From report at bugs.python.org Sun Nov 1 00:54:45 2015 From: report at bugs.python.org (Zachary Ware) Date: Sun, 01 Nov 2015 04:54:45 +0000 Subject: [issue25526] (python2.7.10)ImportError: No module named _ssl In-Reply-To: <1446344567.35.0.253230006676.issue25526@psf.upfronthosting.co.za> Message-ID: <1446353685.31.0.285402624481.issue25526@psf.upfronthosting.co.za> Zachary Ware added the comment: Do "yum install openssl-devel", then rebuild Python. There are probably other modules that also didn't build, setup.py will report them at its end. ---------- nosy: +zach.ware resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 01:20:15 2015 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 01 Nov 2015 05:20:15 +0000 Subject: [issue25523] Correct "a" article to "an" article In-Reply-To: <1446294729.19.0.0593417180133.issue25523@psf.upfronthosting.co.za> Message-ID: <1446355215.71.0.892272038616.issue25523@psf.upfronthosting.co.za> Mark Dickinson added the comment: Yes, the Lib/test/decimaltestdata files do come from an external source. I don't see the harm in including them in the changes, but those changes will be overwritten when the files are next updated. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 01:20:44 2015 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 01 Nov 2015 05:20:44 +0000 Subject: [issue25523] Correct "a" article to "an" article In-Reply-To: <1446294729.19.0.0593417180133.issue25523@psf.upfronthosting.co.za> Message-ID: <1446355244.45.0.709847101096.issue25523@psf.upfronthosting.co.za> Mark Dickinson added the comment: I should have said what that source is: it's http://speleotrove.com/decimal/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 01:56:06 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 01 Nov 2015 05:56:06 +0000 Subject: [issue25525] Deallocation scheme for memoryview is unsafe In-Reply-To: <1446318862.67.0.0722395026507.issue25525@psf.upfronthosting.co.za> Message-ID: <1446357366.61.0.519991223131.issue25525@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: WTF? Where is my patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 01:07:55 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 01 Nov 2015 06:07:55 +0000 Subject: [issue25525] Deallocation scheme for memoryview is unsafe In-Reply-To: <1446318862.67.0.0722395026507.issue25525@psf.upfronthosting.co.za> Message-ID: <1446358075.3.0.443429714633.issue25525@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Strange bug. I can't attach any file. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 01:11:43 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 01 Nov 2015 06:11:43 +0000 Subject: [issue25228] Regression in cookie parsing with brackets and quotes In-Reply-To: <1443113876.69.0.763546669405.issue25228@psf.upfronthosting.co.za> Message-ID: <1446358303.32.0.47944550947.issue25228@psf.upfronthosting.co.za> Martin Panter added the comment: Adding Guido and Antoine, who committed the security fix as 9e765e65e5cb in 2.7 and 5cfe74a9bfa4 in 3.2. Perhaps you are able to help decide if the proposal here would affect the original security report. Basically this issue (as well as #22758 and #22983) are complaining that 3.2?s cookie parsing became too strict. People would like to parse subsequent cookie ?morsels? if an earlier one is considered invalid, rather than aborting the parse completely. All I can find out about the security report is from and , but that doesn?t explain the test cases with square brackets in the cookie names. RFC 6265 says double quotes (") are not meant to be sent by the server, but the client should tolerate them without any special handling (different to Python?s handling and earlier specs, which parse a special double-quoted string syntax). One potential problem that comes to mind is that the current patch blindly searches for the next semicolon ?;?, which would not be valid inside a double-quoted string, e.g. name="some;value". Python behaviour: * Before the 3.2 security fix, square brackets and double quotes caused truncation of the cookie value, but subsequent cookies were still parsed in most cases * The security fix prevents parsing of subsequent cookies (either on purpose or as a side effect) * The HttpOnly and Secure support in 3.3+ (Issue 16611) prevents parsing of the cookie morsel with the offending square bracket or double quote. This is proposed for 3.2 backport in Issue 22758. * Square brackets are now allowed in 3.2+ thanks to Issue 22931. So 3.2 should truncate the original test case at the double quote, while 3.3+ drops the offending cookie. The current patch proposed here appears to solve Issue 22983 (permissive parsing) in general. If the current cookie does not match the syntax, it is skipped, by falling back to a search for a semicolon ?;?. So I am inclined to close Issue 22983 as a duplicate of this issue. And Tim, I understand your main interest in Issue 22758 is that parsing aborts for things like "a=value1; HttpOnly; b=value2". If this patch were ported to 3.2 it should also fix that for free. Pathangi: did you see my review comment about unnecessary backslashes? I also left another comment today. ---------- nosy: +gvanrossum, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 02:18:04 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 01 Nov 2015 07:18:04 +0000 Subject: [issue22450] urllib doesn't put Accept: */* in the headers In-Reply-To: <1411257032.38.0.526589346468.issue22450@psf.upfronthosting.co.za> Message-ID: <1446362284.54.0.66491208149.issue22450@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > What do you think, Raymond Before dismissing this, we should get a better understanding of why "Accept: */*" is so widely used in practice. Here's what we know so far: * The header made a difference to the Facebook Graph API. * Curl (a minimalist) includes "Accept: */*", Host, and User-Agent. * Firefox includes "*/*" at the end of its list of acceptable types. * Kenneth Reitz's requests module uses "Accept: */*" by default. * The poolmanager in urllib3 uses "Accept: */*" by default and has a comment that that and the "Host" header are both needed by proxies. * I'm also seeing "Accept: */*" in book examples as well. See https://books.google.com/books?id=fVuWayXLdYIC&pg=PA22 and http://doc.bonfire-project.eu/R1/api/example-session.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 02:26:49 2015 From: report at bugs.python.org (Laura Creighton) Date: Sun, 01 Nov 2015 07:26:49 +0000 Subject: [issue25522] IDLE: warn if save-as name matches stdlib name In-Reply-To: <1446270102.89.0.424617028731.issue25522@psf.upfronthosting.co.za> Message-ID: <1446362809.11.0.812860017936.issue25522@psf.upfronthosting.co.za> Laura Creighton added the comment: I'm not sure about "Neither you nor Python will be able to import the stdlib." Depending on what the file is, you may be able to import it later. I'd prefer: "If you run Python in this directory, your version of will be used instead of the one in the standard library. This may cause Idle to behave strangely, or possibly not run at all." ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 02:36:58 2015 From: report at bugs.python.org (Laura Creighton) Date: Sun, 01 Nov 2015 07:36:58 +0000 Subject: [issue25522] IDLE: warn if save-as name matches stdlib name In-Reply-To: <1446270102.89.0.424617028731.issue25522@psf.upfronthosting.co.za> Message-ID: <1446363418.0.0.398274375166.issue25522@psf.upfronthosting.co.za> Laura Creighton added the comment: Do we need a full path name here as well? Probably not. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 02:39:24 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 01 Nov 2015 07:39:24 +0000 Subject: [issue25523] Correct "a" article to "an" article In-Reply-To: <1446294729.19.0.0593417180133.issue25523@psf.upfronthosting.co.za> Message-ID: <1446363564.28.0.489674911395.issue25523@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks everyone for the comments. Serhiy?s points: I did this by using ?grep? and then manually editing all of the appropriate lines. So they were not generated by a script, but because it is a fairly mindless process I could have made human mistakes. In multiprocessing.rst, socket.rst, I removed ?a? because I thought it matched the surrounding text, e.g. it already says nearby ?If .?.?. then OSError is raised?, rather than ?an OSError is raised?. I find the documentation uses both forms in many places, so I just try to keep things consistent with the nearby text. In 3.2.rst, I thought it should be plural: ?total_ordering() will use existing equality and inequality methods?. I could reword it to something like ?will use an existing equality and inequality method? if you prefer. Either way seems valid to me. In HISTORY, I removed ?a? from ?.?.?. is passed ill-formed input? because it seemed better (similar to ?is passed hot water?). But ?an ill-formed input? should also be fine if people prefer. _hashopenssl.c: ?have a its own definition? is nonsense, hence I removed ?a?. ?An SMTP?: See Emanuel and David. The rest of the page uses ?an SMTP?, while I only found two instances of ?a SMTP?, which I made consistent. Externally-supplied decimaltestdata: I did wonder about this. Looking at the history, I saw other local changes, but now I notice most are in a special ?extra.decTest? file. Anyway, as Mark says it is okay I will let my changes go ahead for the time being. David: I have incorporated your suggestion for test_discovery.py into my local patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 02:56:28 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 01 Nov 2015 07:56:28 +0000 Subject: [issue25523] Correct "a" article to "an" article In-Reply-To: <1446294729.19.0.0593417180133.issue25523@psf.upfronthosting.co.za> Message-ID: <1446364588.89.0.177712534833.issue25523@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I had pointed to some of changes not because they look wrong to me, but for the case if there are human mistakes. After your acknowledgement all LGTM. ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 03:00:01 2015 From: report at bugs.python.org (Laura Creighton) Date: Sun, 01 Nov 2015 08:00:01 +0000 Subject: [issue25514] better startup error messages in IDLE when stdlib modules shadowed In-Reply-To: <1446151640.74.0.583734209916.issue25514@psf.upfronthosting.co.za> Message-ID: <1446364801.68.0.779683988203.issue25514@psf.upfronthosting.co.za> Laura Creighton added the comment: can I send a file ---------- type: behavior -> enhancement versions: -Python 3.4 Added file: http://bugs.python.org/file40915/dia2.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 03:32:11 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 01 Nov 2015 08:32:11 +0000 Subject: [issue14373] C implementation of functools.lru_cache In-Reply-To: <1332250846.11.0.753199667334.issue14373@psf.upfronthosting.co.za> Message-ID: <1446366731.83.0.272972335396.issue14373@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 04:30:43 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 01 Nov 2015 09:30:43 +0000 Subject: [issue22450] urllib doesn't put Accept: */* in the headers In-Reply-To: <1411257032.38.0.526589346468.issue22450@psf.upfronthosting.co.za> Message-ID: <1446370243.58.0.991162255964.issue22450@psf.upfronthosting.co.za> Martin Panter added the comment: According to all the HTTP 1.1 RFCs, having */* at the end means you accept any other content type if none of the higher priority ones are available (otherwise you risk a 406 Not Acceptable error). So that explains why Firefox has */* tacked on. Requests copied from Curl: . Similarly, it is in urllib3 ?because that?s what cURL had by default?. Brief discussion at , where they decided to leave things as they already were. So all roads seem to lead to Curl. Curl?s ?initial revision? (Dec 1999) had ?Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*?, which was changed to ?Accept: */*? in in 2004. I don?t see any reasons given. I just left a question on Git Hub about this, so maybe we might get some sort of answer. Wget also includes ?Accept: */*?. But it gives no explanations either, and it was present right from the ?initial revision? also in Dec 1999 (presumably Source Forge started about then). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 04:49:58 2015 From: report at bugs.python.org (Antony Lee) Date: Sun, 01 Nov 2015 09:49:58 +0000 Subject: [issue25527] Invalid (... and confusing) warning raised by 2to3 regarding repeat Message-ID: <1446371398.34.0.43007110205.issue25527@psf.upfronthosting.co.za> New submission from Antony Lee: $ echo 'from numpy import repeat\nrepeat(2, 3)' | 2to3 - RefactoringTool: Skipping optional fixer: buffer RefactoringTool: Skipping optional fixer: idioms RefactoringTool: Skipping optional fixer: set_literal RefactoringTool: Skipping optional fixer: ws_comma RefactoringTool: No files need to be modified. RefactoringTool: Warnings/messages while refactoring: RefactoringTool: ### In file ### RefactoringTool: Line 2: You should use 'operator.mul(2, 3)' here. numpy.repeat(2, 3) returns np.array([2, 2, 2]) but 2to3 confuses it with the old operator.repeat. It may be impossible to resolve in general which function the author wanted to call but perhaps the warning should only be raised if the operator module is imported at some point? (or clarify the error message) ---------- components: 2to3 (2.x to 3.x conversion tool) messages: 253835 nosy: Antony.Lee priority: normal severity: normal status: open title: Invalid (... and confusing) warning raised by 2to3 regarding repeat versions: Python 2.7, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 04:57:43 2015 From: report at bugs.python.org (Rohit Mediratta) Date: Sun, 01 Nov 2015 09:57:43 +0000 Subject: [issue25528] Attempt to further increase test coverage of calendar module Message-ID: <1446371863.84.0.773420016182.issue25528@psf.upfronthosting.co.za> New submission from Rohit Mediratta: Opened to submit a patch. - make patchcheck succeeded - full testsuite succeeded - Old coverage Lib/calendar.py 375 54 86% 511, 519, 541, 608-699, 703 - New coverage Lib/calendar.py 375 51 86% 608-699, 703 ---------- components: Tests files: mywork.patch keywords: patch messages: 253836 nosy: Rohit Mediratta priority: normal severity: normal status: open title: Attempt to further increase test coverage of calendar module type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file40916/mywork.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 05:08:49 2015 From: report at bugs.python.org (Pathangi Jatinshravan) Date: Sun, 01 Nov 2015 10:08:49 +0000 Subject: [issue25228] Regression in cookie parsing with brackets and quotes In-Reply-To: <1443113876.69.0.763546669405.issue25228@psf.upfronthosting.co.za> Message-ID: <1446372529.04.0.619713720585.issue25228@psf.upfronthosting.co.za> Pathangi Jatinshravan added the comment: Just saw the code review comments now, didn't know that there was a separate section for code review comments until now. Will take a look and implement them. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 05:14:15 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 01 Nov 2015 10:14:15 +0000 Subject: [issue25521] optparse module does not emit DeprecationWarning In-Reply-To: <1446247354.16.0.386152814173.issue25521@psf.upfronthosting.co.za> Message-ID: <1446372855.7.0.555777012106.issue25521@psf.upfronthosting.co.za> Martin Panter added the comment: I don?t have an opinion on pending vs non-pending warning. I think there are quite a few standard library modules that use ?optparse? that will emit a warning as a result of this change. And the test suite probably needs patching to suppress the warning while testing the ?optparse? module. Perhaps you could look at the code touched by revisions 5877c191b76e (imp warning upgrade) and 3f924cb4c3eb (test suite update) for inspiration. ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 05:16:39 2015 From: report at bugs.python.org (Stefan Krah) Date: Sun, 01 Nov 2015 10:16:39 +0000 Subject: [issue25525] Deallocation scheme for memoryview is unsafe In-Reply-To: <1446318862.67.0.0722395026507.issue25525@psf.upfronthosting.co.za> Message-ID: <1446372999.56.0.314431217312.issue25525@psf.upfronthosting.co.za> Stefan Krah added the comment: > First garbage collector calls tp_clear for all objects in the loop (memory_clear() for memoryview). If self->exports != 0 for memoryview, _memory_release() fails and the _Py_MEMORYVIEW_RELEASED flag is not set. I don't understand: 1) memory_clear() 2) _memory_release() 3) if self->exports > 0 then BufferError. Please state the code path clearly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 05:28:09 2015 From: report at bugs.python.org (Stefan Krah) Date: Sun, 01 Nov 2015 10:28:09 +0000 Subject: [issue25194] Opt-in motivations & affiliations page for core contributors In-Reply-To: <1442740668.12.0.539568285088.issue25194@psf.upfronthosting.co.za> Message-ID: <1446373689.7.0.0905647273313.issue25194@psf.upfronthosting.co.za> Stefan Krah added the comment: Hmm, I have some reservations about linking to statistics. They can really give wrong incentives for committing (and IMO this is already happening on GitHub). ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 05:41:47 2015 From: report at bugs.python.org (SilentGhost) Date: Sun, 01 Nov 2015 10:41:47 +0000 Subject: [issue25521] optparse module does not emit DeprecationWarning In-Reply-To: <1446247354.16.0.386152814173.issue25521@psf.upfronthosting.co.za> Message-ID: <1446374507.46.0.0933862516052.issue25521@psf.upfronthosting.co.za> SilentGhost added the comment: Modules that use optparse: calendar (issue18973 has patch), uu (seems trivial to change), test_decimal (trivial too), profile, cprofile Tools: strginbench, ccbench, iobench Neither of the changes are particularly tricky it seems. ---------- nosy: +SilentGhost _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 05:45:26 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Sun, 01 Nov 2015 10:45:26 +0000 Subject: [issue25521] optparse module does not emit DeprecationWarning In-Reply-To: <1446247354.16.0.386152814173.issue25521@psf.upfronthosting.co.za> Message-ID: <1446374726.96.0.878240306757.issue25521@psf.upfronthosting.co.za> St?phane Wirtel added the comment: Already proposed to move to argparse for the existing modules, see this issue: http://bugs.python.org/issue25475 For the calendar module, there are two issues with two patches. http://bugs.python.org/issue25499 and http://bugs.python.org/issue18973 I can write a patch to use argparse instead of optparse. ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 08:56:25 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 01 Nov 2015 13:56:25 +0000 Subject: [issue25525] Deallocation scheme for memoryview is unsafe In-Reply-To: <1446318862.67.0.0722395026507.issue25525@psf.upfronthosting.co.za> Message-ID: <1446386185.03.0.134719068571.issue25525@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +patch Added file: http://bugs.python.org/file40917/memoryview_safer_clearing.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 09:00:10 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 01 Nov 2015 14:00:10 +0000 Subject: [issue25525] Deallocation scheme for memoryview is unsafe In-Reply-To: <1446318862.67.0.0722395026507.issue25525@psf.upfronthosting.co.za> Message-ID: <1446386410.34.0.0416290347702.issue25525@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: 1) memory_clear() 2) _memory_release() 3) if self->exports > 0 then BufferError (but ignored). 4) Py_CLEAR(self->mbuf) 5) memory_dealloc() 6) _memory_release() 7) self->mbuf->exports where self->mbuf == NULL ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 09:04:52 2015 From: report at bugs.python.org (Ryosuke Ito) Date: Sun, 01 Nov 2015 14:04:52 +0000 Subject: [issue25510] fileinput.FileInput.readline() always returns str object at the end even if in 'rb' mode In-Reply-To: <1446127939.75.0.173725539565.issue25510@psf.upfronthosting.co.za> Message-ID: <1446386692.16.0.291511665301.issue25510@psf.upfronthosting.co.za> Ryosuke Ito added the comment: Add a test for fileinput.FileInput.readline() in 'rb' mode. I'm sure this test fails on Python 3.5 and fixed in the patch(fileinput.py.diff). ---------- Added file: http://bugs.python.org/file40918/test_fileinput.py.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 09:08:14 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 01 Nov 2015 14:08:14 +0000 Subject: [issue25395] SIGSEGV using json.tool: highly nested OrderedDict In-Reply-To: <1444765181.78.0.70980847428.issue25395@psf.upfronthosting.co.za> Message-ID: <1446386894.87.0.932681582603.issue25395@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 09:14:35 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 01 Nov 2015 14:14:35 +0000 Subject: [issue25395] SIGSEGV using json.tool: highly nested OrderedDict In-Reply-To: <1444765181.78.0.70980847428.issue25395@psf.upfronthosting.co.za> Message-ID: <20151101141431.80222.64369@psf.io> Roundup Robot added the comment: New changeset ce8c850a52d4 by Serhiy Storchaka in branch '3.5': Issue #25395: Fixed crash when highly nested OrderedDict structures were https://hg.python.org/cpython/rev/ce8c850a52d4 New changeset bd6bfa5fe203 by Serhiy Storchaka in branch 'default': Issue #25395: Fixed crash when highly nested OrderedDict structures were https://hg.python.org/cpython/rev/bd6bfa5fe203 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 09:16:12 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 01 Nov 2015 14:16:12 +0000 Subject: [issue25395] SIGSEGV using json.tool: highly nested OrderedDict In-Reply-To: <1444765181.78.0.70980847428.issue25395@psf.upfronthosting.co.za> Message-ID: <1446387372.05.0.53427111806.issue25395@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Martin for your review and for initial investigation. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 09:34:21 2015 From: report at bugs.python.org (Cyd Haselton) Date: Sun, 01 Nov 2015 14:34:21 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> Message-ID: <1446388461.22.0.596296765282.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: GDB debugging isn't going to happen any time soon; all of the gdb tests fail. I re-compiled with the --with-pydebug option, thinking that would help, but it won't build; I get the following error when the newly built python starts to build packages: Debug memory block at address p=0xb6003070: API 'a' 795107700 bytes originally requested The 3 pad bytes at p-3 are not all FORBIDDENBYTE (0xfb): at p-3: 0x2f *** OUCH at p-2: 0x00 *** OUCH at p-1: 0x00 *** OUCH Because memory is corrupted at the start, the count of bytes requested may be bogus, and checking the trailing pad bytes may segfault. The 4 pad bytes at tail=0xe56491e4 are Segmentation fault generate-posix-vars failed Additional things I've attemptedto try to resolve the test_hash failure, based on this bug report (https://mail.python.org/pipermail/python-bugs-list/2015-March/267442.html) 1) compiling with -mno-unaligned-access 2) compiling with FNV as the default hash algorithm. Neither worked. At this point I am at a loss and am beginning to think there may be a problem with my device. Any suggestions are welcome. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 09:37:34 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 01 Nov 2015 14:37:34 +0000 Subject: [issue25510] fileinput.FileInput.readline() always returns str object at the end even if in 'rb' mode In-Reply-To: <1446127939.75.0.173725539565.issue25510@psf.upfronthosting.co.za> Message-ID: <1446388654.13.0.1104155207.issue25510@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. I don't think we should care about breaking backward compatibility here. Most code tests end-of-files with "not line" or "len(line) == 0", and this work with fixed fileinput as well as with broken. That is why we have received this bug report now, after many years since releasing 3.0. ---------- assignee: -> serhiy.storchaka stage: test needed -> commit review versions: +Python 3.4, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 09:46:49 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 01 Nov 2015 14:46:49 +0000 Subject: [issue25510] fileinput.FileInput.readline() always returns str object at the end even if in 'rb' mode In-Reply-To: <1446127939.75.0.173725539565.issue25510@psf.upfronthosting.co.za> Message-ID: <20151101144646.10172.48896@psf.io> Roundup Robot added the comment: New changeset e27c589e1c6a by Serhiy Storchaka in branch '3.4': Issue #25510: fileinput.FileInput.readline() now returns b'' instead of '' https://hg.python.org/cpython/rev/e27c589e1c6a New changeset 321b34824020 by Serhiy Storchaka in branch '3.5': Issue #25510: fileinput.FileInput.readline() now returns b'' instead of '' https://hg.python.org/cpython/rev/321b34824020 New changeset 4f0e293e6eb0 by Serhiy Storchaka in branch 'default': Issue #25510: fileinput.FileInput.readline() now returns b'' instead of '' https://hg.python.org/cpython/rev/4f0e293e6eb0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 09:50:32 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 01 Nov 2015 14:50:32 +0000 Subject: [issue25510] fileinput.FileInput.readline() always returns str object at the end even if in 'rb' mode In-Reply-To: <1446127939.75.0.173725539565.issue25510@psf.upfronthosting.co.za> Message-ID: <1446389432.38.0.639558211809.issue25510@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Ryosuke for your contribution. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 09:54:10 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 01 Nov 2015 14:54:10 +0000 Subject: [issue18973] Use argparse in the calendar module In-Reply-To: <1378652776.38.0.50139824268.issue18973@psf.upfronthosting.co.za> Message-ID: <1446389650.5.0.40149861326.issue18973@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 10:14:17 2015 From: report at bugs.python.org (Ryan Gonzalez) Date: Sun, 01 Nov 2015 15:14:17 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1446388461.22.0.596296765282.issue23496@psf.upfronthosting.co.za> Message-ID: Ryan Gonzalez added the comment: Are there no binaries? Pretty sure it isn't your device. I'd think a compiler issue. What are you using, and what version? You have insane determination! :D On November 1, 2015 8:34:21 AM CST, Cyd Haselton wrote: > >Cyd Haselton added the comment: > >GDB debugging isn't going to happen any time soon; all of the gdb tests >fail. >I re-compiled with the --with-pydebug option, thinking that would help, >but it won't build; I get the following error when the newly built >python starts to build packages: > >Debug memory block at address p=0xb6003070: API 'a' > 795107700 bytes originally requested > The 3 pad bytes at p-3 are not all FORBIDDENBYTE (0xfb): > at p-3: 0x2f *** OUCH > at p-2: 0x00 *** OUCH > at p-1: 0x00 *** OUCH > Because memory is corrupted at the start, the count of bytes requested > may be bogus, and checking the trailing pad bytes may segfault. > The 4 pad bytes at tail=0xe56491e4 are Segmentation fault >generate-posix-vars failed > >Additional things I've attemptedto try to resolve the test_hash >failure, based on this bug report >(https://mail.python.org/pipermail/python-bugs-list/2015-March/267442.html) >1) compiling with -mno-unaligned-access >2) compiling with FNV as the default hash algorithm. > >Neither worked. At this point I am at a loss and am beginning to think >there may be a problem with my device. Any suggestions are welcome. > >---------- > >_______________________________________ >Python tracker > >_______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 10:14:51 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 01 Nov 2015 15:14:51 +0000 Subject: [issue18973] Use argparse in the calendar module In-Reply-To: <1378652776.38.0.50139824268.issue18973@psf.upfronthosting.co.za> Message-ID: <20151101151448.59801.54171@psf.io> Roundup Robot added the comment: New changeset 9f8b5053e30d by Serhiy Storchaka in branch 'default': Issue #18973: Command-line interface of the calendar module now uses argparse https://hg.python.org/cpython/rev/9f8b5053e30d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 10:17:33 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 01 Nov 2015 15:17:33 +0000 Subject: [issue18973] Use argparse in the calendar module In-Reply-To: <1378652776.38.0.50139824268.issue18973@psf.upfronthosting.co.za> Message-ID: <1446391053.34.0.706507387763.issue18973@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you SilentGhost and St?phane for your review. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 10:18:40 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Sun, 01 Nov 2015 15:18:40 +0000 Subject: [issue18973] Use argparse in the calendar module In-Reply-To: <1378652776.38.0.50139824268.issue18973@psf.upfronthosting.co.za> Message-ID: <1446391120.93.0.76741087075.issue18973@psf.upfronthosting.co.za> St?phane Wirtel added the comment: Serhiy, welcome. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 10:26:45 2015 From: report at bugs.python.org (Pathangi Jatinshravan) Date: Sun, 01 Nov 2015 15:26:45 +0000 Subject: [issue25228] Regression in cookie parsing with brackets and quotes In-Reply-To: <1443113876.69.0.763546669405.issue25228@psf.upfronthosting.co.za> Message-ID: <1446391605.3.0.784409037496.issue25228@psf.upfronthosting.co.za> Pathangi Jatinshravan added the comment: New patch with code review comments incorporated. ---------- Added file: http://bugs.python.org/file40919/patch_review.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 10:27:30 2015 From: report at bugs.python.org (Cyd Haselton) Date: Sun, 01 Nov 2015 15:27:30 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> Message-ID: <1446391650.12.0.0558130003017.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: Pretty sure there are binaries, but the python binary can't build its own modules. I'm using GCC 4.9.2 on Android L...which means it is a PIE and that Python is being built as a PIE ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 10:48:14 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 01 Nov 2015 15:48:14 +0000 Subject: [issue25521] optparse module does not emit DeprecationWarning In-Reply-To: <1446247354.16.0.386152814173.issue25521@psf.upfronthosting.co.za> Message-ID: <1446392894.13.0.000960147917143.issue25521@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: There is a difference between optparse and other deprecated module. Other modules are deprecated if they are too buggy or bad-designed to be fixed and there are stable standard or third-party modules that provides similar functionality. But looking on a number of open issues for argparse it seems that optparse is more stable and has less bugs than more powerful argparse. Having experience with converting many modules from optparse to argparse or reviewing converting patches, I can say that not always the conversion can be done without loss. For example there is a difference in formatting descriptions. I think that optparse should be supported in the stdlib for very long time. -1 for non-pending warning. Don?t have an opinion about pending warning. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 11:02:07 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 01 Nov 2015 16:02:07 +0000 Subject: [issue25521] optparse module does not emit DeprecationWarning In-Reply-To: <1446247354.16.0.386152814173.issue25521@psf.upfronthosting.co.za> Message-ID: <1446393727.17.0.598954486331.issue25521@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: And it looks there was a special decision to not deprecate optparse. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 11:41:07 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 01 Nov 2015 16:41:07 +0000 Subject: [issue25464] Tix HList header_exists should be "exist" In-Reply-To: <1445555946.1.0.542845821493.issue25464@psf.upfronthosting.co.za> Message-ID: <1446396067.22.0.873035931639.issue25464@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It looks as a bug in Tix. All other Tcl, Tk and Tix commands (except "assemblecode") use "exists", and "header exists" is documented. Perhaps we should workaround this bug. But I doubt about renaming header_exists to header_exist. As for tests, I'm working on writing tests for Tix. The progress is slow because Tix provides a lot of classes with a lot of commands and options, but I hope to finish the work before releasing 3.6. We can commit the patch for this issue without tests, just add a reminder in test_tix.py. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 11:57:10 2015 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 01 Nov 2015 16:57:10 +0000 Subject: [issue25228] Regression in cookie parsing with brackets and quotes In-Reply-To: <1446358303.32.0.47944550947.issue25228@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: I'm coming at this without much context (I don't recall the original issue) but IIUC from a security POV, lenient parsing is unsafe -- it could allow an attacker to modify a cookie (or part of a cookie -- I'm unclear on the correct terminology here) and that's what we're trying to avoid. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 12:29:59 2015 From: report at bugs.python.org (Stefan Krah) Date: Sun, 01 Nov 2015 17:29:59 +0000 Subject: [issue25525] Deallocation scheme for memoryview is unsafe In-Reply-To: <1446318862.67.0.0722395026507.issue25525@psf.upfronthosting.co.za> Message-ID: <1446398999.13.0.122594188213.issue25525@psf.upfronthosting.co.za> Stefan Krah added the comment: First of all, the premise "exports > 0" in your example looks wrong to me. The deallocation process for the first view should start precisely when it no longer has any exports. In fact, the check for "exports > 0" is for the case when memoryview.release() is called from the Python level. Secondly, even if it did happen (show the code path leading to that!), BufferError would be set in memory_clear() and the garbage collector would throw a FatalError, i.e. step 5+ would not be reached. Lastly, I don't find it very diplomatic to use language like "Deallocation scheme for memoryview is complex and unsafe. It crashes with chained memoryviews..." when you don't seem to a test case or a clear concept of how the alleged bug should occur. ---------- resolution: -> not a bug stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 13:06:17 2015 From: report at bugs.python.org (Cyd Haselton) Date: Sun, 01 Nov 2015 18:06:17 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> Message-ID: <1446401177.47.0.640883481768.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: Key note: it looks like the config option --with-hash-algorithm does nothing; python is still built with the siphash hash algorithim even though I specified fnv and, in pyconfig.h: /* Define hash algorithm for str, bytes and memoryview. SipHash24: 1, FNV: 2, externally defined: 0 */ #define Py_HASH_ALGORITHM 2 What's the correct way to build with fnv as the hash algorithm? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 13:31:13 2015 From: report at bugs.python.org (tzickel) Date: Sun, 01 Nov 2015 18:31:13 +0000 Subject: [issue25083] Python can sometimes create incorrect .pyc files In-Reply-To: <1442143572.78.0.211523310189.issue25083@psf.upfronthosting.co.za> Message-ID: <1446402673.29.0.936706401125.issue25083@psf.upfronthosting.co.za> tzickel added the comment: TL:DR Python 2 forgot to do I/O error checking when reading .py files from disk. On some rare situations this can bite Python in the ass and cause it to bork .pyc files. Checked python 3, it checks the I/O in a different / better way. Next python 2.7 is out in 1.5 month, I really want this fix to get in, did I forgot to nose some developer who can help out ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 13:39:40 2015 From: report at bugs.python.org (Cory Benfield) Date: Sun, 01 Nov 2015 18:39:40 +0000 Subject: [issue25529] Provide access to the validated certificate chain in ssl module Message-ID: <1446403180.28.0.269111083171.issue25529@psf.upfronthosting.co.za> New submission from Cory Benfield: I?m currently working on adding support for HPKP to the Requests and urllib3 modules. HPKP (HTTP Public Key Pinning), specified in RFC 7469, is an extension to HTTP that allows a web server to specify a whitelist of public keys that are valid for TLS certificates on that domain. This prevents a rogue certificate authority from issuing a certificate that would be trusted by a browser and would allow a man-in-the-middle attack on a domain (as happened to Google in 2013[0]). Right now, the draft version of the support I have will only work when you use PyOpenSSL for your TLS needs, not the standard library. This is because to get HPKP to work I need access to the validated certificate chain: that is, the certificate chain that OpenSSL has built and validated for the TLS connection. I also need to be able to work with those certificates in order to extract their public keys. The standard library?s ssl module does not expose any of this functionality. To get this to work with the standard library, I would require the following things from the standard library: 1. The ability to access the validated certificate chain. This requires saving off the certificate each time the OpenSSL verify callback is called. This is an easy enough change to make. 2. The ability to extract the public key from the saved certificates. This could be done by extending the logic used for getpeercert() to provide a DER-encoded ASN.1 representation of the public key in the dictionary, and then using that representation for each cert in the peer cert chain. The motivation for making this available in the standard library would be pip. Right now python.org and all its subdomains (including pypi.python.org) are HPKP-enabled. Making this support available in the standard library would ensure that all pip installations are safe from man-in-the-middle attacks on its packaging infrastructure. Without it, a number of third-party packages would be required to add this security. In particular, pip could distribute a HPKP preload value for pypi.python.org, which would ensure that pip is truly invulnerable to MITM TLS attacks via malicious attackers coercing a CA to provide TLS certificates for *.python.org. I?m happy to do the work required to provide this functionality, but I?d only like to start work if people believe there?s a likelihood of getting it merged. [0]: https://nakedsecurity.sophos.com/2013/01/08/the-turktrust-ssl-certificate-fiasco-what-happened-and-what-happens-next/ ---------- components: Library (Lib) messages: 253864 nosy: Lukasa priority: normal severity: normal status: open title: Provide access to the validated certificate chain in ssl module type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 13:42:40 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 01 Nov 2015 18:42:40 +0000 Subject: [issue25525] Deallocation scheme for memoryview is unsafe In-Reply-To: <1446398999.13.0.122594188213.issue25525@psf.upfronthosting.co.za> Message-ID: <1813878.lqa8uNgOZk@raxxla> Serhiy Storchaka added the comment: Sorry for my bad wording. I wasn't going to blame or insult anybody. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 13:48:32 2015 From: report at bugs.python.org (Brett Cannon) Date: Sun, 01 Nov 2015 18:48:32 +0000 Subject: [issue25083] Python can sometimes create incorrect .pyc files In-Reply-To: <1442143572.78.0.211523310189.issue25083@psf.upfronthosting.co.za> Message-ID: <1446403712.58.0.881929193196.issue25083@psf.upfronthosting.co.za> Brett Cannon added the comment: Nope, I think you probably have everyone who might be interested in looking at fixing this on the issue, tzickel. Just a matter of someone taking the interest and initiative to fix this in Python 2.7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 13:50:38 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 01 Nov 2015 18:50:38 +0000 Subject: [issue25446] smtplib.py AUTH LOGIN code messed up sending login and password data since 3.5 In-Reply-To: <1445355692.4.0.944252984253.issue25446@psf.upfronthosting.co.za> Message-ID: <1446403838.97.0.821511821849.issue25446@psf.upfronthosting.co.za> Larry Hastings added the comment: I think it's about time to think about releasing 3.5.1. But since this bug is marked as a "release blocker", 3.5.1 cannot be released until this is fixed. Arguably I can't even really make a schedule for 3.5.1 until it's fixed, or at least I'm reasonably confident I know when it'll be fixed. Any idea when this might be fixed? ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 14:10:54 2015 From: report at bugs.python.org (Alex Gaynor) Date: Sun, 01 Nov 2015 19:10:54 +0000 Subject: [issue25530] ssl: OP_NO_SSLv3 should always be set unless a user specifically asks for it Message-ID: <1446405054.12.0.603454420685.issue25530@psf.upfronthosting.co.za> New submission from Alex Gaynor: SSLv3 is broken, both _create_unverified_context and create_default_context turn it off, but we should make all contexts turn it off, like we do for SSLv2. A patch is attached. ---------- components: Library (Lib) files: sslv3.diff keywords: needs review, patch, security_issue messages: 253868 nosy: alex, christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou priority: normal severity: normal status: open title: ssl: OP_NO_SSLv3 should always be set unless a user specifically asks for it versions: Python 2.7, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file40920/sslv3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 14:27:14 2015 From: report at bugs.python.org (Christian Heimes) Date: Sun, 01 Nov 2015 19:27:14 +0000 Subject: [issue25529] Provide access to the validated certificate chain in ssl module In-Reply-To: <1446403180.28.0.269111083171.issue25529@psf.upfronthosting.co.za> Message-ID: <1446406034.03.0.487637557544.issue25529@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- nosy: +alex, christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 14:38:44 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 01 Nov 2015 19:38:44 +0000 Subject: [issue25521] optparse module does not emit DeprecationWarning In-Reply-To: <1446247354.16.0.386152814173.issue25521@psf.upfronthosting.co.za> Message-ID: <1446406724.52.0.122960971118.issue25521@psf.upfronthosting.co.za> R. David Murray added the comment: My sense is that most of the open argparse bugs are *because* of the increased power (that is, they aren't, with a few exceptions, in the fundamental bits that optparse does as well). And the issues are open because no one is maintaining that module, either :(. There is one non-committer who has done a lot of work on the patches, we should probably evaluate offering him commit privileges. That said, I don't have a strong opinion on the deprecation-or-not myself. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 14:49:43 2015 From: report at bugs.python.org (kracekumar ramaraju) Date: Sun, 01 Nov 2015 19:49:43 +0000 Subject: [issue25531] greenlet header file is missing inside virtualenv Message-ID: <1446407383.6.0.829207834021.issue25531@psf.upfronthosting.co.za> New submission from kracekumar ramaraju: I am using OSX 10.10.5 (14F27) and Python 3.5. Python 3.5 was installed via brew. When greenlet is installed inside virtualenv using py3.5 header files are missing inside /path/to/venv/include/python3.5m. As a result uwsgi is unable to build with asyncio support ~ brew info python3 python3: stable 3.5.0 (bottled), HEAD Interpreted, interactive, object-oriented programming language https://www.python.org/ /usr/local/Cellar/python3/3.4.3 (4721 files, 82M) Poured from bottle /usr/local/Cellar/python3/3.4.3_2 (5948 files, 98M) Built from source /usr/local/Cellar/python3/3.5.0 (3573 files, 61M) * Poured from bottle From: https://github.com/Homebrew/homebrew/blob/master/Library/Formula/python3.rb ==> Dependencies Build: xz , pkg-config Required: openssl Recommended: readline , sqlite , gdbm , xz Optional: homebrew/dupes/tcl-tk Steps to reproduce ------------------ 1. Create a venv $/tmp python3.5 -m virtualenv venv_bug 2. Install greenlet $/tmp . venv_bug/bin/activate (venv_bug)$/tmp pip install greenlet Collecting greenlet Using cached greenlet-0.4.9.tar.gz Building wheels for collected packages: greenlet Running setup.py bdist_wheel for greenlet Complete output from command /private/tmp/venv_bug/bin/python3.5 -c "import setuptools;__file__='/private/var/folders/xk/8lhz2_j91_3758cc65stj5z40000gn/T/pip-build-sxtdlufe/greenlet/setup.py';exec(compile(open(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" bdist_wheel -d /var/folders/xk/8lhz2_j91_3758cc65stj5z40000gn/T/tmpf6g8rwt_pip-wheel-: running bdist_wheel running build running build_ext building 'greenlet' extension creating build creating build/temp.macosx-10.10-x86_64-3.5 clang -Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/usr/local/Cellar/python3/3.5.0/Frameworks/Python.framework/Versions/3.5/include/python3.5m -c greenlet.c -o build/temp.macosx-10.10-x86_64-3.5/greenlet.o creating build/lib.macosx-10.10-x86_64-3.5 clang -bundle -undefined dynamic_lookup build/temp.macosx-10.10-x86_64-3.5/greenlet.o -o build/lib.macosx-10.10-x86_64-3.5/greenlet.cpython-35m-darwin.so installing to build/bdist.macosx-10.10-x86_64/wheel running install running install_lib creating build/bdist.macosx-10.10-x86_64 creating build/bdist.macosx-10.10-x86_64/wheel copying build/lib.macosx-10.10-x86_64-3.5/greenlet.cpython-35m-darwin.so -> build/bdist.macosx-10.10-x86_64/wheel running install_headers creating build/bdist.macosx-10.10-x86_64/wheel/greenlet-0.4.9.data creating build/bdist.macosx-10.10-x86_64/wheel/greenlet-0.4.9.data/headers copying greenlet.h -> build/bdist.macosx-10.10-x86_64/wheel/greenlet-0.4.9.data/headers running install_egg_info running egg_info creating greenlet.egg-info writing top-level names to greenlet.egg-info/top_level.txt writing greenlet.egg-info/PKG-INFO writing dependency_links to greenlet.egg-info/dependency_links.txt writing manifest file 'greenlet.egg-info/SOURCES.txt' warning: manifest_maker: standard file '-c' not found reading manifest file 'greenlet.egg-info/SOURCES.txt' reading manifest template 'MANIFEST.in' writing manifest file 'greenlet.egg-info/SOURCES.txt' Copying greenlet.egg-info to build/bdist.macosx-10.10-x86_64/wheel/greenlet-0.4.9-py3.5.egg-info running install_scripts Traceback (most recent call last): File "", line 1, in File "/private/var/folders/xk/8lhz2_j91_3758cc65stj5z40000gn/T/pip-build-sxtdlufe/greenlet/setup.py", line 101, in **setuptools_args) File "/usr/local/Cellar/python3/3.5.0/Frameworks/Python.framework/Versions/3.5/lib/python3.5/distutils/core.py", line 148, in setup dist.run_commands() File "/usr/local/Cellar/python3/3.5.0/Frameworks/Python.framework/Versions/3.5/lib/python3.5/distutils/dist.py", line 955, in run_commands self.run_command(cmd) File "/usr/local/Cellar/python3/3.5.0/Frameworks/Python.framework/Versions/3.5/lib/python3.5/distutils/dist.py", line 974, in run_command cmd_obj.run() File "/private/tmp/venv_bug/lib/python3.5/site-packages/wheel/bdist_wheel.py", line 213, in run archive_basename = self.get_archive_basename() File "/private/tmp/venv_bug/lib/python3.5/site-packages/wheel/bdist_wheel.py", line 161, in get_archive_basename impl_tag, abi_tag, plat_tag = self.get_tag() File "/private/tmp/venv_bug/lib/python3.5/site-packages/wheel/bdist_wheel.py", line 155, in get_tag assert tag == supported_tags[0] AssertionError ---------------------------------------- Failed building wheel for greenlet Failed to build greenlet Installing collected packages: greenlet Running setup.py install for greenlet Successfully installed greenlet-0.4.9 3. Install uWSGI (venv_bug)$ /tmp CFLAGS="-I/tmp/venv_bug/include/python3.5m" UWSGI_PROFILE="asyncio" pip install uwsgi Collecting uwsgi Using cached uwsgi-2.0.11.2.tar.gz Building wheels for collected packages: uwsgi Running setup.py bdist_wheel for uwsgi Complete output from command /private/tmp/venv_bug/bin/python3.5 -c "import setuptools;__file__='/private/var/folders/xk/8lhz2_j91_3758cc65stj5z40000gn/T/pip-build-bru7wwac/uwsgi/setup.py';exec(compile(open(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" bdist_wheel -d /var/folders/xk/8lhz2_j91_3758cc65stj5z40000gn/T/tmpwoq08qywpip-wheel-: running bdist_wheel running build running build_py creating build creating build/lib copying uwsgidecorators.py -> build/lib installing to build/bdist.macosx-10.10-x86_64/wheel running install plugins/greenlet/greenlet.c:2:10: fatal error: 'greenlet/greenlet.h' file not found #include ^ 1 error generated. ---------------------------------------- Failed building wheel for uwsgi Failed to build uwsgi Installing collected packages: uwsgi Running setup.py install for uwsgi Complete output from command /private/tmp/venv_bug/bin/python3.5 -c "import setuptools, tokenize;__file__='/private/var/folders/xk/8lhz2_j91_3758cc65stj5z40000gn/T/pip-build-bru7wwac/uwsgi/setup.py';exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --record /var/folders/xk/8lhz2_j91_3758cc65stj5z40000gn/T/pip-69gibzr6-record/install-record.txt --single-version-externally-managed --compile --install-headers /private/tmp/venv_bug/bin/../include/site/python3.5/uwsgi: running install plugins/greenlet/greenlet.c:2:10: fatal error: 'greenlet/greenlet.h' file not found #include ^ 1 error generated. ---------------------------------------- Command "/private/tmp/venv_bug/bin/python3.5 -c "import setuptools, tokenize;__file__='/private/var/folders/xk/8lhz2_j91_3758cc65stj5z40000gn/T/pip-build-bru7wwac/uwsgi/setup.py';exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --record /var/folders/xk/8lhz2_j91_3758cc65stj5z40000gn/T/pip-69gibzr6-record/install-record.txt --single-version-externally-managed --compile --install-headers /private/tmp/venv_bug/bin/../include/site/python3.5/uwsgi" failed with error code 1 in /private/var/folders/xk/8lhz2_j91_3758cc65stj5z40000gn/T/pip-build-bru7wwac/uwsgi Also setuptools is at latest version 18.2. Installing uwsgi site wide succeeds. greenlet directory is present inside `python3.5m`. (venv_bug)$ /tmp ls -la /usr/local/include/python3.5m | grep greenlet drwxr-xr-x 3 root admin 102 Nov 1 20:40 greenlet Links: uWSGI asyncio: https://uwsgi-docs.readthedocs.org/en/latest/asyncio.html#building-uwsgi-with-asyncio-support Greenlet issue thread: https://github.com/python-greenlet/greenlet/issues/96 ---------- components: Macintosh messages: 253870 nosy: kracekumar, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: greenlet header file is missing inside virtualenv type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 15:02:59 2015 From: report at bugs.python.org (Camilla Montonen) Date: Sun, 01 Nov 2015 20:02:59 +0000 Subject: [issue25041] document AF_PACKET socket address format In-Reply-To: <1441804077.41.0.782475265278.issue25041@psf.upfronthosting.co.za> Message-ID: <1446408179.37.0.435572685487.issue25041@psf.upfronthosting.co.za> Camilla Montonen added the comment: Thank you very much for the feedback, Martin and Berker! I'll start working on the revised patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 15:05:17 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 01 Nov 2015 20:05:17 +0000 Subject: [issue25455] Some repr implementations don't check for self-referential structures In-Reply-To: <1445455038.6.0.824380060049.issue25455@psf.upfronthosting.co.za> Message-ID: <1446408317.43.0.862642848125.issue25455@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The general solution is to make PyObject_Repr to detect recursive calls (as reprlib.recursive_repr does). The straightforward way is to use thread local identity set. It can be implemented as a dict that maps id(obj) -> obj (creates an int object for key for every call, requires about 40-80 bytes for recurse level), or as specialized hash table (see Modules/hashtable.c) (faster, requires about 12-24 bytes for recurse level). The fastest solution would be to set special flag inside proceeded object. For now general object has no place for such flag, but we can add it to GC head. On 64-bit this would increase the size of GC head from 24 to 32 bytes, on 32-bit there is a free place in 16-bytes GC head. However the performance can be not critical here, because in any case repr() creates new object (resulting string). Using thread local hash table can be enough. In any case the patch will be enough complex to target it 3.6 only. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 15:11:25 2015 From: report at bugs.python.org (Alexey Borzenkov) Date: Sun, 01 Nov 2015 20:11:25 +0000 Subject: [issue25531] greenlet header file is missing inside virtualenv In-Reply-To: <1446407383.6.0.829207834021.issue25531@psf.upfronthosting.co.za> Message-ID: <1446408685.19.0.677043739709.issue25531@psf.upfronthosting.co.za> Alexey Borzenkov added the comment: Just wanted to clarify that greenlet.h is not missing in virtualenv, but headers seem to be installed in venv/include/site/python3.5, when only venv/include is considered for includes when building extensions. It is not specific to OSX and it is trivial to reproduce on Linux too. ---------- nosy: +snaury _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 15:27:41 2015 From: report at bugs.python.org (John Hagen) Date: Sun, 01 Nov 2015 20:27:41 +0000 Subject: [issue25521] optparse module does not emit DeprecationWarning In-Reply-To: <1446247354.16.0.386152814173.issue25521@psf.upfronthosting.co.za> Message-ID: <1446409661.56.0.632797990915.issue25521@psf.upfronthosting.co.za> John Hagen added the comment: @martin.panter My new patch fixes Lib/test_optparse.py by suppressing the warning like test_imp does as you suggested. @serhiy.storchaka I don't have a strong preference that it be a DeprecationWarning vs. PendingDeprecationWarning since to me, both get the point across to the end-user to avoid it. I do, however, feel that it is important raise some kind of warning since it seems clear from the docs that is deprecated. In my new patch I changed the type of warning to a PendingDeprecationWarning, as there seems to be at least some notion that optparse is a special case. I don't have a strong opinion about which type of deprecation warning is used. My new patch works when test_optparse.py is run with -Werror on 3.6.0a0. ---------- Added file: http://bugs.python.org/file40921/optparse_and_test_deprecationwarning.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 15:28:02 2015 From: report at bugs.python.org (John Hagen) Date: Sun, 01 Nov 2015 20:28:02 +0000 Subject: [issue25521] optparse module does not emit DeprecationWarning In-Reply-To: <1446247354.16.0.386152814173.issue25521@psf.upfronthosting.co.za> Message-ID: <1446409682.57.0.965808879663.issue25521@psf.upfronthosting.co.za> Changes by John Hagen : Removed file: http://bugs.python.org/file40913/optparse_deprecationwarning.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 16:02:14 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 01 Nov 2015 21:02:14 +0000 Subject: [issue25510] fileinput.FileInput.readline() always returns str object at the end even if in 'rb' mode In-Reply-To: <1446127939.75.0.173725539565.issue25510@psf.upfronthosting.co.za> Message-ID: <1446411734.15.0.209416237156.issue25510@psf.upfronthosting.co.za> R. David Murray added the comment: Ah, I misunderstood the bug report. Yes, this should be OK (I hope :). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 16:08:09 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 01 Nov 2015 21:08:09 +0000 Subject: [issue25446] smtplib.py AUTH LOGIN code messed up sending login and password data since 3.5 In-Reply-To: <1445355692.4.0.944252984253.issue25446@psf.upfronthosting.co.za> Message-ID: <1446412089.93.0.847238096011.issue25446@psf.upfronthosting.co.za> R. David Murray added the comment: I will work on it this week, should have something committed before the end of next weekend. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 16:11:43 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 01 Nov 2015 21:11:43 +0000 Subject: [issue25531] greenlet header file is missing inside virtualenv In-Reply-To: <1446407383.6.0.829207834021.issue25531@psf.upfronthosting.co.za> Message-ID: <1446412303.0.0.12492298734.issue25531@psf.upfronthosting.co.za> R. David Murray added the comment: Greenlet isn't part of python, so what bug in CPython are you reporting? It sounds like you should be reporting this to the greenlet folks. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 16:44:28 2015 From: report at bugs.python.org (Meador Inge) Date: Sun, 01 Nov 2015 21:44:28 +0000 Subject: [issue25083] Python can sometimes create incorrect .pyc files In-Reply-To: <1442143572.78.0.211523310189.issue25083@psf.upfronthosting.co.za> Message-ID: <1446414268.32.0.533566047206.issue25083@psf.upfronthosting.co.za> Meador Inge added the comment: I started poking at the patch a little and have a few comments. My understanding of the issue comments is that the read error actually happens when reading in the *source* file and *not* the bytecode file. This happens because 'ferror' is not checked after receiving an EOF and thus we think we just have an empty source file. I can understand how creating a reproducible test case for this error path would be very difficult. So, checking for errors with 'ferror' definitely seems reasonable, but why do it in the tokenizer code? I already see several places in 'fileobject.c' that do similar checks. For example, in 'get_line' I see: while ( buf != end && (c = GETC(fp)) != EOF ) { ... } if (c == EOF) { if (ferror(fp) && errno == EINTR) { ... } } As such, wouldn't handling this error case directly in 'Py_UniversalNewlineFgets' similar to the above code be more appropriate? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 16:47:18 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 01 Nov 2015 21:47:18 +0000 Subject: [issue25388] tokenizer crash/misbehavior -- heap use-after-free In-Reply-To: <1444706115.92.0.283351483962.issue25388@psf.upfronthosting.co.za> Message-ID: <1446414438.01.0.894746549136.issue25388@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Stack trace: #0 ascii_decode (start=0xa72f2008 "", end=0xfffff891 , dest=) at Objects/unicodeobject.c:4795 #1 0x08100c0f in PyUnicode_DecodeUTF8Stateful (s=s at entry=0xa72f2008 "", size=size at entry=1490081929, errors=errors at entry=0x81f4303 "replace", consumed=consumed at entry=0x0) at Objects/unicodeobject.c:4871 #2 0x081029c7 in PyUnicode_DecodeUTF8 (s=0xa72f2008 "", size=1490081929, errors=errors at entry=0x81f4303 "replace") at Objects/unicodeobject.c:4743 #3 0x0815179a in err_input (err=0xbfffec04) at Python/pythonrun.c:1352 #4 0x081525cf in PyParser_ASTFromFileObject (arena=0x8348118, errcode=0x0, flags=, ps2=0x0, ps1=0x0, start=257, enc=0x0, filename=0xb7950e00, fp=0x8347fb0) at Python/pythonrun.c:1163 #5 PyRun_FileExFlags (fp=0x8347fb0, filename_str=0xb79e2eb8 "vuln.py", start=257, globals=0xb79e3d8c, locals=0xb79e3d8c, closeit=1, flags=0xbfffecec) at Python/pythonrun.c:916 #6 0x08152744 in PyRun_SimpleFileExFlags (fp=0x8347fb0, filename=, closeit=1, flags=0xbfffecec) at Python/pythonrun.c:396 #7 0x08063919 in run_file (p_cf=0xbfffecec, filename=0x82eda10 L"vuln.py", fp=0x8347fb0) at Modules/main.c:318 #8 Py_Main (argc=argc at entry=2, argv=argv at entry=0x82ed008) at Modules/main.c:768 #9 0x0805f345 in main (argc=2, argv=0xbfffee44) at ./Programs/python.c:69 At #2 PyUnicode_DecodeUTF8 is called with s="" and size=1490081929. size is err->offset, and err->offset is set only in parsetok() in Parser/parsetok.c. This is the tokenizer bug. Minimal reproducer: ./python -c 'with open("vuln.py", "wb") as f: f.write(b"\x7f\x00\n\xfd\n") ./python vuln.py The crash is gone if comment out the code at the end of decoding_fgets() that tests UTF-8. ---------- nosy: +benjamin.peterson, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 16:49:24 2015 From: report at bugs.python.org (Chris Angelico) Date: Sun, 01 Nov 2015 21:49:24 +0000 Subject: [issue25446] smtplib.py AUTH LOGIN code messed up sending login and password data since 3.5 In-Reply-To: <1445355692.4.0.944252984253.issue25446@psf.upfronthosting.co.za> Message-ID: <1446414564.53.0.420599930305.issue25446@psf.upfronthosting.co.za> Changes by Chris Angelico : ---------- nosy: +Rosuav _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 16:53:55 2015 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 01 Nov 2015 21:53:55 +0000 Subject: [issue25474] Weird behavior when setting f_trace in a context manager In-Reply-To: <1445774698.38.0.095988844457.issue25474@psf.upfronthosting.co.za> Message-ID: <1446414835.26.0.419078966805.issue25474@psf.upfronthosting.co.za> Xavier de Gaye added the comment: This is an artefact that occurs as the result of raising an exception in the local trace function. Disassembling the first case of failure of as_context.py with the attached script gives the following: 9 0 LOAD_GLOBAL 0 (context) 3 CALL_FUNCTION 0 (0 positional, 0 keyword pair) 6 SETUP_WITH 20 (to 29) 10 9 STORE_FAST 0 (two) 11 12 LOAD_GLOBAL 1 (print) 15 LOAD_CONST 1 ('two') 18 LOAD_FAST 0 (two) 21 CALL_FUNCTION 2 (2 positional, 0 keyword pair) 24 POP_TOP 25 POP_BLOCK 26 LOAD_CONST 0 (None) >> 29 WITH_CLEANUP 30 END_FINALLY 12 31 LOAD_GLOBAL 1 (print) 34 LOAD_CONST 2 ('TWO') 37 LOAD_FAST 0 (two) 40 CALL_FUNCTION 2 (2 positional, 0 keyword pair) 43 POP_TOP 44 LOAD_CONST 0 (None) 47 RETURN_VALUE The __raise() local trace function is invoked on line 10 upon executing the STORE_FAST bytecode (this can be confirmed by running foo() under the control of pdb). The exception raised by __raise() causes the assignement to 'two' to fail, hence the tracebacks in as_context.py. This does not seem to be a bug in python. ---------- nosy: +xdegaye Added file: http://bugs.python.org/file40922/as_context_dis.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 17:21:57 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 01 Nov 2015 22:21:57 +0000 Subject: [issue25521] optparse module does not emit DeprecationWarning In-Reply-To: <1446247354.16.0.386152814173.issue25521@psf.upfronthosting.co.za> Message-ID: <1446416517.56.0.340224568723.issue25521@psf.upfronthosting.co.za> Martin Panter added the comment: Serhiy, do you have a link or more information about this decision? Looking around at previous discussions, this is what I found: limiting to pending deprecation: ; not bothering with any code warning: . But the PEP was never updated as suggested in that last thread. FWIW I have never used optparse. I do find argparse useful, but having bugs due to being ?powerful? is not necessarily a good thing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 17:40:16 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 01 Nov 2015 22:40:16 +0000 Subject: [issue25464] Tix HList header_exists should be "exist" In-Reply-To: <1445555946.1.0.542845821493.issue25464@psf.upfronthosting.co.za> Message-ID: <1446417616.25.0.934078056774.issue25464@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I agree. Leave the name 'header_exists', consistent with all others, pass 'exist', and add a comment. Optional: report the bug upstream if there are tix maintainers somewhere. Serhiy, my question about the status of tix is really whether I can use it in IDLE, since it is not now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 18:00:52 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 01 Nov 2015 23:00:52 +0000 Subject: [issue25464] Tix HList header_exists should be "exist" In-Reply-To: <1445555946.1.0.542845821493.issue25464@psf.upfronthosting.co.za> Message-ID: <1446418852.16.0.504145505589.issue25464@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > Serhiy, my question about the status of tix is really whether I can use it in IDLE, since it is not now. I can't say anything. But be aware that Tix is optional and likely is not installed on Linux. Maintainers should add new dependence to IDLE package in every distribution. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 18:07:40 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 01 Nov 2015 23:07:40 +0000 Subject: [issue25521] optparse module does not emit DeprecationWarning In-Reply-To: <1446247354.16.0.386152814173.issue25521@psf.upfronthosting.co.za> Message-ID: <1446419260.96.0.708605608262.issue25521@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: No, I have not more information. My supposition is based on indirect evidence in msg225052. I suppose there was more recent discussion in 2014. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 18:50:18 2015 From: report at bugs.python.org (Chris Withers) Date: Sun, 01 Nov 2015 23:50:18 +0000 Subject: [issue25532] infinite loop when running inspect.unwrap over unittest.mock.call Message-ID: <1446421817.99.0.495650724157.issue25532@psf.upfronthosting.co.za> New submission from Chris Withers: The following results in an infinite loop: >>> from inspect import unwrap >>> from unittest.mock import call >>> unwrap(call) This can occur when you use doctest.DocTestSuite to load doc tests from a module where unittest.mock.call has been imported. ---------- components: Library (Lib) keywords: 3.5regression messages: 253885 nosy: cjw296, michael.foord, ncoghlan, yselivanov priority: normal severity: normal status: open title: infinite loop when running inspect.unwrap over unittest.mock.call versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 18:50:21 2015 From: report at bugs.python.org (Joshua Bronson) Date: Sun, 01 Nov 2015 23:50:21 +0000 Subject: [issue25243] decouple string-to-boolean logic from ConfigParser.getboolean and offer as separate function In-Reply-To: <1443307220.16.0.776749230814.issue25243@psf.upfronthosting.co.za> Message-ID: <1446421821.06.0.637302082911.issue25243@psf.upfronthosting.co.za> Joshua Bronson added the comment: My friend @novalis_dt and I worked up a patch for this including tests (attached). First time working with the CPython codebase but hope it's a reasonable start. Here's a preview: ~> ./python.exe Python 3.6.0a0 (default:9f8b5053e30d+, Nov 1 2015, 18:38:37) [GCC 4.2.1 Compatible Apple LLVM 7.0.0 (clang-700.1.76)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> trues = ['true', 'yes', 'on', '1'] >>> [bool.from_config_str(i) for i in trues] [True, True, True, True] >>> falses = ['false', 'no', 'off', '0', ''] >>> [bool.from_config_str(i) for i in falses] [False, False, False, False, False] I would be happy to try to make any additional changes necessary (including changing ConfigParser.getboolean to use the new method) if there is interest. Thanks! ---------- keywords: +patch nosy: +novalis_dt Added file: http://bugs.python.org/file40923/bool_from_config_str.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 18:54:21 2015 From: report at bugs.python.org (Chris Withers) Date: Sun, 01 Nov 2015 23:54:21 +0000 Subject: [issue25532] infinite loop when running inspect.unwrap over unittest.mock.call In-Reply-To: <1446421817.99.0.495650724157.issue25532@psf.upfronthosting.co.za> Message-ID: <1446422061.52.0.857294274427.issue25532@psf.upfronthosting.co.za> Chris Withers added the comment: A naive solution is to chat unittest.mock._Call's __getattr__ to be as follows: def __getattr__(self, attr): if attr == '__wrapped__': raise AttributeError('__wrapped__') if self.name is None: return _Call(name=attr, from_kall=False) name = '%s.%s' % (self.name, attr) return _Call(name=name, parent=self, from_kall=False) ...but I'm not sure that's the right thing to do. inspect.unwrap is trying to catch this loop, but the implementation fails for cases where f.__wrapped__ is generative, as in the case of Mock and _Call. I suspect both modules need a fix, but not sure what best to suggest. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 19:46:42 2015 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 02 Nov 2015 00:46:42 +0000 Subject: [issue23749] asyncio missing wrap_socket (starttls) In-Reply-To: <1427119199.61.0.485462184824.issue23749@psf.upfronthosting.co.za> Message-ID: <1446425202.26.0.884782326408.issue23749@psf.upfronthosting.co.za> Yury Selivanov added the comment: Guido, Victor, any thoughts about the (proto-)patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 20:24:45 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 02 Nov 2015 01:24:45 +0000 Subject: [issue25521] optparse module does not emit DeprecationWarning In-Reply-To: <1446247354.16.0.386152814173.issue25521@psf.upfronthosting.co.za> Message-ID: <1446427485.11.0.72164824065.issue25521@psf.upfronthosting.co.za> R. David Murray added the comment: I can't remember the timing...was that PEP accepted before we made DeprecationWarnings off by default? It sounds like it probably was, based on the phrasing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 20:28:43 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 02 Nov 2015 01:28:43 +0000 Subject: [issue25521] optparse module does not emit DeprecationWarning In-Reply-To: <1446247354.16.0.386152814173.issue25521@psf.upfronthosting.co.za> Message-ID: <1446427723.31.0.405816998304.issue25521@psf.upfronthosting.co.za> R. David Murray added the comment: Oh, and as far as bugs because it is powerful...optparse has had time to have its bugs fixed, so having bugs in the newer features of argparse is not surprising, really. We just need to get the fixes committed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 20:37:16 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 02 Nov 2015 01:37:16 +0000 Subject: [issue25464] Tix HList header_exists should be "exist" In-Reply-To: <1445555946.1.0.542845821493.issue25464@psf.upfronthosting.co.za> Message-ID: <1446428236.68.0.02012126108.issue25464@psf.upfronthosting.co.za> Terry J. Reedy added the comment: If tkinter and IDLE are some places installed without tix, then it it not usable. What about the suggestion for a revised patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 22:36:18 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 02 Nov 2015 03:36:18 +0000 Subject: [issue18010] pydoc search chokes on import errors In-Reply-To: <1368896719.35.0.915741072389.issue18010@psf.upfronthosting.co.za> Message-ID: <1446435378.06.0.926155213332.issue18010@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a test case. I had to insert a temporary directory into sys.path, based off my patch in Issue 25184. Let me know if it doesn?t look too evil :) ---------- nosy: +martin.panter stage: test needed -> patch review Added file: http://bugs.python.org/file40924/pydoc_search_onerror.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 23:29:19 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 02 Nov 2015 04:29:19 +0000 Subject: [issue25523] Correct "a" article to "an" article In-Reply-To: <1446294729.19.0.0593417180133.issue25523@psf.upfronthosting.co.za> Message-ID: <20151102042915.12527.52328@psf.io> Roundup Robot added the comment: New changeset d8ff13414deb by Martin Panter in branch '3.4': Issue #25523: Correct "a" article to "an" article https://hg.python.org/cpython/rev/d8ff13414deb New changeset e279ab6753fd by Martin Panter in branch '3.5': Issue #25523: Merge "a" to "an" fixes from 3.4 into 3.5 https://hg.python.org/cpython/rev/e279ab6753fd New changeset 2347271172b3 by Martin Panter in branch '3.5': Issue #25523: Further a-to-an corrections new in 3.5 https://hg.python.org/cpython/rev/2347271172b3 New changeset 96e61bb7f6e9 by Martin Panter in branch 'default': Issue #25523: Merge a-to-an corrections from 3.5 https://hg.python.org/cpython/rev/96e61bb7f6e9 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 1 23:34:04 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 02 Nov 2015 04:34:04 +0000 Subject: [issue25523] Correct "a" article to "an" article In-Reply-To: <1446294729.19.0.0593417180133.issue25523@psf.upfronthosting.co.za> Message-ID: <1446438844.37.0.965983516724.issue25523@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 00:40:03 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 02 Nov 2015 05:40:03 +0000 Subject: [issue24379] operator.subscript In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za> Message-ID: <20151102054000.80232.98714@psf.io> Roundup Robot added the comment: New changeset 83fa2e9b0038 by Raymond Hettinger in branch 'default': Issue #24379: Revert the operator.subscript patch (dccc4e63aef5) pending resolution of the related refcnt leak. https://hg.python.org/cpython/rev/83fa2e9b0038 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 00:53:44 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 02 Nov 2015 05:53:44 +0000 Subject: [issue24931] _asdict breaks when inheriting from a namedtuple In-Reply-To: <1440460188.11.0.136200791288.issue24931@psf.upfronthosting.co.za> Message-ID: <1446443624.6.0.212639492019.issue24931@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 01:03:01 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 02 Nov 2015 06:03:01 +0000 Subject: [issue24379] operator.subscript In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za> Message-ID: <1446444181.4.0.440068931171.issue24379@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: rhettinger -> priority: high -> normal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 01:58:55 2015 From: report at bugs.python.org (Alexander Mohr) Date: Mon, 02 Nov 2015 06:58:55 +0000 Subject: [issue14119] Ability to adjust queue size in Executors In-Reply-To: <1330129142.34.0.452763799677.issue14119@psf.upfronthosting.co.za> Message-ID: <1446447535.38.0.561541790723.issue14119@psf.upfronthosting.co.za> Alexander Mohr added the comment: adding support for internal queue size is critical to avoid chewing through all your memory when you have a LOT of tasks. I just hit this issue myself. If we could have a simple parameter to set the max queue size this would help tremendously! ---------- nosy: +thehesiod _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 02:34:13 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 02 Nov 2015 07:34:13 +0000 Subject: [issue25523] Correct "a" article to "an" article In-Reply-To: <1446294729.19.0.0593417180133.issue25523@psf.upfronthosting.co.za> Message-ID: <1446449653.76.0.962938097227.issue25523@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch with additional changes. ---------- resolution: fixed -> stage: resolved -> patch review status: closed -> open Added file: http://bugs.python.org/file40925/a-an_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 02:34:28 2015 From: report at bugs.python.org (Jon Snoo) Date: Mon, 02 Nov 2015 07:34:28 +0000 Subject: [issue19407] PEP 453: update the "Installing Python Modules" documentation In-Reply-To: <1382791475.83.0.387983167617.issue19407@psf.upfronthosting.co.za> Message-ID: <1446449668.47.0.35268059829.issue19407@psf.upfronthosting.co.za> Jon Snoo added the comment: The link to the "quick recommendations section" in the Python 2.7 and 3.3 docs is broken. It appears that the PPUG has changed the path from https://python-packaging-user-guide.readthedocs.org/en/latest/current.html to https://python-packaging-user-guide.readthedocs.org/en/latest/current/ Also, should the "Installing Python Modules" in Python 2.7.9 and 2.7.10 be the same as the one in Python 3.4? After all, pip is included in Python 2.7.9+, isn't it? ---------- nosy: +Jon Snoo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 02:42:45 2015 From: report at bugs.python.org (Kracekumar Ramaraj) Date: Mon, 02 Nov 2015 07:42:45 +0000 Subject: [issue25531] greenlet header file is missing inside virtualenv In-Reply-To: <1446407383.6.0.829207834021.issue25531@psf.upfronthosting.co.za> Message-ID: <1446450165.98.0.213794085767.issue25531@psf.upfronthosting.co.za> Kracekumar Ramaraj added the comment: I have attached the link to greenlet issue as well. The issue seems to be with distutils/setuptools. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 02:48:54 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 02 Nov 2015 07:48:54 +0000 Subject: [issue24379] operator.subscript In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za> Message-ID: <1446450534.25.0.18919519243.issue24379@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The are is a reference loop: global instance -> type -> method -> module globals -> global instance Since an instance doesn't have GC head if __slots__ is empty, the loop can't be broken. A workaround is to add a stub element to __slots__: __slots__ = ('__stub__',) But operator.subscript is not the only class that causes a reference leak. Any class with empty __slots__ can create a loop and cause a leak. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 03:03:57 2015 From: report at bugs.python.org (Fred Gansevles) Date: Mon, 02 Nov 2015 08:03:57 +0000 Subject: [issue25474] Weird behavior when setting f_trace in a context manager In-Reply-To: <1445774698.38.0.095988844457.issue25474@psf.upfronthosting.co.za> Message-ID: <1446451437.81.0.272492697543.issue25474@psf.upfronthosting.co.za> Fred Gansevles added the comment: Xavier, thanks for looking at my post. But, since all six invocations of the context manager are the same - I did an 'ast.parse' and 'ast.dump' and the the six calls were *exactly* the same (save lineno and col_offset) - why does 'zero', 'one', 'four' and 'five' get assigned but 'two' and 'three' not ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 04:47:46 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 02 Nov 2015 09:47:46 +0000 Subject: [issue25523] Correct "a" article to "an" article In-Reply-To: <1446294729.19.0.0593417180133.issue25523@psf.upfronthosting.co.za> Message-ID: <1446457666.77.0.552751328495.issue25523@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks Serhiy. My pass over the files missed most cases where there was a line break involved, and certain punctuation and markup, which you picked up on. I skipped the /Lib/msilib/schema.py file in my patch because it was part of the data rather than a comment, and I wasn?t sure what it is for. It seems to be a generated file from some Windows source. But I see other people have made similar corrections, so it might be okay. I left a couple of comments. Apart from those, the rest look good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 04:58:50 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 02 Nov 2015 09:58:50 +0000 Subject: [issue24379] operator.subscript In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za> Message-ID: <1446458330.08.0.191363715338.issue24379@psf.upfronthosting.co.za> Martin Panter added the comment: On the mailing list, Antoine also suggested removing __slots__ completely as another workaround. I agree that it doesn?t seem important for a singleton, though in the review comments a couple people seemed to want __slots__. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 05:31:16 2015 From: report at bugs.python.org (Michael Foord) Date: Mon, 02 Nov 2015 10:31:16 +0000 Subject: [issue25532] infinite loop when running inspect.unwrap over unittest.mock.call In-Reply-To: <1446421817.99.0.495650724157.issue25532@psf.upfronthosting.co.za> Message-ID: <1446460276.51.0.573645210782.issue25532@psf.upfronthosting.co.za> Michael Foord added the comment: For mock I think your proposed fix is fine. call is particularly magic as merely importing it into modules can cause introspection problems like this (venusian is a third party library that has a similar issue), so working around these problems as they arise is worthwhile. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 06:09:25 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 02 Nov 2015 11:09:25 +0000 Subject: [issue2466] os.path.ismount doesn't work for mounts the user doesn't have permission to see In-Reply-To: <1206293428.96.0.660613140218.issue2466@psf.upfronthosting.co.za> Message-ID: <1446462565.88.0.158059970221.issue2466@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the patch, Robin. The patch needs a test case. See Lib/test/test_posixpath.py. The test coverage of ismount() is not high, so we need more tests. Also, I don't have much time to work on this right now, but Antoine's suggestion in msg71294 sounds good to me. Did you try it? ---------- nosy: +berker.peksag stage: -> patch review versions: -Python 2.6, Python 3.0, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 06:14:13 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 02 Nov 2015 11:14:13 +0000 Subject: [issue25533] Make pkgutil.iter_modules() yield built-in modules Message-ID: <1446462853.43.0.928344730721.issue25533@psf.upfronthosting.co.za> New submission from Martin Panter: When no specific list of paths are given, pkgutil.iter_modules() and walk_packages() will list modules found on sys.path. But they don?t list built-in modules, which don?t live in a particular directory. So many users of these APIs (such as the ModuleScanner class in pydoc) have to separately iterate over sys.builtin_module_names. I think it would be good to change the pkgutil module to also yield the builtin modules. Attached is a patch which does this. However I had second thoughts on blindly changing the existing function to yield the extra modules, because this will hurt backward compatibility for people already working around the problem. For example, if I didn?t also update pydoc in my patch, a module search would list the built-in modules twice. Perhaps we could overcome this with an opt-in flag like iter_modules(builtins=True)? I?m interested if anyone else has an opinion on this. Adding support for builtins could also help with proposals such as listing the entire library (Issue 20506) and autocompletion of module names (Issue 25419). ---------- components: Library (Lib) files: iter-builtin.patch keywords: patch messages: 253905 nosy: martin.panter priority: normal severity: normal status: open title: Make pkgutil.iter_modules() yield built-in modules type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file40926/iter-builtin.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 06:27:45 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 02 Nov 2015 11:27:45 +0000 Subject: [issue22450] urllib doesn't put Accept: */* in the headers In-Reply-To: <1411257032.38.0.526589346468.issue22450@psf.upfronthosting.co.za> Message-ID: <1446463665.51.0.492695651715.issue22450@psf.upfronthosting.co.za> Martin Panter added the comment: The Curl programmer replied basically saying there was no scientific reason, but since Curl was previously sending a custom Accept header, it was safer to leave a bare-bones Accept header in than completely remove it. Plus he thought it might be slighly more compatible with websites. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 07:42:07 2015 From: report at bugs.python.org (Alex Gaynor) Date: Mon, 02 Nov 2015 12:42:07 +0000 Subject: [issue25530] ssl: OP_NO_SSLv3 should always be set unless a user specifically asks for it In-Reply-To: <1446405054.12.0.603454420685.issue25530@psf.upfronthosting.co.za> Message-ID: <1446468127.45.0.307099684527.issue25530@psf.upfronthosting.co.za> Alex Gaynor added the comment: Oops, there were a few failing tests on that patch. New one is green ---------- Added file: http://bugs.python.org/file40927/sslv3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 08:07:10 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 02 Nov 2015 13:07:10 +0000 Subject: [issue25523] Correct "a" article to "an" article In-Reply-To: <1446294729.19.0.0593417180133.issue25523@psf.upfronthosting.co.za> Message-ID: <20151102130706.504.2452@psf.io> Roundup Robot added the comment: New changeset 75df8b0a2cd1 by Serhiy Storchaka in branch '3.4': Issue #25523: Further a-to-an corrections. https://hg.python.org/cpython/rev/75df8b0a2cd1 New changeset 68edc7baeef7 by Serhiy Storchaka in branch '3.5': Issue #25523: Merge a-to-an corrections from 3.4. https://hg.python.org/cpython/rev/68edc7baeef7 New changeset a0d0f968b020 by Serhiy Storchaka in branch '3.5': Issue #25523: Further a-to-an corrections new in 3.5. https://hg.python.org/cpython/rev/a0d0f968b020 New changeset 72cca30f4707 by Serhiy Storchaka in branch 'default': Issue #25523: Merge a-to-an corrections from 3.5. https://hg.python.org/cpython/rev/72cca30f4707 New changeset e8f3c011e2b4 by Serhiy Storchaka in branch '2.7': Issue #25523: Backported a-to-an corrections. https://hg.python.org/cpython/rev/e8f3c011e2b4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 08:26:47 2015 From: report at bugs.python.org (Alun Champion) Date: Mon, 02 Nov 2015 13:26:47 +0000 Subject: [issue25193] itertools.accumulate should have an optional initializer argument In-Reply-To: <1442738800.12.0.18115193144.issue25193@psf.upfronthosting.co.za> Message-ID: <1446470807.46.0.61852508041.issue25193@psf.upfronthosting.co.za> Alun Champion added the comment: Understandable, though it would have also made the first order recurrence relationships more accurate, e.g. annualized interest on an initial balance: accumulate(repeat(None), lambda: bal, _: bal*1.05, initializer=1000) vs. artificially repeating 1000: accumulate(repeat(1000), lambda: bal, _: bal*1.05) Or, if the initialiser is expensive: accumulate(chain([1000], repeat(None)), lambda: bal, _: bal*1.05) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 08:30:15 2015 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 02 Nov 2015 13:30:15 +0000 Subject: [issue25483] Improve f-string implementation: FORMAT_VALUE opcode In-Reply-To: <1445874299.22.0.773155754186.issue25483@psf.upfronthosting.co.za> Message-ID: <1446471015.26.0.726215638878.issue25483@psf.upfronthosting.co.za> Eric V. Smith added the comment: Some formatting improvements. I removed one of the optimizations I was doing, because it's also done in PyObject_Format(). I plan on moving other optimizations into PyObject_Format(), but I'll open a separate issue for that. I swapped the order of the parameters on the stack, so that I could use the micro-optimization of TOP() and SET_TOP(). I'll commit this shortly. ---------- Added file: http://bugs.python.org/file40928/format-opcode-3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 08:37:26 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 02 Nov 2015 13:37:26 +0000 Subject: [issue25523] Correct "a" article to "an" article In-Reply-To: <1446294729.19.0.0593417180133.issue25523@psf.upfronthosting.co.za> Message-ID: <1446471446.2.0.68499035096.issue25523@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Martin for your review. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 08:49:23 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 02 Nov 2015 13:49:23 +0000 Subject: [issue25483] Improve f-string implementation: FORMAT_VALUE opcode In-Reply-To: <1445874299.22.0.773155754186.issue25483@psf.upfronthosting.co.za> Message-ID: <1446472163.19.0.00709778025865.issue25483@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It looks to me that FVS_MASK and FVS_HAVE_SPEC are duplicates. FVS_HAVE_SPEC is set but FVS_MASK is tested. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 09:01:07 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 02 Nov 2015 14:01:07 +0000 Subject: [issue25531] greenlet header file is missing inside virtualenv In-Reply-To: <1446407383.6.0.829207834021.issue25531@psf.upfronthosting.co.za> Message-ID: <1446472867.17.0.788427139389.issue25531@psf.upfronthosting.co.za> R. David Murray added the comment: I don't see a link to a greenlet issue, and setuptools is not maintained as part of the stdlib. It sounds like we should close this until and if the greenlet project can point us to a specific problem with the stdlib distutils. ---------- resolution: -> third party status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 09:04:34 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 02 Nov 2015 14:04:34 +0000 Subject: [issue25533] Make pkgutil.iter_modules() yield built-in modules In-Reply-To: <1446462853.43.0.928344730721.issue25533@psf.upfronthosting.co.za> Message-ID: <1446473074.35.0.326335328151.issue25533@psf.upfronthosting.co.za> R. David Murray added the comment: IMO, definitely this should not be changed by default. An alternative to a boolean flag would be a new function (iter_all_modules?). ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 09:05:22 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 02 Nov 2015 14:05:22 +0000 Subject: [issue25533] Make pkgutil.iter_modules() yield built-in modules In-Reply-To: <1446462853.43.0.928344730721.issue25533@psf.upfronthosting.co.za> Message-ID: <1446473122.72.0.388802750391.issue25533@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 09:10:06 2015 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 02 Nov 2015 14:10:06 +0000 Subject: [issue25483] Improve f-string implementation: FORMAT_VALUE opcode In-Reply-To: <1445874299.22.0.773155754186.issue25483@psf.upfronthosting.co.za> Message-ID: <1446473406.6.0.720995593356.issue25483@psf.upfronthosting.co.za> Eric V. Smith added the comment: Right, they're the same because it's a single bit. You 'and' with a mask to get the bits you want, and you 'or' together the values. It's an old habit left over from my bit-twiddling days. I guess the test could really be: have_fmt_spec = (oparg & FVS_MASK) == FVS_HAVE_SPEC; to make it more clear what I'm doing. It's easier to see the same thing with the FVC_MASK and FVC_* values, since that field is multiple bits. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 09:11:28 2015 From: report at bugs.python.org (Kracekumar Ramaraj) Date: Mon, 02 Nov 2015 14:11:28 +0000 Subject: [issue25531] greenlet header file is missing inside virtualenv In-Reply-To: <1446407383.6.0.829207834021.issue25531@psf.upfronthosting.co.za> Message-ID: <1446473488.61.0.577492748064.issue25531@psf.upfronthosting.co.za> Kracekumar Ramaraj added the comment: Link to greenlet issue: https://github.com/python-greenlet/greenlet/issues/96 ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 09:22:44 2015 From: report at bugs.python.org (Kracekumar Ramaraj) Date: Mon, 02 Nov 2015 14:22:44 +0000 Subject: [issue25531] greenlet header file is missing inside virtualenv In-Reply-To: <1446407383.6.0.829207834021.issue25531@psf.upfronthosting.co.za> Message-ID: <1446474164.73.0.912948469585.issue25531@psf.upfronthosting.co.za> Kracekumar Ramaraj added the comment: I have created an issue in setuptools repo: https://bitbucket.org/pypa/setuptools/issues/455/unable-to-build-extension-in-python-35. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 09:33:18 2015 From: report at bugs.python.org (Mouse) Date: Mon, 02 Nov 2015 14:33:18 +0000 Subject: [issue25495] binascii documentation incorrect In-Reply-To: <1445987417.55.0.122139453671.issue25495@psf.upfronthosting.co.za> Message-ID: <1446474798.0.0.63556880211.issue25495@psf.upfronthosting.co.za> Mouse added the comment: 1. I concede knowing nothing about the early Python library implementation, functionality, or even purpose. 2. I don't think it makes sense now to either refer to PEM. We'd be two decades too late for that (well, 27 years, to be precise :). See https://en.wikipedia.org/wiki/Privacy-enhanced_Electronic_Mail 3. I don't think we are in position to tell programmers how to split a string of characters into 76-long chunks. Not to mention that the example you gave is likely to suffer in performance (just count those function calls), compared to other methods, and won't reflect well on the authors. Here's one possible doc version: ''' Convert binary data to the base 64 encoding defined in :rfc:`4648`. The return value includes a trailing newline ``b"\n"`` if *newline* is true. If the output is used as Base64 transfer encoding for MIME (:rfc: 2045), base 64 output should be broken into lines at most 76 characters long to be compliant. Base64 encoding standard does not limit the maximum encoded line length. ''' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 09:53:04 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 02 Nov 2015 14:53:04 +0000 Subject: [issue25531] greenlet header file is missing inside virtualenv In-Reply-To: <1446407383.6.0.829207834021.issue25531@psf.upfronthosting.co.za> Message-ID: <1446475984.13.0.371546450677.issue25531@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks for the links. I'll leave this open for now since it isn't clear where the problem is. Please update the issue with any additional information you get from setuptools if it looks like a distutils problem, or ping this issue if you get no response there for an extended period. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 09:56:20 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 02 Nov 2015 14:56:20 +0000 Subject: [issue25495] binascii documentation incorrect In-Reply-To: <1445987417.55.0.122139453671.issue25495@psf.upfronthosting.co.za> Message-ID: <1446476180.51.0.409872776513.issue25495@psf.upfronthosting.co.za> R. David Murray added the comment: Add a parenthetical "(57 bytes of the input per line)" and I'll be happy with that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 09:59:49 2015 From: report at bugs.python.org (Mouse) Date: Mon, 02 Nov 2015 14:59:49 +0000 Subject: [issue25495] binascii documentation incorrect In-Reply-To: <1445987417.55.0.122139453671.issue25495@psf.upfronthosting.co.za> Message-ID: <1446476389.83.0.0702750914761.issue25495@psf.upfronthosting.co.za> Mouse added the comment: Let's not insinuate anything about the input. This is about what constraints on the OUTPUT MAY be there, not a tutorial from the 80-ties on how one might accomplish it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 10:00:46 2015 From: report at bugs.python.org (Mouse) Date: Mon, 02 Nov 2015 15:00:46 +0000 Subject: [issue25495] binascii documentation incorrect In-Reply-To: <1445987417.55.0.122139453671.issue25495@psf.upfronthosting.co.za> Message-ID: <1446476446.42.0.637486883291.issue25495@psf.upfronthosting.co.za> Mouse added the comment: And even those constraints depend on the use. E.g. X.509 does not have those. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 10:11:43 2015 From: report at bugs.python.org (Xavier de Gaye) Date: Mon, 02 Nov 2015 15:11:43 +0000 Subject: [issue25474] Weird behavior when setting f_trace in a context manager In-Reply-To: <1445774698.38.0.095988844457.issue25474@psf.upfronthosting.co.za> Message-ID: <1446477103.66.0.0355392260299.issue25474@psf.upfronthosting.co.za> Xavier de Gaye added the comment: The difference lies in the line numbers. When tracing lines, the interpreter operates on the basis of physical lines, not logical lines (https://docs.python.org/3/reference/lexical_analysis.html#line-structure). The local trace function is called on the first instruction of each physical line (see the comment in maybe_call_line_trace() in Python/ceval.c). In the first case of as_context.py, the 'zero' case, we have: 25 74 SETUP_EXCEPT 49 (to 126) 27 77 LOAD_NAME 6 (Context) 80 CALL_FUNCTION 0 (0 positional, 0 keyword pair) 83 SETUP_WITH 20 (to 106) 86 STORE_NAME 7 (zero) 28 89 LOAD_NAME 8 (print) 92 LOAD_CONST 5 ('zero') 95 LOAD_NAME 7 (zero) ... After 'CALL_FUNCTION' has been run and the trace function set up, the __raise() local trace function is invoked for the first time upon running the 'LOAD_NAME' instruction, since 'SETUP_WITH' and 'STORE_NAME' are not the first instruction of line 27. In the 'two' case, we have: 41 >> 214 SETUP_EXCEPT 49 (to 266) 42 217 LOAD_NAME 6 (Context) 220 CALL_FUNCTION 0 (0 positional, 0 keyword pair) 223 SETUP_WITH 20 (to 246) 43 226 STORE_NAME 11 (two) 44 229 LOAD_NAME 8 (print) 232 LOAD_CONST 9 ('two') 235 LOAD_NAME 11 (two) .... Here the __raise() local trace function is invoked for the first time upon running the 'STORE_NAME' instruction. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 10:15:52 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 02 Nov 2015 15:15:52 +0000 Subject: [issue25495] binascii documentation incorrect In-Reply-To: <1445987417.55.0.122139453671.issue25495@psf.upfronthosting.co.za> Message-ID: <1446477352.14.0.205484414314.issue25495@psf.upfronthosting.co.za> R. David Murray added the comment: Please take a look at the Examples section of this: http://perldoc.perl.org/MIME/Base64.html Looks kind of like Martin's suggestion :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 10:26:51 2015 From: report at bugs.python.org (Stefan Krah) Date: Mon, 02 Nov 2015 15:26:51 +0000 Subject: [issue25525] Deallocation scheme for memoryview is unsafe In-Reply-To: <1446318862.67.0.0722395026507.issue25525@psf.upfronthosting.co.za> Message-ID: <1446478011.24.0.0199937444041.issue25525@psf.upfronthosting.co.za> Stefan Krah added the comment: Thanks, no big problem. The thing is that the parts I wrote (Modules/_decimal/*, Objects/memoryobject.c, Modules/_testbuffer.c) have been audited rather heavily and have 100% code coverage with a privately maintained patch that inserts allocation failures. There are even tests in test_memoryview() / test_buffer() for breaking up reference cycles. So I'd really prefer not to have things labeled as potential issues when there are none. That also applies to the PyMem_NEW() "potential overflow" fix in _testbuffer.c where overflow was impossible. Thus, I'll probably revert that at some point, not out of hostility, but just because it's not my approach to software development (in the _testbuffer case, I view the 'len' parameter as a constrained type in the Ada sense where 0 <= len <= ndim = 64). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 10:35:17 2015 From: report at bugs.python.org (Sean Wang) Date: Mon, 02 Nov 2015 15:35:17 +0000 Subject: [issue25534] SimpleHTTPServer throwed an exception due to negtive st_mtime attr in file Message-ID: <1446478517.38.0.562445062137.issue25534@psf.upfronthosting.co.za> New submission from Sean Wang: I transfered a file from remote Debian host to my local Windows 10 host using SecureFX. I found that the file's last modifed date was ?1900?/?1?/1????0:00:00 on Windows. I tried to serve this file to be downloaded, and it crashed as follows: Exception happened during processing of request from ('192.168.1.102', 50978) Traceback (most recent call last): File "C:\Python27\lib\SocketServer.py", line 295, in _handle_request_noblock self.process_request(request, client_address) File "C:\Python27\lib\SocketServer.py", line 321, in process_request self.finish_request(request, client_address) File "C:\Python27\lib\SocketServer.py", line 334, in finish_request self.RequestHandlerClass(request, client_address, self) File "C:\Python27\lib\SocketServer.py", line 655, in __init__ self.handle() File "C:\Python27\lib\BaseHTTPServer.py", line 340, in handle self.handle_one_request() File "C:\Python27\lib\BaseHTTPServer.py", line 328, in handle_one_request method() File "C:\Python27\lib\SimpleHTTPServer.py", line 45, in do_GET f = self.send_head() File "C:\Python27\lib\SimpleHTTPServer.py", line 103, in send_head self.send_header("Last-Modified", self.date_time_string(fs.st_mtime)) File "C:\Python27\lib\BaseHTTPServer.py", line 468, in date_time_string year, month, day, hh, mm, ss, wd, y, z = time.gmtime(timestamp) ValueError: (22, 'Invalid argument') I have checked the source code, and found it was because of the last modifed date of the file, I got this in console: >>> os.fstat(f.fileno()) nt.stat_result(st_mode=33206, st_ino=4785074604093500L, st_dev=0L, st_nlink=1, st_uid=0, st_gid=0, st_size=3406L, st_atime=1446477520L, st_mtime=-2209017600L, st_ctime=1446370767L) -2209017600L cannot be handled by "time.gmtime()" method and it throwed error ---------- components: Library (Lib) messages: 253926 nosy: Sean.Wang priority: normal severity: normal status: open title: SimpleHTTPServer throwed an exception due to negtive st_mtime attr in file type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 10:38:20 2015 From: report at bugs.python.org (Sean Wang) Date: Mon, 02 Nov 2015 15:38:20 +0000 Subject: [issue25534] SimpleHTTPServer throwed an exception due to negtive st_mtime attr in file In-Reply-To: <1446478517.38.0.562445062137.issue25534@psf.upfronthosting.co.za> Message-ID: <1446478700.47.0.082280546466.issue25534@psf.upfronthosting.co.za> Sean Wang added the comment: upload a sample test file ---------- Added file: http://bugs.python.org/file40929/test _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 10:50:25 2015 From: report at bugs.python.org (Stefan Krah) Date: Mon, 02 Nov 2015 15:50:25 +0000 Subject: [issue25483] Improve f-string implementation: FORMAT_VALUE opcode In-Reply-To: <1445874299.22.0.773155754186.issue25483@psf.upfronthosting.co.za> Message-ID: <1446479425.97.0.145792002232.issue25483@psf.upfronthosting.co.za> Stefan Krah added the comment: The MASK idiom is nice and I think it's good to be exposed to it from time to time. ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 10:52:13 2015 From: report at bugs.python.org (Fred Gansevles) Date: Mon, 02 Nov 2015 15:52:13 +0000 Subject: [issue25474] Weird behavior when setting f_trace in a context manager In-Reply-To: <1445774698.38.0.095988844457.issue25474@psf.upfronthosting.co.za> Message-ID: <1446479533.32.0.00375640044374.issue25474@psf.upfronthosting.co.za> Fred Gansevles added the comment: Xavier, thanks! you found it. If I look the code again, I see that with zero, one, four and five the context-manager (i.e. Context()) and the target (one .. five) are on the same code-line In the case of two and three they are on a different line. Now, with the dependency of the trace function on the *physical line* it all make sense. Fred. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 11:35:19 2015 From: report at bugs.python.org (Rob Malouf) Date: Mon, 02 Nov 2015 16:35:19 +0000 Subject: [issue25535] collections.Counter methods return Counter objects Message-ID: <1446482119.59.0.839988363019.issue25535@psf.upfronthosting.co.za> New submission from Rob Malouf: Several collections.Counter methods return Counter objects, which is leads to wrong or at least confusing behavior when Counter is subclassed. For example, nltk.FreqDist is a subclass of Counter: >>> x = nltk.FreqDist(['a','a','b','b','b']) >>> y = nltk.FreqDist(['b','b','b','b','b']) >>> z = x + y >>> z.__class__ This applies to __add__(), __sub__(), __or__(), __and__(), __pos__(), and __neg__(). In contrast, the copy() method does (what I think is) the right thing: >>> x.copy().__class__ ---------- components: Library (Lib) messages: 253930 nosy: rmalouf priority: normal severity: normal status: open title: collections.Counter methods return Counter objects type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 11:55:19 2015 From: report at bugs.python.org (Akira Li) Date: Mon, 02 Nov 2015 16:55:19 +0000 Subject: [issue25536] use sys.platform instead of os.name in asyncio docs consistently Message-ID: <1446483319.57.0.76121078527.issue25536@psf.upfronthosting.co.za> New submission from Akira Li: asyncio code uses "sys.platform == 'win32'" to detect OS. asyncio docs use both os.name and sys.platform. As far as I can tell there is no *practical* difference between "os.name == 'nt" and "sys.platform == 'win32'" for choosing asyncio.ProactorEventLoop() I've attached a patch that replaces all os.name occurrences in asyncio docs with sys.platform. ---------- components: asyncio files: doc-asyncio-os.name->sys.platform.patch keywords: patch messages: 253931 nosy: akira, gvanrossum, haypo, yselivanov priority: normal severity: normal status: open title: use sys.platform instead of os.name in asyncio docs consistently versions: Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file40930/doc-asyncio-os.name->sys.platform.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 12:07:52 2015 From: report at bugs.python.org (Brett Cannon) Date: Mon, 02 Nov 2015 17:07:52 +0000 Subject: [issue25533] Make pkgutil.iter_modules() yield built-in modules In-Reply-To: <1446462853.43.0.928344730721.issue25533@psf.upfronthosting.co.za> Message-ID: <1446484072.57.0.344576015952.issue25533@psf.upfronthosting.co.za> Brett Cannon added the comment: How would this handle frozen modules? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 12:12:26 2015 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 02 Nov 2015 17:12:26 +0000 Subject: [issue25536] use sys.platform instead of os.name in asyncio docs consistently In-Reply-To: <1446483319.57.0.76121078527.issue25536@psf.upfronthosting.co.za> Message-ID: <1446484346.68.0.77568857328.issue25536@psf.upfronthosting.co.za> Guido van Rossum added the comment: Sounds good. I'll commit this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 12:18:24 2015 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 02 Nov 2015 17:18:24 +0000 Subject: [issue25536] use sys.platform instead of os.name in asyncio docs consistently In-Reply-To: <1446483319.57.0.76121078527.issue25536@psf.upfronthosting.co.za> Message-ID: <1446484704.12.0.293831860807.issue25536@psf.upfronthosting.co.za> Guido van Rossum added the comment: Fixed in 3.4, 3.5, 3.6 by these commits: 193327cabbbc, e2400d5d67e7, 40ce5f4b8835. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 12:23:24 2015 From: report at bugs.python.org (Mouse) Date: Mon, 02 Nov 2015 17:23:24 +0000 Subject: [issue25495] binascii documentation incorrect In-Reply-To: <1445987417.55.0.122139453671.issue25495@psf.upfronthosting.co.za> Message-ID: <1446485004.04.0.711599574284.issue25495@psf.upfronthosting.co.za> Mouse added the comment: 1. I am OK with the following text, modeling referred Perldoc: b2a_base64( $bytes, $eol ); Encode data by calling the encode_base64() function. The first argument is the byte string to encode. The second argument is optional, and provides the line-ending sequence to use. When it is given, the returned encoded string is broken into lines of no more than 76 characters each and it will end with $eol unless it is empty. Pass an empty string, or no second argument at all if you do not want the encoded string to be broken into lines. 2. I already had people telling me that "Python-3 doc prohibits input longer than 57 bytes, even though it doesn't currently enforce it". Please help putting end to spreading of this confusion. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 12:47:36 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 02 Nov 2015 17:47:36 +0000 Subject: [issue25535] collections.Counter methods return Counter objects instead of subclass objects In-Reply-To: <1446482119.59.0.839988363019.issue25535@psf.upfronthosting.co.za> Message-ID: <1446486456.64.0.35109151779.issue25535@psf.upfronthosting.co.za> R. David Murray added the comment: This indeed looks like a bug to me, but I won't be surprised if Raymond says it was done on purpose. On the other hand originally the binary operator mothods didn't correctly return NotImplemented for non-Counters, so perhaps it is just an oversight. I'm not sure what the backward compatibility consequences would be of changing it. ---------- nosy: +r.david.murray, rhettinger title: collections.Counter methods return Counter objects -> collections.Counter methods return Counter objects instead of subclass objects _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 13:24:15 2015 From: report at bugs.python.org (Ned Deily) Date: Mon, 02 Nov 2015 18:24:15 +0000 Subject: [issue25531] greenlet header file is missing inside virtualenv In-Reply-To: <1446407383.6.0.829207834021.issue25531@psf.upfronthosting.co.za> Message-ID: <1446488655.73.0.504836997348.issue25531@psf.upfronthosting.co.za> Ned Deily added the comment: As David notes, this issue does not document any problems with Python 3.5 itself. I see at least two issues here. One, you are using virtualenv, a third-party package, rather than Python's built-in venv. It appears that the most recent release of virtualenv on PyPI, virtualenv 13.1.2, includes outdated wheels of other third-party products, in particular, of wheel: 0.24, instead of the current 0.36 (https://pypi.python.org/pypi/wheel). If you update wheel in your virtualenv that should fix the "assert tag == supported_tags[0]" issue. Suggest you open an issue against virtualenv to ask that they update their vendored packages or perhaps not include them. Another problem, when using the python.org python3.5, is with the install script of the uwsgi, uwsgiconfig.py. The script does some machinations to figure out what compiler it is using. Unfortunately, it seems to get confused by the fact that, with the last several major releases of Xcode, Apple no long ships gcc but does provide a gcc alias that actually invokes clang. If you override the CC value and explictly set CC=clang, the uwsgi install seems to work correctly with the python.org OS X 3.5.0. I do not have a homebrew installation handy to check, so if there are other problems after updating wheel in your virtualenv (or switching to use builtin venv) and using CC=clang, suggest you ask on a homebrew forum. ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 13:26:38 2015 From: report at bugs.python.org (Ned Deily) Date: Mon, 02 Nov 2015 18:26:38 +0000 Subject: [issue25531] greenlet header file is missing inside virtualenv In-Reply-To: <1446407383.6.0.829207834021.issue25531@psf.upfronthosting.co.za> Message-ID: <1446488798.0.0.0603472799806.issue25531@psf.upfronthosting.co.za> Ned Deily added the comment: As David notes, this issue does not document any problems with Python 3.5 itself. I see at least two issues here. One, you are using virtualenv, a third-party package, rather than Python's built-in venv. It appears that the most recent release of virtualenv on PyPI, virtualenv 13.1.2, includes outdated wheels of other third-party products, in particular, of wheel: 0.24, instead of the current 0.26 (https://pypi.python.org/pypi/wheel). If you update wheel in your virtualenv that should fix the "assert tag == supported_tags[0]" issue. Suggest you open an issue against virtualenv to ask that they update their vendored packages or perhaps not include them. Another problem, when using the python.org python3.5, is with the install script of the uwsgi, uwsgiconfig.py. The script does some machinations to figure out what compiler it is using. Unfortunately, it seems to get confused by the fact that, with the last several major releases of Xcode, Apple no long ships gcc but does provide a gcc alias that actually invokes clang. If you override the CC value and explictly set CC=clang, the uwsgi install seems to work correctly with the python.org OS X 3.5.0. You should probably open an issue with the uwsgi project about that. I do not have a homebrew installation handy to check, so if there are other problems after updating wheel in your virtualenv (or switching to use builtin venv) and using CC=clang, suggest you ask on a homebrew forum. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 13:26:46 2015 From: report at bugs.python.org (Ned Deily) Date: Mon, 02 Nov 2015 18:26:46 +0000 Subject: [issue25531] greenlet header file is missing inside virtualenv In-Reply-To: <1446407383.6.0.829207834021.issue25531@psf.upfronthosting.co.za> Message-ID: <1446488806.76.0.777256104068.issue25531@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- Removed message: http://bugs.python.org/msg253937 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 13:39:56 2015 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 02 Nov 2015 18:39:56 +0000 Subject: [issue25535] collections.Counter methods return Counter objects instead of subclass objects In-Reply-To: <1446482119.59.0.839988363019.issue25535@psf.upfronthosting.co.za> Message-ID: <1446489596.12.0.274400890803.issue25535@psf.upfronthosting.co.za> Mark Dickinson added the comment: I'm fairly sure that this behaviour is deliberate, and (more-or-less) consistently applied throughout the builtin and standard library types. If you create a subclass C of list, then concatenation of two instances of C still gives a result of type list. Similarly, if you subclass Decimal then arithmetic operations on instances of your subclass still return a Decimal instance. If you want operations to return instances of the subclass, it's up to you to override those operations in your subclass. Having the Counter operations automatically return an instance of the subclass would mean placing restrictions on the signature of the constructor of any such subclass, which may be undesirable. (A subclass may want to require additional arguments in its constructor.) ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 13:57:43 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 02 Nov 2015 18:57:43 +0000 Subject: [issue24306] Backport py.exe to 3.4 In-Reply-To: <1432771856.97.0.606443218974.issue24306@psf.upfronthosting.co.za> Message-ID: <1446490663.89.0.282369231272.issue24306@psf.upfronthosting.co.za> Steve Dower added the comment: So with the 3.5 launcher being installed all-users by default, the attached patch is a good option. I'm not able to build 3.4 entirely, but I made the modification to the MSI directly and it works fine, so I intend to go ahead and apply it (with some extra line wrapping for formatting purposes) before 3.4.4 Unfortunately, I believe upgrades from 3.4.3 to 3.4.4 may remove the 3.5 launcher and then replace it with the 3.4 one. Unfortunately, there's no way to prevent this. Subsequently repairing or installing 3.5 should bring back the newer one. Martin - any concerns here? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 14:05:24 2015 From: report at bugs.python.org (Alexey Borzenkov) Date: Mon, 02 Nov 2015 19:05:24 +0000 Subject: [issue25531] greenlet header file is missing inside virtualenv In-Reply-To: <1446407383.6.0.829207834021.issue25531@psf.upfronthosting.co.za> Message-ID: <1446491124.54.0.139243065475.issue25531@psf.upfronthosting.co.za> Alexey Borzenkov added the comment: I have reproduced this problem on Linux with pyvenv, isn't that part of Python 3.5? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 14:10:21 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 02 Nov 2015 19:10:21 +0000 Subject: [issue25535] collections.Counter methods return Counter objects instead of subclass objects In-Reply-To: <1446482119.59.0.839988363019.issue25535@psf.upfronthosting.co.za> Message-ID: <1446491421.08.0.72637373164.issue25535@psf.upfronthosting.co.za> R. David Murray added the comment: OK, good point. Perhaps we should turn this into a feature request to replace the calls to Counter with a call to an overridable method to make subclassing in this way possible without massive cut and paste. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 14:10:55 2015 From: report at bugs.python.org (tzickel) Date: Mon, 02 Nov 2015 19:10:55 +0000 Subject: [issue25083] Python can sometimes create incorrect .pyc files In-Reply-To: <1442143572.78.0.211523310189.issue25083@psf.upfronthosting.co.za> Message-ID: <1446491455.68.0.626691796739.issue25083@psf.upfronthosting.co.za> tzickel added the comment: 1. You are correct the issue I am talking about is in parsing source files (Altough because python caches them as .pyc it's a worse situation). 2. The example you give is EINTR handling (which is mostly handling interrupted I/O operations by signals and retrying them) the real I/O error checking in that get_line is I belive in the next ferror check there. It might be nice to have EINTR checking (and retry) when reading the source file as well, but that is a secondary issue. 3. As for your recommendation for changing Py_UniversalNewlineFgets, you can see that both it's documentation says "Note that we need no error handling: fgets() treats error and eof identically." and since it seems like a low-level function that does not have any python stuff like exception handling, and in it's current signature it can't return an error (it simply returns the buffer, or NULL if nothing was read). 4. As for why putting it in that position, basically there could be a few I/O paths, besides Py_UniversalNewlineFget, such as codec decoding in fp_readl (via decoding_fgets) that can fail in I/O as well. Looking at the code again (while not tested), maybe the check can be actually moved to the end of decoding_fgets in tokenizer.c i.e. if there is an ferror in tok->fp in the end of decoding_fgets then to return error_ret(tok); there, but then double eyes need to be sure that no other code path can have an I/O error. I am not an expert on the layout of tokenizer (read it mostly to figure out this bug) so if that's better it can be moved I guess. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 14:13:51 2015 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 02 Nov 2015 19:13:51 +0000 Subject: [issue25535] collections.Counter methods return Counter objects instead of subclass objects In-Reply-To: <1446482119.59.0.839988363019.issue25535@psf.upfronthosting.co.za> Message-ID: <1446491631.33.0.76367364142.issue25535@psf.upfronthosting.co.za> Mark Dickinson added the comment: Relevant post from Tim Peters back in 2005, on the subject of subclassing datetime and timedelta: """ Yes, and all builtin Python types work that way. For example, int.__add__ or float.__add__ applied to a subclass of int or float will return an int or float; similarly for a subclass of str. This was Guido's decision, based on that an implementation of any method in a base class has no idea what requirements may exist for invoking a subclass's constructor. For example, a subclass may restrict the values of constructor arguments, or require more arguments than a base class constructor; it may permute the order of positional arguments in the base class constructor; it may even be "a feature" that a subclass constructor gives a different meaning to an argument it shares with the base class constructor. Since there isn't a way to guess, Python does a safe thing instead. """ Source: https://mail.python.org/pipermail/python-list/2005-January/311610.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 14:15:01 2015 From: report at bugs.python.org (Alexey Borzenkov) Date: Mon, 02 Nov 2015 19:15:01 +0000 Subject: [issue25531] greenlet header file is missing inside virtualenv In-Reply-To: <1446407383.6.0.829207834021.issue25531@psf.upfronthosting.co.za> Message-ID: <1446491701.23.0.438989485998.issue25531@psf.upfronthosting.co.za> Alexey Borzenkov added the comment: I created a simple gist that can show the problem: https://gist.github.com/snaury/ea167713b1804ffbaf5a (testme.sh builds Python 3.5, creates a venv, install greenlet and tries to compile an extension) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 14:29:36 2015 From: report at bugs.python.org (Nir Soffer) Date: Mon, 02 Nov 2015 19:29:36 +0000 Subject: [issue25516] threading.Condition._is_owned() is wrong when using threading.Lock In-Reply-To: <1446165392.31.0.717642417411.issue25516@psf.upfronthosting.co.za> Message-ID: <1446492576.76.0.696006351932.issue25516@psf.upfronthosting.co.za> Changes by Nir Soffer : ---------- nosy: +haypo, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 16:10:26 2015 From: report at bugs.python.org (Sjoerd Job Postmus) Date: Mon, 02 Nov 2015 21:10:26 +0000 Subject: [issue25537] Call `isinstance` instead of `issubclass` during exception handling Message-ID: <1446498626.24.0.0841734313123.issue25537@psf.upfronthosting.co.za> New submission from Sjoerd Job Postmus: Currently Python2.7 calls `PyObject_IsSubclass` during exception handling. This allows some virtual-base-class machinery to make Python believe a certain class should match an exception while it in reality does not. However, this does not necessarily give one really enough granularity when dealing with base libraries which are not as granular in raising exceptions as one would like (the Python base library before PEP3151 comes to mind). Currently I used the trick of calling `isinstance(sys.exc_info()[1], cls)` in the `__subclasscheck__`, which is sort-of a great work-around.[*]. This method is great for sort-of emulating PEP3151 in Python2.7, and similar work can be done for other libraries: making the exception classes appear more granular based on properties of the instance of the exception. My belief is that by calling the `isinstance` during exception handling, one can use virtual base classes (or should I say virtual base instances) to their fullest potential in writing cleaner code. I think this is important because exception-handling is already a place where messy code is likely to occur, and we need all the support we can get in making it just a tad less messy.[**] Note: Python3.5 calls `PyType_IsSubtype`, which has #12029 open for a change towards `PyObject_IsSubclass`. As soon as (or before) that's implemented, I'd like to propose a similar change for Python3.5+: call `PyObject_IsInstance` when the raised exception is an instance. [*] See https://github.com/sjoerdjob/exhacktion/ for how I use the described hack to somewhat emulate PEP3151 in Python2.7. [**] One question that comes to mind is: why not just write a wrapper around the offending library. (1): If it's the base library, almost nobody is going to bother. (2): even if it's not the base library, the wrapper will likely be even more function calls, which may cost performance in both the good and the bad cases, instead of just the bad cases. ---------- components: Interpreter Core messages: 253946 nosy: sjoerdjob priority: normal severity: normal status: open title: Call `isinstance` instead of `issubclass` during exception handling type: enhancement versions: Python 2.7, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 16:23:28 2015 From: report at bugs.python.org (Ned Deily) Date: Mon, 02 Nov 2015 21:23:28 +0000 Subject: [issue25531] greenlet header file is missing inside virtualenv In-Reply-To: <1446407383.6.0.829207834021.issue25531@psf.upfronthosting.co.za> Message-ID: <1446499408.71.0.151567151383.issue25531@psf.upfronthosting.co.za> Ned Deily added the comment: Alexey, thanks for the simplified test case. I'll look at it further. ---------- resolution: third party -> stage: resolved -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 17:00:33 2015 From: report at bugs.python.org (Giampaolo Rodola') Date: Mon, 02 Nov 2015 22:00:33 +0000 Subject: [issue25157] Installing Python 3.5.0 32bit on Windows 8.1 64bit system gives Error 0x80240017 In-Reply-To: <1442526643.4.0.412457342038.issue25157@psf.upfronthosting.co.za> Message-ID: <1446501633.22.0.773651293213.issue25157@psf.upfronthosting.co.za> Changes by Giampaolo Rodola' : ---------- nosy: +giampaolo.rodola _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 17:38:00 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 02 Nov 2015 22:38:00 +0000 Subject: [issue25534] SimpleHTTPServer throwed an exception due to negtive st_mtime attr in file In-Reply-To: <1446478517.38.0.562445062137.issue25534@psf.upfronthosting.co.za> Message-ID: <1446503880.29.0.297441651863.issue25534@psf.upfronthosting.co.za> Martin Panter added the comment: I think your test file?s time is lost on the web server. On Linux it is pretty easy to make a file with an arbitrary time; maybe Windows has an equivalent: $ touch -d "1 Jan 1900" test I experimented with Wine, and it seems gmtime() raises ValueError on Python 2 and OSError on Python 3 for negative times, but under Linux negative times are handled successfully. (Wine seems to wrap the st_mtime field to a 32-bit unsigned value though, so I am unable to reproduce the original problem.) The ?time? module documentation says ?The functions in this module may not handle dates and times before the epoch?, so maybe the HTTP module should be fixed to handle a ValueError (or OSError on Python 3). ---------- components: +Windows nosy: +martin.panter, paul.moore, steve.dower, tim.golden, zach.ware stage: -> needs patch type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 18:08:03 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 02 Nov 2015 23:08:03 +0000 Subject: [issue25538] Traceback from __exit__ method is misleading Message-ID: <1446505683.0.0.402181965789.issue25538@psf.upfronthosting.co.za> New submission from R. David Murray: This is at least the second time that I've wasted a bunch of debugging time being mislead by the traceback from __exit__. Perhaps I will remember from now on, but...I wonder if it would be possible/practical to improve the situation. The problem is that in the traceback printed when __exit__ throws an error, the source line printed before the source line from inside the __exit__ is the last line of the 'with' block. I kept staring at that line trying to figure out how the exception could possibly be getting raised from that line...which of course it wasn't really, it was the "line" in between that one and the next one, a psuedo-line representing the exit from the block. I don't know if it would be worth the effort that would be required to somehow clarify this in the traceback (I'm not even sure what that would *look* like...maybe the first line of the with block instead?), but I thought I'd raise the issue to see if anyone had any clever ideas. (Hopefully I haven't done this before...I tried searching for similar issues and didn't find anything.) ---------- messages: 253949 nosy: r.david.murray priority: normal severity: normal status: open title: Traceback from __exit__ method is misleading _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 18:41:04 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 02 Nov 2015 23:41:04 +0000 Subject: [issue25498] Python 3.4.3 core dump with simple sample code In-Reply-To: <1446055572.58.0.349657416945.issue25498@psf.upfronthosting.co.za> Message-ID: <1446507664.19.0.95824730029.issue25498@psf.upfronthosting.co.za> Martin Panter added the comment: I tend to agree with Serhiy about Eryksun?s patch. I understand it solves the current problem, and continues to protect against this scenario: >>> b = bytearray(b"a") >>> c = ctypes.c_char.from_buffer(b) >>> b *= 1000 BufferError: Existing exports of data: object cannot be re-sized PyObject_AsWriteBuffer() and PyBuffer_Release() did get changed in 3.4, also by Issue 22896. Reviewing the history (mainly ), the only behaviour change I see is that it now clears view->obj to NULL, via the new PyBuffer_Release() call, before calling DECREF on the object. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 18:44:28 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 02 Nov 2015 23:44:28 +0000 Subject: [issue25537] Call `isinstance` instead of `issubclass` during exception handling In-Reply-To: <1446498626.24.0.0841734313123.issue25537@psf.upfronthosting.co.za> Message-ID: <1446507868.32.0.804942413573.issue25537@psf.upfronthosting.co.za> R. David Murray added the comment: This does not sound like the kind of change we would accept for python 2.7. (I also don't understand what the difference is between calling issubclass on the type and isinstance on the instance in this case. But, then, I haven't looked at the code in question.) ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 18:47:42 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 02 Nov 2015 23:47:42 +0000 Subject: [issue25474] Weird behavior when setting f_trace in a context manager In-Reply-To: <1445774698.38.0.095988844457.issue25474@psf.upfronthosting.co.za> Message-ID: <1446508062.07.0.432033974604.issue25474@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Thank you Xavier. I guess the lesson is that physical line tracing works best (and most as one would hope or expect) when physical lines are logical lines (or compound statement header lines). ---------- resolution: -> not a bug stage: test needed -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 18:48:25 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 02 Nov 2015 23:48:25 +0000 Subject: [issue25535] collections.Counter methods return Counter objects instead of subclass objects In-Reply-To: <1446482119.59.0.839988363019.issue25535@psf.upfronthosting.co.za> Message-ID: <1446508105.68.0.646241307437.issue25535@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 19:04:31 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 03 Nov 2015 00:04:31 +0000 Subject: [issue25535] collections.Counter methods return Counter objects instead of subclass objects In-Reply-To: <1446482119.59.0.839988363019.issue25535@psf.upfronthosting.co.za> Message-ID: <1446509071.54.0.713217506478.issue25535@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The decision was deliberate and matches what we've done elsewhere in Python. The nearest kin to Counters are sets/frozensets which also behave the same way: >>> class S(set): pass >>> type(S('abc') | S('cdef')) Mark Dickinson articulated the reasons clearly. Python has been consistent about this decision from the outset (see array.array or fractions.Fraction for example). Marking this as "not a bug" and closing. ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 19:47:21 2015 From: report at bugs.python.org (Chris Withers) Date: Tue, 03 Nov 2015 00:47:21 +0000 Subject: [issue25532] infinite loop when running inspect.unwrap over unittest.mock.call In-Reply-To: <1446421817.99.0.495650724157.issue25532@psf.upfronthosting.co.za> Message-ID: <1446511641.41.0.221515398813.issue25532@psf.upfronthosting.co.za> Chris Withers added the comment: Ah yes, I can see how Venusian would get confused. How about making the check a more generic: if attr.startswith('__'): raise AttributeError(attr) ? That said, why does call have a __getattr__? Where is that intended to be used? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 20:04:28 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 03 Nov 2015 01:04:28 +0000 Subject: [issue25495] binascii documentation incorrect In-Reply-To: <1445987417.55.0.122139453671.issue25495@psf.upfronthosting.co.za> Message-ID: <1446512668.61.0.25002687185.issue25495@psf.upfronthosting.co.za> Martin Panter added the comment: FWIW that Perl function looks like it does the line splitting for you. It mentions ?chunks that are a multiple of 57 bytes?. The Python function does not do any line splitting. You have to use base64.encodebytes(), codecs.encode(encoding="base64") or perhaps something in the email package (or user code) for that. I think we all agree that there is no hard limit of 57. I have avoided this function in the past due to the documentation. The question is whether the documentation should mention that number in a more accurate context, or not at all. Personally I don?t see much harm in mentioning the 57-byte input chunking, as long as it is obvious it is not the only option. I don?t have a strong view; I am just trying to be conservative. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 20:14:13 2015 From: report at bugs.python.org (Giampaolo Rodola') Date: Tue, 03 Nov 2015 01:14:13 +0000 Subject: [issue25157] Installing Python 3.5.0 32bit on Windows 8.1 64bit system gives Error 0x80240017 In-Reply-To: <1442526643.4.0.412457342038.issue25157@psf.upfronthosting.co.za> Message-ID: <1446513253.83.0.142315750923.issue25157@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: I am having the same problem with Windows 7 64-bit. Tried to install all updates but nothing changed. As for the suggestion to install SP1 1: - Windows update does not automatically install it - As for the manual installation I am not sure which file to download from: https://www.microsoft.com/en-us/download/details.aspx?id=5842 (this is ridiculous). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 21:19:07 2015 From: report at bugs.python.org (eryksun) Date: Tue, 03 Nov 2015 02:19:07 +0000 Subject: [issue25157] Installing Python 3.5.0 32bit on Windows 8.1 64bit system gives Error 0x80240017 In-Reply-To: <1442526643.4.0.412457342038.issue25157@psf.upfronthosting.co.za> Message-ID: <1446517147.89.0.860508534534.issue25157@psf.upfronthosting.co.za> eryksun added the comment: > As for the suggestion to install SP1 1... As for the manual > installation I am not sure which file to download from It's one of these three, depending on your system architecture: windows6.1-KB976932-X86.exe - This application installs Sp1 to a 32-bit machine running Windows 7. windows6.1-KB976932-X64.exe - This application installs Sp1 to a 64-bit machine running Windows 7 or Windows Server 2008 R2. windows6.1-KB976932-IA64.exe - This application installs Sp1 to an Itanium 64-bit Windows Server 2008 R2. Detailed instructions for installing Windows 7 SP1: http://windows.microsoft.com/installwindows7sp1. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 21:39:38 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 03 Nov 2015 02:39:38 +0000 Subject: [issue12029] Catching virtual subclasses in except clauses In-Reply-To: <1304844823.89.0.48444500115.issue12029@psf.upfronthosting.co.za> Message-ID: <1446518378.53.0.529728787996.issue12029@psf.upfronthosting.co.za> Martin Panter added the comment: In the current (v4) patch, it looks like there is an unneeded ?allow_new_exception? parameter that is always set to zero. So maybe the patch needs more careful thought. Also I agree it needs documentation, what?s new, ?changed in version 3.6?, etc. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 21:51:13 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 03 Nov 2015 02:51:13 +0000 Subject: [issue25533] Make pkgutil.iter_modules() yield built-in modules In-Reply-To: <1446462853.43.0.928344730721.issue25533@psf.upfronthosting.co.za> Message-ID: <1446519073.78.0.411057514244.issue25533@psf.upfronthosting.co.za> Martin Panter added the comment: My patch doesn?t handle frozen modules. Maybe we need a new sys.frozen_module_names API, or a sys.list_frozen_module_names() function if it is meant to be dynamic. All I could find was (which needs updating for Python 3?s byte strings). A related point: Are built-in packages possible? My patch doesn?t anticipate them either. If adding a new iter_all_modules() function, there should probably be a matching walk_all_packages() function. But under the hood they would all probably use the same internal functions with a flag. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 22:04:41 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 03 Nov 2015 03:04:41 +0000 Subject: [issue25537] Call `isinstance` instead of `issubclass` during exception handling In-Reply-To: <1446498626.24.0.0841734313123.issue25537@psf.upfronthosting.co.za> Message-ID: <1446519881.95.0.729972739623.issue25537@psf.upfronthosting.co.za> Martin Panter added the comment: [Avoiding UTF-8 error] This is an interesting idea that never occurred to me. It would be nice to support it if the performance impact isn?t a problem. By the sound of Issue 12029, performance is barely affected until you actually try to catch a ?virtual exception?. So the impact of changing from subclass to instance checking shouldn?t be much worse if we do it right. I agree this would be a new feature for a new release, not for 2.7 or 3.5. BTW here?s another approach using the same sys.exc_info() hack that also works in Python 3: >>> def catch_not_implemented(): ... '''Helper to catch "API not implemented" exceptions''' ... [_, exc, _] = sys.exc_info() ... if isinstance(exc, NotImplementedError): ... return BaseException # Catch the exception ... if isinstance(exc, EnvironmentError) and exc.errno == ENOSYS: ... return BaseException # Catch the exception ... if isinstance(exc, HTTPError) and exc.code == HTTPStatus.NOT_IMPLEMENTED: ... return BaseException # Catch the exception ... return () # Don't catch the exception ... >>> try: raise OSError(ENOSYS, "Dummy message") ... except catch_not_implemented() as err: print(repr(err)) ... OSError(38, 'Dummy message') ---------- dependencies: +Catching virtual subclasses in except clauses nosy: +martin.panter versions: -Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 2 22:27:24 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 03 Nov 2015 03:27:24 +0000 Subject: [issue25538] Traceback from __exit__ method is misleading In-Reply-To: <1446505683.0.0.402181965789.issue25538@psf.upfronthosting.co.za> Message-ID: <1446521244.09.0.12568067711.issue25538@psf.upfronthosting.co.za> Martin Panter added the comment: I guess you are mainly complaining about when __exit__() implementation is built into the interpreter. E.g., given demo.py: with open("/dev/full", "wb") as file: file.write(b"data") print("All is well") print("Not executed") the output looks like All is well Traceback (most recent call last): File "demo.py", line 3, in print("All is well") OSError: [Errno 28] No space left on device When __exit__() is implemented natively in Python, you get more of a hint: Traceback (most recent call last): File "demo.py", line 4, in print("All is well") File "/home/proj/python/cpython/Lib/_pyio.py", line 457, in __exit__ self.close() File "/home/proj/python/cpython/Lib/_pyio.py", line 773, in close self.flush() File "/home/proj/python/cpython/Lib/_pyio.py", line 1210, in flush self._flush_unlocked() File "/home/proj/python/cpython/Lib/_pyio.py", line 1217, in _flush_unlocked n = self.raw.write(self._write_buf) File "/home/proj/python/cpython/Lib/_pyio.py", line 1614, in write return os.write(self._fd, b) OSError: [Errno 28] No space left on device Maybe another option would be to insert a virtual frame in the built-in version of the traceback: Traceback (most recent call last): File "demo.py", line 3, in print("All is well") File "", line ???, in OSError: [Errno 28] No space left on device ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 01:02:21 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 03 Nov 2015 06:02:21 +0000 Subject: [issue25455] Some repr implementations don't check for self-referential structures In-Reply-To: <1445455038.6.0.824380060049.issue25455@psf.upfronthosting.co.za> Message-ID: <1446530541.97.0.292695052302.issue25455@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Changing PyObject_Repr is too course; it affects a broad class of objects other than containers, and it risks unknown impacts to larges swaths of third-party code use this venerable API. It is also a break with the long established history of recursion detection being a responsibility of the individual types (i.e. the code in sets, lists, dicts, etc.) The three cases listed here should be fixed individually. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 01:38:03 2015 From: report at bugs.python.org (=?utf-8?b?7Iug64+Z7JuQ?=) Date: Tue, 03 Nov 2015 06:38:03 +0000 Subject: [issue25539] python3 fail on parsing http header Message-ID: <1446532683.92.0.439898298366.issue25539@psf.upfronthosting.co.za> New submission from ???: I tried to login some website using requests session, but it failed because of parsing header. This is header data of problem. It contains two line of continuous CRLF between the data. Date: Mon, 02 Nov 2015 08:45:48 GMT Server: Apache/2.2.20 (Unix) mod_ssl/2.2.20 OpenSSL/0.9.8e-fips-rhel5 DAV/2 PHP/5.2.16 mod_fastcgi/2.4.6 X-Powered-By: PHP/5.2.16 P3P: CP="NOI CURa ADMa DEVa TAIa OUR DELa BUS IND PHY ONL UNI COM NAV INT DEM PRE" P3P : CP="ALL CURa ADMa DEVa TAIa OUR BUS IND PHY ONL UNI PUR FIN COM NAV INT DEM CNT STA POL HEA PRE LOC OTC" Set-Cookie: PHPSESSID=**; path=/ Set-Cookie: PHPSESSID=**; path=/ Content-Length: 81 Connection: close Content-Type: text/html function parse_headers in http.client, parsing exits when it meet CRLF. (https://hg.python.org/cpython/file/tip/Lib/http/client.py#l197) Is it standard? Same code works well in python2, or even similar code in ruby. ---------- components: Library (Lib) messages: 253966 nosy: ??? priority: normal severity: normal status: open title: python3 fail on parsing http header type: crash versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 01:51:37 2015 From: report at bugs.python.org (Kracekumar Ramaraj) Date: Tue, 03 Nov 2015 06:51:37 +0000 Subject: [issue25531] greenlet header file is missing inside virtualenv In-Reply-To: <1446407383.6.0.829207834021.issue25531@psf.upfronthosting.co.za> Message-ID: <1446533497.74.0.675781031541.issue25531@psf.upfronthosting.co.za> Kracekumar Ramaraj added the comment: Updating wheel to latest version fixed assertion issue but uwsgi installation still fails. Virtualenv has updated to latest whhel version https://github.com/pypa/virtualenv/blob/develop/virtualenv_support/wheel-0.26.0-py2.py3-none-any.whl. Also, my example used `python -m venv`, this is part of stdlib and using `pyvenv-3.5` produced same result. Explicitly setting `CC=clang` in OSX didn't help https://gist.github.com/kracekumar/270533354d62be46f77d and also on Ubuntu 14.04 produces same error with gcc and clang. I have opened an issue in uwsgi https://github.com/unbit/uwsgi/issues/1100. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 01:58:31 2015 From: report at bugs.python.org (tanbro) Date: Tue, 03 Nov 2015 06:58:31 +0000 Subject: [issue25540] virtual conf file encoding error on windows Message-ID: <1446533911.62.0.714179099115.issue25540@psf.upfronthosting.co.za> New submission from tanbro: When create a new `venv` on windows, sometimes an `UnicodeDecodeError` occurred. It seems that, it is caused by the system module `site`. In `Lib/site.py`, line 468:: with open(virtual_conf) as f: for line in f: line = line.strip() The file `virtual_conf` was open with encoding `gbk` which is my windows default encoding, but in fact, the file is an `utf-8` one, so i think it should be:: with open(virtual_conf, encoding='utf-8') as f: for line in f: line = line.strip() ---------- messages: 253968 nosy: tanbro priority: normal severity: normal status: open title: virtual conf file encoding error on windows type: crash versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 02:47:30 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 03 Nov 2015 07:47:30 +0000 Subject: [issue25455] Some repr implementations don't check for self-referential structures In-Reply-To: <1445455038.6.0.824380060049.issue25455@psf.upfronthosting.co.za> Message-ID: <1446536850.3.0.903221565432.issue25455@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yet one example: >>> import io >>> class BR(io.BufferedReader): ... @property ... def name(self): ... return self ... >>> repr(BR(io.BytesIO())) Segmentation fault The same is for other file-like objects. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 03:29:50 2015 From: report at bugs.python.org (Florin Papa) Date: Tue, 03 Nov 2015 08:29:50 +0000 Subject: [issue25300] Enable Intel MPX (Memory protection Extensions) feature In-Reply-To: <1443788737.62.0.174147088714.issue25300@psf.upfronthosting.co.za> Message-ID: <1446539390.22.0.00700849866861.issue25300@psf.upfronthosting.co.za> Florin Papa added the comment: Please see the updated patch after Zachary Ware's review. Thank you for the feedback. ---------- Added file: http://bugs.python.org/file40931/mpx_enable_3_6_v6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 03:47:15 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 03 Nov 2015 08:47:15 +0000 Subject: [issue25539] python3 fail on parsing http header In-Reply-To: <1446532683.92.0.439898298366.issue25539@psf.upfronthosting.co.za> Message-ID: <1446540435.16.0.76418329253.issue25539@psf.upfronthosting.co.za> Martin Panter added the comment: Are you able to print out the repr() of the header or the entire HTTP response so we can see exactly what characters are there? Or provide a URL if it is a public server. I suspect it may not be a completely blank line, but may have whitespace there. Both Python 2 and 3 should stop parsing the HTTP header when they meet a blank line (two CRLFs in a row). This marks the start of the HTTP body. See . ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 03:47:40 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 03 Nov 2015 08:47:40 +0000 Subject: [issue25539] python3 fail on parsing http header In-Reply-To: <1446532683.92.0.439898298366.issue25539@psf.upfronthosting.co.za> Message-ID: <1446540460.35.0.561525012182.issue25539@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 03:48:42 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 03 Nov 2015 08:48:42 +0000 Subject: [issue25455] Some repr implementations don't check for self-referential structures In-Reply-To: <1445455038.6.0.824380060049.issue25455@psf.upfronthosting.co.za> Message-ID: <1446540521.99.0.834145722465.issue25455@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Recursive partial objects are legitimate. Here is a patch that makes partial's repr to support recursive partial objects. Also added a test for pickling. Cases for Element and file-like objects are questionable. Recursive Element.tag and TextIOWrapper.name don't make a sense, and I don't think we should special support (and encourage) these cases. To avoid stack overflow we can add a restriction for tag to be str or None, but file's name attribute can be dynamic. We can omit name from repr if it is not None, str, bytes or int. ---------- keywords: +patch Added file: http://bugs.python.org/file40932/partial_recursive_repr.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 04:00:59 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 03 Nov 2015 09:00:59 +0000 Subject: [issue25455] Some repr implementations don't check for self-referential structures In-Reply-To: <1445455038.6.0.824380060049.issue25455@psf.upfronthosting.co.za> Message-ID: <1446541259.87.0.0358525373295.issue25455@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Added ElementTree and io modules experts to the nosy list. ---------- nosy: +benjamin.peterson, eli.bendersky, pitrou, scoder, stutzbach _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 04:09:21 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 03 Nov 2015 09:09:21 +0000 Subject: [issue25540] virtual conf file encoding error on windows In-Reply-To: <1446533911.62.0.714179099115.issue25540@psf.upfronthosting.co.za> Message-ID: <1446541761.05.0.239108671925.issue25540@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Already fixed in issue25185. ---------- nosy: +serhiy.storchaka resolution: -> out of date stage: -> resolved status: open -> closed superseder: -> Inconsistency between venv and site _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 04:26:58 2015 From: report at bugs.python.org (Michael Foord) Date: Tue, 03 Nov 2015 09:26:58 +0000 Subject: [issue25532] infinite loop when running inspect.unwrap over unittest.mock.call In-Reply-To: <1446421817.99.0.495650724157.issue25532@psf.upfronthosting.co.za> Message-ID: <1446542818.33.0.693364093035.issue25532@psf.upfronthosting.co.za> Michael Foord added the comment: Have you read the docs for call? :-) call.foo("foo") generates a call object representing a method call to the method foo. So you can do. m = Mock() m.foo("foo") self.assertEqual(m.mock_calls, call.foo("foo")) (etc) See also the call.call_list (I believe) method for assertions on chained calls. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 04:28:31 2015 From: report at bugs.python.org (Michael Foord) Date: Tue, 03 Nov 2015 09:28:31 +0000 Subject: [issue25532] infinite loop when running inspect.unwrap over unittest.mock.call In-Reply-To: <1446421817.99.0.495650724157.issue25532@psf.upfronthosting.co.za> Message-ID: <1446542911.6.0.999381258381.issue25532@psf.upfronthosting.co.za> Michael Foord added the comment: Preventing the use of "__" attributes would limit the usefulness of call with MagicMock and the use of magic methods. That might be an acceptable trade-off, but would break existing tests for people. (i.e. it's a backwards incompatible change.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 05:22:10 2015 From: report at bugs.python.org (Shin Dong-won) Date: Tue, 03 Nov 2015 10:22:10 +0000 Subject: [issue25539] python3 fail on parsing http header In-Reply-To: <1446532683.92.0.439898298366.issue25539@psf.upfronthosting.co.za> Message-ID: <1446546130.11.0.621371635099.issue25539@psf.upfronthosting.co.za> Shin Dong-won added the comment: b'Date: Tue, 03 Nov 2015 10:05:42 GMT\nServer: Apache/2.2.20 (Unix) mod_ssl/2.2.20 OpenSSL/0.9.8e-fips-rhel5 DAV/2\n PHP/5.2.16 mod_fastcgi/2.4.6\nX-Powered-By: PHP/5.2.16\nP3P: CP="NOI CURa ADMa DEVa TAIa OUR DELa BUS IND PHY ONL UNI COM NAV INT DEM\n PRE"\n\nP3P : CP="ALL CURa ADMa DEVa TAIa OUR BUS IND PHY ONL UNI PUR FIN COM NAV INT DEM CNT STA POL HEA PRE LOC OTC"\nSet-Cookie: PHPSESSID=**; path=/\nSet-Cookie: PHPSESSID=**; path=/\nContent-Length: 79\nConnection: close\nContent-Type: text/html\n\n' There's no other characters except CRLF. And other weird result, in python2 there are no two CRLF between P3P:~. Here's gist for test. (https://gist.github.com/littmus/9625a4436e1edfb3afe9) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 05:33:37 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 03 Nov 2015 10:33:37 +0000 Subject: [issue25539] python3 fail on parsing http header In-Reply-To: <1446532683.92.0.439898298366.issue25539@psf.upfronthosting.co.za> Message-ID: <1446546817.77.0.792468450232.issue25539@psf.upfronthosting.co.za> STINNER Victor added the comment: > It contains two line of continuous CRLF between the data. It looks like a bug at server side. \n\n is the separator between headers and data. An header must not end with \n\n. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 05:35:20 2015 From: report at bugs.python.org (Shin Dong-won) Date: Tue, 03 Nov 2015 10:35:20 +0000 Subject: [issue25539] python3 fail on parsing http header In-Reply-To: <1446532683.92.0.439898298366.issue25539@psf.upfronthosting.co.za> Message-ID: <1446546920.17.0.35763557749.issue25539@psf.upfronthosting.co.za> Shin Dong-won added the comment: I think so but same http request works well in Python2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 05:57:40 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 03 Nov 2015 10:57:40 +0000 Subject: [issue25388] tokenizer crash/misbehavior -- heap use-after-free In-Reply-To: <1444706115.92.0.283351483962.issue25388@psf.upfronthosting.co.za> Message-ID: <1446548260.02.0.628772106205.issue25388@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 06:00:29 2015 From: report at bugs.python.org (Shin Dong-won) Date: Tue, 03 Nov 2015 11:00:29 +0000 Subject: [issue25539] python3 fail on parsing http header In-Reply-To: <1446532683.92.0.439898298366.issue25539@psf.upfronthosting.co.za> Message-ID: <1446548429.35.0.0338986696143.issue25539@psf.upfronthosting.co.za> Shin Dong-won added the comment: I had a mistake. That's not CRLF but just two '\n'. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 06:08:21 2015 From: report at bugs.python.org (PrzemeK) Date: Tue, 03 Nov 2015 11:08:21 +0000 Subject: [issue25541] Wrong usage of sockaddr_un struct for abstract namespace unix sockets Message-ID: <1446548901.72.0.800156558453.issue25541@psf.upfronthosting.co.za> Changes by PrzemeK : ---------- components: IO, Library (Lib) nosy: soutys priority: normal severity: normal status: open title: Wrong usage of sockaddr_un struct for abstract namespace unix sockets type: behavior versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 06:15:22 2015 From: report at bugs.python.org (PrzemeK) Date: Tue, 03 Nov 2015 11:15:22 +0000 Subject: [issue25541] Wrong usage of sockaddr_un struct for abstract namespace unix sockets Message-ID: <1446549321.99.0.809607214975.issue25541@psf.upfronthosting.co.za> New submission from PrzemeK: Case: http://stackoverflow.com/questions/33465094/connection-refused-when-using-abstract-namespace-unix-sockets The code that does not work (python3 example): ... sock_path = b"/var/tmp/sock.tmp" server.bind(b"\0" + sock_path) ... and strace shows: connect(3, {sa_family=AF_LOCAL, sun_path=@"/var/tmp/sock.tmp"}, 20) = -1 ECONNREFUSED (Connection refused) For C-written client strace shows: connect(3, {sa_family=AF_LOCAL, sun_path=@"/var/tmp/sock.tmp"}, 110) = 0 The code that actually works (python3 example): ... sun_path_len = 108 sock_path = b"/var/tmp/sock.tmp" server.bind(b"\0" + sock_path + (b"\0" * (sun_path_len - len(sock_path) - 1))) ... and strace shows: bind(3, {sa_family=AF_LOCAL, sun_path=@"/var/tmp/sock.tmp"}, 110) = 0 110 it's the correst size of a struct. There's no hint at https://docs.python.org/3/library/socket.html#socket-families for that. Test files (servers and clients): https://gist.github.com/soutys/ffbe2e76a86835a9cc6b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 06:23:44 2015 From: report at bugs.python.org (PrzemeK) Date: Tue, 03 Nov 2015 11:23:44 +0000 Subject: [issue25541] Wrong usage of sockaddr_un struct for abstract namespace unix sockets In-Reply-To: <1446549321.99.0.809607214975.issue25541@psf.upfronthosting.co.za> Message-ID: <1446549824.63.0.0904825992096.issue25541@psf.upfronthosting.co.za> PrzemeK added the comment: Errata - 1st paragraph should be: The code that does not work (python3 example): ... sock_path = b"/var/tmp/sock.tmp" server.bind(b"\0" + sock_path) ... and strace shows: bind(3, {sa_family=AF_LOCAL, sun_path=@"/var/tmp/sock.tmp"...}, 20) = 0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 06:26:12 2015 From: report at bugs.python.org (Shin Dong-won) Date: Tue, 03 Nov 2015 11:26:12 +0000 Subject: [issue25539] python3 fail on parsing http header In-Reply-To: <1446532683.92.0.439898298366.issue25539@psf.upfronthosting.co.za> Message-ID: <1446549972.3.0.153089658909.issue25539@psf.upfronthosting.co.za> Shin Dong-won added the comment: I monkey patched the method `parse_headers` to print what the fp read and finally arrived at that http.client is not a problem. email.parser.Parser.parsestr adds two '\n' between two lines of "P3P: ~~". end: b'POST /bbs/login_check.php HTTP/1.1\r\nHost: www.koreapas.com\r\nAccept-Encoding: identity\r\nContent-Length: 31\r\nUser-Agent: Mozilla/5.0 (Linux; Android 4.2.2; GT-I9505 Build/JDQ39) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.59 Mobile Safari/537.36\r\nContent-Type: application/x-www-form-urlencoded\r\n\r\nuser_id=blahsdfi&password=qwera' reply: 'HTTP/1.1 200 OK\r\n' b'Date: Tue, 03 Nov 2015 11:23:16 GMT\r\n' b'Server: Apache/2.2.20 (Unix) mod_ssl/2.2.20 OpenSSL/0.9.8e-fips-rhel5 DAV/2 PHP/5.2.16 mod_fastcgi/2.4.6\r\n' b'X-Powered-By: PHP/5.2.16\r\n' b'P3P: CP="NOI CURa ADMa DEVa TAIa OUR DELa BUS IND PHY ONL UNI COM NAV INT DEM PRE"\r\n' b'P3P : CP="ALL CURa ADMa DEVa TAIa OUR BUS IND PHY ONL UNI PUR FIN COM NAV INT DEM CNT STA POL HEA PRE LOC OTC"\r\n' b'Set-Cookie: PHPSESSID=e990184309013a2c97579c76a52e203a; path=/\r\n' b'Content-Length: 1504\r\n' b'Connection: close\r\n' b'Content-Type: text/html\r\n' b'\r\n' ########################## hstring Date: Tue, 03 Nov 2015 11:23:16 GMT Server: Apache/2.2.20 (Unix) mod_ssl/2.2.20 OpenSSL/0.9.8e-fips-rhel5 DAV/2 PHP/5.2.16 mod_fastcgi/2.4.6 X-Powered-By: PHP/5.2.16 P3P: CP="NOI CURa ADMa DEVa TAIa OUR DELa BUS IND PHY ONL UNI COM NAV INT DEM PRE" P3P : CP="ALL CURa ADMa DEVa TAIa OUR BUS IND PHY ONL UNI PUR FIN COM NAV INT DEM CNT STA POL HEA PRE LOC OTC" Set-Cookie: PHPSESSID=e990184309013a2c97579c76a52e203a; path=/ Content-Length: 1504 Connection: close Content-Type: text/html ###################################### ########################### parsed b'Date: Tue, 03 Nov 2015 11:23:16 GMT\nServer: Apache/2.2.20 (Unix) mod_ssl/2.2.20 OpenSSL/0.9.8e-fips-rhel5 DAV/2\n PHP/5.2.16 mod_fastcgi/2.4.6\nX-Powered-By: PHP/5.2.16\nP3P: CP="NOI CURa ADMa DEVa TAIa OUR DELa BUS IND PHY ONL UNI COM NAV INT DEM\n PRE"\n\nP3P : CP="ALL CURa ADMa DEVa TAIa OUR BUS IND PHY ONL UNI PUR FIN COM NAV INT DEM CNT STA POL HEA PRE LOC OTC"\nSet-Cookie: PHPSESSID=e990184309013a2c97579c76a52e203a; path=/\nContent-Length: 1504\nConnection: close\nContent-Type: text/html\n\n' ####################################### ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 06:54:33 2015 From: report at bugs.python.org (Shin Dong-won) Date: Tue, 03 Nov 2015 11:54:33 +0000 Subject: [issue25539] python3 fail on parsing http header In-Reply-To: <1446532683.92.0.439898298366.issue25539@psf.upfronthosting.co.za> Message-ID: <1446551673.86.0.112944904973.issue25539@psf.upfronthosting.co.za> Shin Dong-won added the comment: I found that Python3 no more uses header format from rfc822, and the data b'P3P : CP="ALL CURa ADMa DEVa TAIa OUR BUS IND PHY ONL UNI PUR FIN COM NAV INT DEM CNT STA POL HEA PRE LOC OTC"\r\n' not match with `headerRE = re.compile(r'^(From |[\041-\071\073-\176]*:|[\t ])')` so it makes problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 07:30:08 2015 From: report at bugs.python.org (Mario Wenzel) Date: Tue, 03 Nov 2015 12:30:08 +0000 Subject: [issue25542] tuple unpacking on assignment should be lazy for unpacked generators Message-ID: <1446553808.55.0.885073556118.issue25542@psf.upfronthosting.co.za> New submission from Mario Wenzel: if I have an assignment a = then a is the generator. But if I do any kind of unpacking *a, = # a list of all items a, *aa = # first item in a, list of rest in as If the right-hand side is a generator expression, I would expect that a, *aa unpacks the first element into a and puts the whole generator (having yielded the first element) back into aa. So the star-operator of tuple unpacking with the right-hand-side having a generator should be lazy and not exhaust the whole generator. ---------- components: Interpreter Core messages: 253985 nosy: Mario Wenzel priority: normal severity: normal status: open title: tuple unpacking on assignment should be lazy for unpacked generators type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 07:56:34 2015 From: report at bugs.python.org (Chris Withers) Date: Tue, 03 Nov 2015 12:56:34 +0000 Subject: [issue25532] infinite loop when running inspect.unwrap over unittest.mock.call In-Reply-To: <1446421817.99.0.495650724157.issue25532@psf.upfronthosting.co.za> Message-ID: <1446555394.68.0.214846671136.issue25532@psf.upfronthosting.co.za> Chris Withers added the comment: Indeed, I guess Venusian will get confused, but not sure thats solvable as there will be obvious bugs indicating that call shouldn't be imported at module-level. This does feel like the problem is actually with inspect.unwrap: there's evidence of an attempt to catch infinite loops like this and blow up with a ValueError, it just doesn't appear those checks are good enough. How many levels of unwrapping are reasonable? 1? 5? 100? It feels like the loop detection should be count, not set-of-ids based... The other optional we be for _Call instances to be generative only in the right context, or only to a certain depth (10? how deep can one set of calls realistically be?) I suspect both should probably happen... Thoughts? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 08:06:14 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 03 Nov 2015 13:06:14 +0000 Subject: [issue25300] Enable Intel MPX (Memory protection Extensions) feature In-Reply-To: <1443788737.62.0.174147088714.issue25300@psf.upfronthosting.co.za> Message-ID: <1446555974.63.0.906453052807.issue25300@psf.upfronthosting.co.za> Raymond Hettinger added the comment: [ Stefan Krah] > I'd suggest to wait until the mpx support is stable in gcc. I concur. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 08:08:21 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 03 Nov 2015 13:08:21 +0000 Subject: [issue25542] tuple unpacking on assignment should be lazy for unpacked generators In-Reply-To: <1446553808.55.0.885073556118.issue25542@psf.upfronthosting.co.za> Message-ID: <1446556101.23.0.656654195955.issue25542@psf.upfronthosting.co.za> Martin Panter added the comment: But when the starred element is not the final one, it couldn?t be lazy, so you would end up with an inconsistency. a, *rest, z = Also, it would be inconsistent with other kinds of iterables, which get turned into list objects. >>> a, *aa = (1, 2) >>> aa [2] >>> a, *aa = "abc" >>> aa ['b', 'c'] ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 08:30:18 2015 From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=) Date: Tue, 03 Nov 2015 13:30:18 +0000 Subject: [issue25543] locale.atof keep '.' even if not part of the localeconv Message-ID: <1446557418.04.0.0373772163699.issue25543@psf.upfronthosting.co.za> New submission from C?dric Krier: If a value containing '.' is passed to locale.atof, but '.' is not the locale decimal_point (and not the thousands_sep), it is anyway parsed as the decimal_point. For me, it should raise a ValueError ---------- components: Library (Lib) messages: 253989 nosy: ced priority: normal severity: normal status: open title: locale.atof keep '.' even if not part of the localeconv type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 08:34:01 2015 From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=) Date: Tue, 03 Nov 2015 13:34:01 +0000 Subject: [issue25543] locale.atof keep '.' even if not part of the localeconv In-Reply-To: <1446557418.04.0.0373772163699.issue25543@psf.upfronthosting.co.za> Message-ID: <1446557641.85.0.512474473509.issue25543@psf.upfronthosting.co.za> C?dric Krier added the comment: Example: >>> import locale >>> locale.setlocale(locale.LC_ALL, 'fr_FR.UTF-8') 'fr_FR.UTF-8' >>> locale.atof('2.5') 2.5 >>> locale.atof('2,5') 2.5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 08:39:30 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 03 Nov 2015 13:39:30 +0000 Subject: [issue25543] locale.atof keep '.' even if not part of the localeconv In-Reply-To: <1446557418.04.0.0373772163699.issue25543@psf.upfronthosting.co.za> Message-ID: <1446557970.8.0.995865037716.issue25543@psf.upfronthosting.co.za> STINNER Victor added the comment: locale.atof() is implemented as float(locale.delocalize(string)). locale.delocalize() replaces the locale numeric dot with ".": >>> locale.setlocale(locale.LC_ALL, 'fr_FR.UTF-8') 'fr_FR.UTF-8' >>> locale.delocalize("1,2") '1.2' >>> locale.localeconv()['decimal_point'] ',' >>> locale.delocalize("1.2") '1.2' I'm not sure that it's very useful to break backward compatibility to be more strict. locale.delocalize() and locale.atof() are a few lines of Python, it's probably worth to copy them and modify them to get the expected behaviour. ---------- nosy: +haypo versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 08:51:34 2015 From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=) Date: Tue, 03 Nov 2015 13:51:34 +0000 Subject: [issue25543] locale.atof keep '.' even if not part of the localeconv In-Reply-To: <1446557418.04.0.0373772163699.issue25543@psf.upfronthosting.co.za> Message-ID: <1446558694.72.0.86897382495.issue25543@psf.upfronthosting.co.za> C?dric Krier added the comment: But you can have some strange behaviour: >>> import locale >>> locale.setlocale(locale.LC_ALL, 'fr_FR.UTF-8') 'fr_FR.UTF-8' >>> locale.atof('2.500,5') Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python2.7/locale.py", line 316, in atof return func(string) ValueError: invalid literal for float(): 2.500.5 >>> locale.atof('2.500') 2.5 If you agree to make it more strict, I can work on a patch, otherwise I will just add some tests on my code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 09:05:19 2015 From: report at bugs.python.org (Albert White) Date: Tue, 03 Nov 2015 14:05:19 +0000 Subject: [issue9694] argparse required arguments displayed under "optional arguments" In-Reply-To: <1282846759.11.0.900867962743.issue9694@psf.upfronthosting.co.za> Message-ID: <1446559519.06.0.369057918076.issue9694@psf.upfronthosting.co.za> Changes by Albert White : ---------- nosy: +Albert White _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 09:15:46 2015 From: report at bugs.python.org (Min RK) Date: Tue, 03 Nov 2015 14:15:46 +0000 Subject: [issue25544] cleanup temporary files in distutils.has_function Message-ID: <1446560146.63.0.814875607484.issue25544@psf.upfronthosting.co.za> New submission from Min RK: One of the nits noted in http://bugs.python.org/issue717152, which introduced ccompiler.has_function, was that it does not clean up after itself. This patch uses a TemporaryDirectory context to ensure that the files created during has_function are cleaned up. ---------- components: Distutils files: 0001-cleanup-temporary-files-in-ccompiler.has_function.patch keywords: patch messages: 253993 nosy: dstufft, eric.araujo, minrk priority: normal severity: normal status: open title: cleanup temporary files in distutils.has_function type: enhancement versions: Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file40933/0001-cleanup-temporary-files-in-ccompiler.has_function.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 09:43:30 2015 From: report at bugs.python.org (Christian Tanzer) Date: Tue, 03 Nov 2015 14:43:30 +0000 Subject: [issue25545] email.message.get_payload returns wrong encoding Message-ID: <1446561810.16.0.921085816129.issue25545@psf.upfronthosting.co.za> New submission from Christian Tanzer: For an email message with `Content-type: text/plain; charset=utf-8`, in Python 3.5, get_payload returns a bytes object encoded with `latin-1`. Python 2.7 returns a str object encoded with `utf-8` as expected. Running the attached test script `email_get_payload__test.py` with Python 2.7 and 3.5 shows the difference. Python 2.7:: 2.7.10.final.0 *** utf8 *** From: Christian Tanzer To: Christian Tanzer Content-type: text/plain; charset=utf-8 Sehr geehrte Damen und Herren, ... Danke und mit freundlichen Gr?ssen, -- Christian Tanzer http://www.c-tanzer.at/ Python 3.5:: 3.5.0.final.0 *** latin-1 *** From: Christian Tanzer To: Christian Tanzer Content-type: text/plain; charset=utf-8 Sehr geehrte Damen und Herren, ... Danke und mit freundlichen Gr?ssen, -- Christian Tanzer http://www.c-tanzer.at/ In both Python versions, `msg.get_content_charset()` returns None, which is not correct, either. ---------- components: Library (Lib) files: email_get_payload__test.py messages: 253994 nosy: tanzer at swing.co.at priority: normal severity: normal status: open title: email.message.get_payload returns wrong encoding type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file40934/email_get_payload__test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 10:10:48 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 03 Nov 2015 15:10:48 +0000 Subject: [issue25537] Call `isinstance` instead of `issubclass` during exception handling In-Reply-To: <1446498626.24.0.0841734313123.issue25537@psf.upfronthosting.co.za> Message-ID: <1446563448.6.0.594037522933.issue25537@psf.upfronthosting.co.za> R. David Murray added the comment: Ah, now I understand. That is definitely not something that could go into 2.7. It is also a level of change that would need to go to python-ideas first, and possibly even a PEP. Closing this pending such a discussion. ---------- dependencies: -Catching virtual subclasses in except clauses resolution: -> later stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 10:20:48 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 03 Nov 2015 15:20:48 +0000 Subject: [issue25538] Traceback from __exit__ method is misleading In-Reply-To: <1446505683.0.0.402181965789.issue25538@psf.upfronthosting.co.za> Message-ID: <1446564048.51.0.67716228615.issue25538@psf.upfronthosting.co.za> R. David Murray added the comment: What caught me out was more like this (but more complicated so it wasn't obvious the line mentioned wasn't part of the exception chain; in fact it looked like it was since it was a line that could very well have raised the exception in question): rdmurray at pydev:~/python/p36>cat temp.py def do_something(): try: foo() except Exception: print('caught in do_something') raise def foo(): with cm(): print('all is well') class cm: def __enter__(self): return self def __exit__(*args, **kw): raise Exception('exception in __exit__') do_something() rdmurray at pydev:~/python/p36>./python temp.py all is well caught in do_something Traceback (most recent call last): File "temp.py", line 20, in do_something() File "temp.py", line 3, in do_something foo() File "temp.py", line 10, in foo print('all is well') File "temp.py", line 18, in __exit__ raise Exception('exception in __exit__') Exception: exception in __exit__ The confusing line in the traceback is "print('all is well')", which obviously isn't raising the exception. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 10:41:13 2015 From: report at bugs.python.org (Ryan Franklin) Date: Tue, 03 Nov 2015 15:41:13 +0000 Subject: [issue25546] python 3.5 installation problem; Error 0x80240017: Failed to execute MSU package Message-ID: <1446565273.63.0.514880871574.issue25546@psf.upfronthosting.co.za> New submission from Ryan Franklin: Python 3.5 will not install on my Windows 7 Pro machine. The observed failure is : Error 0x80240017: Failed to execute MSU package. This appears to be an open problem with Python 3.5. The same does not have any problems with the Python 3.4.1 installations. ---------- files: Python 3.5.0 (64-bit)_20151103101640.log messages: 253998 nosy: rfrank1234 priority: normal severity: normal status: open title: python 3.5 installation problem; Error 0x80240017: Failed to execute MSU package type: behavior Added file: http://bugs.python.org/file40935/Python 3.5.0 (64-bit)_20151103101640.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 11:12:08 2015 From: report at bugs.python.org (Eric V. Smith) Date: Tue, 03 Nov 2015 16:12:08 +0000 Subject: [issue25543] locale.atof keep '.' even if not part of the localeconv In-Reply-To: <1446557418.04.0.0373772163699.issue25543@psf.upfronthosting.co.za> Message-ID: <1446567128.9.0.365102627256.issue25543@psf.upfronthosting.co.za> Eric V. Smith added the comment: That's an unfortunate implementation choice. I agree we probably can't break locale.atof, but how about adding another function with a better implementation, that's strictly locale-aware? ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 11:21:23 2015 From: report at bugs.python.org (Brett Cannon) Date: Tue, 03 Nov 2015 16:21:23 +0000 Subject: [issue25533] Make pkgutil.iter_modules() yield built-in modules In-Reply-To: <1446462853.43.0.928344730721.issue25533@psf.upfronthosting.co.za> Message-ID: <1446567683.95.0.295084591356.issue25533@psf.upfronthosting.co.za> Brett Cannon added the comment: The lack of a way to list frozen modules was why I brought it up. :) And built-in packages are not currently supported, but they theoretically could be if someone put in the work (I think there's an issue for that somewhere). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 11:37:59 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 03 Nov 2015 16:37:59 +0000 Subject: [issue24097] Use after free in PyObject_GetState In-Reply-To: <1430489135.55.0.4914099481.issue24097@psf.upfronthosting.co.za> Message-ID: <1446568679.23.0.21969881492.issue24097@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: pitrou -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 11:49:21 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 03 Nov 2015 16:49:21 +0000 Subject: [issue24097] Use after free in PyObject_GetState In-Reply-To: <1430489135.55.0.4914099481.issue24097@psf.upfronthosting.co.za> Message-ID: <1446569361.36.0.187223692361.issue24097@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: In 2.7 the test doesn't crash, but __reduce__ produces invalid recursive structure. ---------- versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 11:51:47 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 03 Nov 2015 16:51:47 +0000 Subject: [issue24097] Use after free in PyObject_GetState In-Reply-To: <1430489135.55.0.4914099481.issue24097@psf.upfronthosting.co.za> Message-ID: <1446569507.11.0.723203803138.issue24097@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is backported to 2.7 patch with test. Can you review the test and commit the patch Antoine? ---------- assignee: serhiy.storchaka -> pitrou Added file: http://bugs.python.org/file40936/getstate_borrowed_ref_with_test-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 11:52:04 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 03 Nov 2015 16:52:04 +0000 Subject: [issue24097] Use after free in PyObject_GetState In-Reply-To: <1430489135.55.0.4914099481.issue24097@psf.upfronthosting.co.za> Message-ID: <1446569524.87.0.630497829226.issue24097@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file40937/getstate_borrowed_ref_with_test-3.4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 11:53:57 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 03 Nov 2015 16:53:57 +0000 Subject: [issue892902] problem with pickling newstyle class instances Message-ID: <1446569637.48.0.808397240056.issue892902@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could you please make a review Alexandre? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 12:24:34 2015 From: report at bugs.python.org (desbma) Date: Tue, 03 Nov 2015 17:24:34 +0000 Subject: [issue25061] Add native enum support for argparse In-Reply-To: <1441908245.42.0.23532628335.issue25061@psf.upfronthosting.co.za> Message-ID: <1446571474.73.0.115120862249.issue25061@psf.upfronthosting.co.za> desbma added the comment: I came up with something that satisfies my needs (no boilerplate code, and intuitive add_argument call). I modified your factory, and defined a simple action class (this is a quick and dirty prototype for discussion, I am in no way asking that such thing should be merged as such): class EnumType(object): """Factory for creating enum object types """ def __init__(self, enumclass, action): self.enums = enumclass self.action = action def __call__(self, astring): name = self.enums.__name__ try: v = self.enums[astring.upper()] except KeyError: msg = ', '.join([t.name.lower() for t in self.enums]) msg = '%s: use one of {%s}'%(name, msg) raise argparse.ArgumentTypeError(msg) else: self.action.choices = None # hugly hack to prevent post validation from choices return v def __repr__(self): astr = ', '.join([t.name.lower() for t in self.enums]) return '%s(%s)' % (self.enums.__name__, astr) class StoreEnumAction(argparse._StoreAction): def __init__(self, option_strings, dest, type, nargs=None, const=None, default=None, required=False, help=None, metavar=None): super().__init__(option_strings=option_strings, dest=dest, nargs=nargs, const=const, default=default, type=EnumType(type, self), choices=tuple(t.name.lower() for t in type), required=required, help=help, metavar=metavar) Then all I have to do is to pass 'action=StoreEnumAction, type=TheEnum' to the add_argument call. The good: I get a proper usage line (which takes into account the value of 'nargs'), relevant error messages, and what is stored in the namespace after validation is the proper enum type, not a string. The bad: * The reference to the action inside the factory is ugly. This should probably be refractored to be all contained inside StoreEnumAction. * The meaning of the 'type' parameter for StoreEnumAction is somewhat different than for other actions (enum class vs callable that validates) What do you think? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 12:44:05 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 03 Nov 2015 17:44:05 +0000 Subject: [issue25061] Add native enum support for argparse In-Reply-To: <1441908245.42.0.23532628335.issue25061@psf.upfronthosting.co.za> Message-ID: <1446572645.47.0.0102988491311.issue25061@psf.upfronthosting.co.za> Raymond Hettinger added the comment: IMO, this adds more complexity than it solves. Argparse already has more options than people can remember. Also, it isn't clear whether this logic should go into the parser or into the business logic (consider for example that the requests package doesn't autogenerate enum results, not does sqlite) -- the extraction of values is a distinct step. ---------- assignee: -> bethard nosy: +bethard, rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 12:45:35 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 03 Nov 2015 17:45:35 +0000 Subject: [issue25483] Improve f-string implementation: FORMAT_VALUE opcode In-Reply-To: <1445874299.22.0.773155754186.issue25483@psf.upfronthosting.co.za> Message-ID: <20151103174522.97295.79285@psf.io> Roundup Robot added the comment: New changeset 1ddeb2e175df by Eric V. Smith in branch 'default': Issue 25483: Add an opcode to make f-string formatting more robust. https://hg.python.org/cpython/rev/1ddeb2e175df ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 12:49:00 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 03 Nov 2015 17:49:00 +0000 Subject: [issue25547] Improve repr for files to show whether the file is open or closed. Message-ID: <1446572940.81.0.863832720658.issue25547@psf.upfronthosting.co.za> New submission from Raymond Hettinger: Good news in Python 3.5, the __repr__ for locks now indicates whether the lock is in a locked state. Bad news for Python 3.x, the __repr__ for files lost the indication of the file's open/closed status: Python 3: --------- $ python3.5 Python 3.5.0 (v3.5.0:374f501f4567, Sep 12 2015, 11:00:19) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> open('hamlet.txt') <_io.TextIOWrapper name='hamlet.txt' mode='r' encoding='UTF-8'> Python 2: --------- # python2.7 Python 2.7.10 (v2.7.10:15c95b7d81dc, May 23 2015, 09:33:12) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> open('hamlet.txt') ^----- status ---------- assignee: pitrou messages: 254007 nosy: pitrou, rhettinger priority: normal severity: normal stage: needs patch status: open title: Improve repr for files to show whether the file is open or closed. type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 13:09:29 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 03 Nov 2015 18:09:29 +0000 Subject: [issue25483] Improve f-string implementation: FORMAT_VALUE opcode In-Reply-To: <1445874299.22.0.773155754186.issue25483@psf.upfronthosting.co.za> Message-ID: <20151103180917.97287.67317@psf.io> Roundup Robot added the comment: New changeset 4734713a31ed by Eric V. Smith in branch 'default': Issue 25483: Update dis.rst with FORMAT_VALUE opcode description. https://hg.python.org/cpython/rev/4734713a31ed ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 13:13:36 2015 From: report at bugs.python.org (Eric V. Smith) Date: Tue, 03 Nov 2015 18:13:36 +0000 Subject: [issue25483] Improve f-string implementation: FORMAT_VALUE opcode In-Reply-To: <1445874299.22.0.773155754186.issue25483@psf.upfronthosting.co.za> Message-ID: <1446574416.26.0.0421972465704.issue25483@psf.upfronthosting.co.za> Eric V. Smith added the comment: Brett: https://docs.python.org/devguide/compiler.html#introducing-new-bytecode looks correct (and reminded me to update dis.rst!). ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 13:22:33 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 03 Nov 2015 18:22:33 +0000 Subject: [issue25547] Improve repr for files to show whether the file is open or closed. In-Reply-To: <1446572940.81.0.863832720658.issue25547@psf.upfronthosting.co.za> Message-ID: <1446574953.26.0.088440403423.issue25547@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: >>> f = open('/dev/null', 'rb', buffering=0) >>> f <_io.FileIO name='/dev/null' mode='rb' closefd=True> >>> f.close() >>> f <_io.FileIO [closed]> ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 13:36:45 2015 From: report at bugs.python.org (Mouse) Date: Tue, 03 Nov 2015 18:36:45 +0000 Subject: [issue25495] binascii documentation incorrect In-Reply-To: <1445987417.55.0.122139453671.issue25495@psf.upfronthosting.co.za> Message-ID: <1446575805.36.0.641056567545.issue25495@psf.upfronthosting.co.za> Mouse added the comment: The harm in mentioning the 57-byte chunking is that so far it successfully confused people. b2a_base64() function is not coupled to MIME. It has no constraints on either its input, or its output. *IF* it is used by (in) a MIME application, then the caller may want to make its output RFC 2045-compliant, by whatever way he chooses. Giving (an unwelcome) advice to a writer of one specific application is in my opinion completely out of scope here. Justification that it used to matter 25 years ago and therefore should be kept here doesn't make sense to me. I strongly insist that this "chunking" thing does not belong, and must be removed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 13:40:11 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 03 Nov 2015 18:40:11 +0000 Subject: [issue25548] Show the address in the repr for class objects Message-ID: <1446576011.58.0.372024983976.issue25548@psf.upfronthosting.co.za> New submission from Raymond Hettinger: In old-style classes, the memory address of the class object is shown for both the class and for the instance. In new-style classes, only the instance shows the address. I and other Python instructors have found the memory address display to be useful and I think it should be added back: Old-style ========= >>> class A: pass >>> a = A() >>> A >>> a <__main__.A instance at 0x105292cb0> New-style ========= >>> class A(object): pass >>> a = A() >>> A >>> a <__main__.A object at 0x105332cd0> ---------- messages: 254012 nosy: rhettinger priority: normal severity: normal status: open title: Show the address in the repr for class objects type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 14:36:33 2015 From: report at bugs.python.org (Mario Wenzel) Date: Tue, 03 Nov 2015 19:36:33 +0000 Subject: [issue25542] tuple unpacking on assignment should be lazy for unpacked generators In-Reply-To: <1446553808.55.0.885073556118.issue25542@psf.upfronthosting.co.za> Message-ID: <1446579393.43.0.0315405696896.issue25542@psf.upfronthosting.co.za> Mario Wenzel added the comment: You are right. I didn't even know head, *middle, end = worked. Thanks ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 14:59:53 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 03 Nov 2015 19:59:53 +0000 Subject: [issue25545] email.message.get_payload returns wrong encoding In-Reply-To: <1446561810.16.0.921085816129.issue25545@psf.upfronthosting.co.za> Message-ID: <1446580793.55.0.26948453162.issue25545@psf.upfronthosting.co.za> R. David Murray added the comment: Your problem is that your input email is ia unicode string. A unicode string has no RFC defintion as an email, so things do not work right, as you observed. Whether or not email should throw an error when fed a non-ascii unicode string is an interesting question, but it hasn't in the past and so for backward compatibility reasons we won't change that. If you add an "encode('utf-8')" to the end of your email string, and then use message_from_bytes, you will get the correct result. You might also be interested in the newer email API, currently documented in the 'contentmanager' and 'policy' chapters of the documentation. It says it is provisional, but the changes (other than bug fixes) between the current API and what will be final in 3.6 are trivial. get_content_charset is None because you don't have any actual headers in your message, just body. This is because of the leading newline in your triple quoted string, which the email package takes as the end of the headers. ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 15:39:57 2015 From: report at bugs.python.org (Berker Peksag) Date: Tue, 03 Nov 2015 20:39:57 +0000 Subject: [issue25546] python 3.5 installation problem; Error 0x80240017: Failed to execute MSU package In-Reply-To: <1446565273.63.0.514880871574.issue25546@psf.upfronthosting.co.za> Message-ID: <1446583197.38.0.566315517855.issue25546@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 15:48:29 2015 From: report at bugs.python.org (Berker Peksag) Date: Tue, 03 Nov 2015 20:48:29 +0000 Subject: [issue25483] Improve f-string implementation: FORMAT_VALUE opcode In-Reply-To: <1445874299.22.0.773155754186.issue25483@psf.upfronthosting.co.za> Message-ID: <1446583709.91.0.916759785397.issue25483@psf.upfronthosting.co.za> Berker Peksag added the comment: + * ``(flags & 0x03) == 0x00``: *value* is formattedd as-is. Just noticed a small typo: formattedd Also, needs ``.. versionadded:: 3.6`` ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 15:58:30 2015 From: report at bugs.python.org (Hrvoje Abraham) Date: Tue, 03 Nov 2015 20:58:30 +0000 Subject: [issue24663] ast.literal_eval does not handle empty set literals In-Reply-To: <1437240496.13.0.316743645205.issue24663@psf.upfronthosting.co.za> Message-ID: <1446584310.71.0.121107268621.issue24663@psf.upfronthosting.co.za> Hrvoje Abraham added the comment: I believe this is the issue. ast.literal_eval sets support can not be considered complete until it also handles empty sets. I do not consider it valid for me to explicitly handle this case in my projects using some weird hacks. Python community settled on not introducing empty set literal because one can simply use set(), as discussed a few times before. But no corresponding alternative was defined for ast.literal_eval, maybe it should handle 'set()' as such. I strongly advise reopening this issue and finding functional solution for empty set case. I need it! ---------- nosy: +ahrvoje type: -> enhancement versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 16:06:20 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Tue, 03 Nov 2015 21:06:20 +0000 Subject: [issue25548] Show the address in the repr for class objects In-Reply-To: <1446576011.58.0.372024983976.issue25548@psf.upfronthosting.co.za> Message-ID: <1446584780.53.0.330861171304.issue25548@psf.upfronthosting.co.za> St?phane Wirtel added the comment: Hi Raymond, I just executed the code with python 3.5 and I don't have this result: Python 3.5.0 (default, Sep 23 2015, 04:41:38) [GCC 4.2.1 Compatible Apple LLVM 7.0.0 (clang-700.0.72)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> class A: pass ... >>> A >>> class A(object): pass ... >>> A >>> ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 16:29:39 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 03 Nov 2015 21:29:39 +0000 Subject: [issue24663] ast.literal_eval does not handle empty set literals In-Reply-To: <1437240496.13.0.316743645205.issue24663@psf.upfronthosting.co.za> Message-ID: <1446586179.1.0.894747002554.issue24663@psf.upfronthosting.co.za> R. David Murray added the comment: You haven't presented an actual use case, it would be interesting to see one. Regardless of that, however, ast.literal_eval is an exposure of the literal value parsing part of the AST. set() is not part of that, because it is not a literal, it is a function call. There has been some discussion of adding a "safe_eval" function to the stdlib (see issue 22525), and that would be the appropriate place to introduce evaluation of set(). python-ideas would be the appropriate place to discuss safe_eval. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 16:30:52 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 03 Nov 2015 21:30:52 +0000 Subject: [issue25483] Improve f-string implementation: FORMAT_VALUE opcode In-Reply-To: <1445874299.22.0.773155754186.issue25483@psf.upfronthosting.co.za> Message-ID: <20151103213049.18102.92995@psf.io> Roundup Robot added the comment: New changeset 93fd7adbc7dd by Eric V. Smith in branch 'default': Issue 25483: Fix doc typo and added versionadded. Thanks, Berker Peksag. https://hg.python.org/cpython/rev/93fd7adbc7dd ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 16:34:26 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Tue, 03 Nov 2015 21:34:26 +0000 Subject: [issue25543] locale.atof keep '.' even if not part of the localeconv In-Reply-To: <1446557418.04.0.0373772163699.issue25543@psf.upfronthosting.co.za> Message-ID: <1446586466.19.0.464493921956.issue25543@psf.upfronthosting.co.za> St?phane Wirtel added the comment: @eric.smith maybe we can add a new strict function. ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 16:37:42 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Tue, 03 Nov 2015 21:37:42 +0000 Subject: [issue12300] Document pydoc.help In-Reply-To: <1307636340.19.0.379742788124.issue12300@psf.upfronthosting.co.za> Message-ID: <1446586662.09.0.740527034732.issue12300@psf.upfronthosting.co.za> St?phane Wirtel added the comment: What can we do for this issue ? ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 16:48:27 2015 From: report at bugs.python.org (Hrvoje Abraham) Date: Tue, 03 Nov 2015 21:48:27 +0000 Subject: [issue24663] ast.literal_eval does not handle empty set literals In-Reply-To: <1437240496.13.0.316743645205.issue24663@psf.upfronthosting.co.za> Message-ID: <1446587307.39.0.53515888847.issue24663@psf.upfronthosting.co.za> Hrvoje Abraham added the comment: I use communication protocol based on Python literals and ast.literal_eval for deserialization. I'm avoiding sets because empty set value is not supported in a clean consistent manner on language level. If I write repr(set()) i get 'set()', this should matter, maybe. I know I can handle it as a special case, None for empty set, and close my eyes on fact that I lose None value reserved for some other cases. But this really is not a nice thing to do. Please reconsider... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 16:56:10 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 03 Nov 2015 21:56:10 +0000 Subject: [issue12300] Document pydoc.help In-Reply-To: <1307636340.19.0.379742788124.issue12300@psf.upfronthosting.co.za> Message-ID: <1446587770.47.0.900570274325.issue12300@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Close it, which I think ?ric implicitly agreed to in paired issue #12299, where I said more in opposition to this one. What I meant above is that help() is 'listed' in https://docs.python.org/3/library/pydoc.html#module-pydoc. While it does not have usual format there, it is linked to a full entry here https://docs.python.org/3/library/functions.html#help ---------- resolution: -> works for me stage: -> resolved status: open -> closed type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 16:57:33 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 03 Nov 2015 21:57:33 +0000 Subject: [issue24663] ast.literal_eval does not handle empty set literals In-Reply-To: <1437240496.13.0.316743645205.issue24663@psf.upfronthosting.co.za> Message-ID: <1446587853.85.0.768274086917.issue24663@psf.upfronthosting.co.za> R. David Murray added the comment: Like I said, you should take your use case to python-ideas, for a safe_eval that would handle it. literal_eval is not the place for handing 'set()', in my opinion. (There is always a chance other other devs will disagree, but none have so far :). FYI, reprs are often evalable to get back the original value, but the key word there is 'eval', not 'literal_eval'. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 16:58:36 2015 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 03 Nov 2015 21:58:36 +0000 Subject: [issue12300] Document pydoc.help In-Reply-To: <1307636340.19.0.379742788124.issue12300@psf.upfronthosting.co.za> Message-ID: <1446587916.24.0.10587060663.issue12300@psf.upfronthosting.co.za> ?ric Araujo added the comment: Works for me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 17:01:15 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Tue, 03 Nov 2015 22:01:15 +0000 Subject: [issue21243] Auto-generate exceptions.c from a Python file In-Reply-To: <1397585549.14.0.873533303783.issue21243@psf.upfronthosting.co.za> Message-ID: <1446588075.99.0.608550634037.issue21243@psf.upfronthosting.co.za> Changes by St?phane Wirtel : ---------- versions: +Python 3.6 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 17:20:10 2015 From: report at bugs.python.org (Hrvoje Abraham) Date: Tue, 03 Nov 2015 22:20:10 +0000 Subject: [issue24663] ast.literal_eval does not handle empty set literals In-Reply-To: <1437240496.13.0.316743645205.issue24663@psf.upfronthosting.co.za> Message-ID: <1446589210.07.0.495107719401.issue24663@psf.upfronthosting.co.za> Hrvoje Abraham added the comment: For now I'll implement my_literal_eval via AST filtering, reproducing ast.literal_eval + 'set()' functionality. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 17:20:11 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 03 Nov 2015 22:20:11 +0000 Subject: [issue13601] sys.stderr should always be line-buffered In-Reply-To: <1323868292.46.0.495967266587.issue13601@psf.upfronthosting.co.za> Message-ID: <1446589211.89.0.249422074878.issue13601@psf.upfronthosting.co.za> Terry J. Reedy added the comment: As I read this, there was agreement that the status quo is sufficient. That would imply that this should be closed. Correct? ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 17:24:23 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 03 Nov 2015 22:24:23 +0000 Subject: [issue13601] sys.stderr should always be line-buffered In-Reply-To: <1323868292.46.0.495967266587.issue13601@psf.upfronthosting.co.za> Message-ID: <1446589463.43.0.822829756021.issue13601@psf.upfronthosting.co.za> Terry J. Reedy added the comment: A month after this discussion, the flush keyword was added to print, which cover partial lines sent to either stdout or stderr via print. https://bugs.python.org/issue13761 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 17:56:59 2015 From: report at bugs.python.org (Steve Dower) Date: Tue, 03 Nov 2015 22:56:59 +0000 Subject: [issue25546] python 3.5 installation problem; Error 0x80240017: Failed to execute MSU package In-Reply-To: <1446565273.63.0.514880871574.issue25546@psf.upfronthosting.co.za> Message-ID: <1446591419.82.0.616780348182.issue25546@psf.upfronthosting.co.za> Steve Dower added the comment: Can you try installing http://www.microsoft.com/en-us/download/details.aspx?id=48145 and then install Python again? That installer is installing the same update for your machine as Python 3.5 requires, so our installer should skip it once it is on. Alternatively, you may get a more detailed error message. ---------- components: +Installation, Windows nosy: +paul.moore, tim.golden, zach.ware versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 18:39:19 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 03 Nov 2015 23:39:19 +0000 Subject: [issue25537] Call `isinstance` instead of `issubclass` during exception handling In-Reply-To: <1446498626.24.0.0841734313123.issue25537@psf.upfronthosting.co.za> Message-ID: <1446593959.0.0.755326424437.issue25537@psf.upfronthosting.co.za> Martin Panter added the comment: FWIW I don?t see it as a drastic change. If the current patch for Issue 12029 went ahead, I imagine the change for instance checking could look like @@ PyErr_GivenExceptionMatches() - /* err might be an instance, so check its class. */ - if (PyExceptionInstance_Check(err)) - err = PyExceptionInstance_Class(err); @@ given_exception_matches_inner() - res = PyObject_IsSubclass(err, exc); + if (PyExceptionInstance_Check(err)) { + res = PyObject_IsInstance(err, exc); + } else { + res = PyObject_IsSubclass(err, exc); + } ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 18:52:29 2015 From: report at bugs.python.org (Josh Rosenberg) Date: Tue, 03 Nov 2015 23:52:29 +0000 Subject: [issue24379] operator.subscript In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za> Message-ID: <1446594749.45.0.529952802996.issue24379@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Martin: I think the primary reason I suggested an empty __slots__ was to avoid people doing dumb stuff like attaching attributes to the singleton, and then getting annoyed if support for them was removed in some future release (e.g. if this ever moved to C for whatever reason), or expecting them to survive pickling, what have you. The memory savings (if any) would be negligible, it was just to avoid future compatibility concerns. Serhiy: If we add a stub slot, presumably it should be __stub, not __stub__, the former getting the private member name mangling protection while the latter would not (and the latter might give the impression it was some sort of special method/attribute when it was not). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 19:16:21 2015 From: report at bugs.python.org (Larry Hastings) Date: Wed, 04 Nov 2015 00:16:21 +0000 Subject: [issue25446] smtplib.py AUTH LOGIN code messed up sending login and password data since 3.5 In-Reply-To: <1445355692.4.0.944252984253.issue25446@psf.upfronthosting.co.za> Message-ID: <1446596181.31.0.960065012996.issue25446@psf.upfronthosting.co.za> Larry Hastings added the comment: Okay, I'm scheduling 3.5.1rc1 on the assumption that you'll check in by next weekend. If you're going to slip please let me know and I'll slip accordingly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 19:32:26 2015 From: report at bugs.python.org (Brian Cain) Date: Wed, 04 Nov 2015 00:32:26 +0000 Subject: [issue25388] tokenizer crash/misbehavior -- heap use-after-free In-Reply-To: <1444706115.92.0.283351483962.issue25388@psf.upfronthosting.co.za> Message-ID: <1446597146.24.0.76467345844.issue25388@psf.upfronthosting.co.za> Brian Cain added the comment: Sorry, the report would have been clearer if I'd included a build with symbols and a stack trace. The test was inspired by the test from issue24022 (https://hg.python.org/cpython/rev/03b2259c6cd3), it sounds like it should not have been. But indeed it seems like you've reproduced this issue, and you agree it's a bug? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 19:47:46 2015 From: report at bugs.python.org (Brian Cain) Date: Wed, 04 Nov 2015 00:47:46 +0000 Subject: [issue25388] tokenizer crash/misbehavior -- heap use-after-free In-Reply-To: <1444706115.92.0.283351483962.issue25388@psf.upfronthosting.co.za> Message-ID: <1446598066.42.0.398975704215.issue25388@psf.upfronthosting.co.za> Brian Cain added the comment: Here is a more useful ASan report: ================================================================= ==12168==ERROR: AddressSanitizer: heap-use-after-free on address 0x62500001e110 at pc 0x000000697238 bp 0x7fff412b9240 sp 0x7fff412b9238 READ of size 1 at 0x62500001e110 thread T0 #0 0x697237 in tok_nextc /home/brian/src/fuzzpy/cpython/Parser/tokenizer.c:911:20 #1 0x68c63b in tok_get /home/brian/src/fuzzpy/cpython/Parser/tokenizer.c:1460:13 #2 0x689d93 in PyTokenizer_Get /home/brian/src/fuzzpy/cpython/Parser/tokenizer.c:1809:18 #3 0x67fec3 in parsetok /home/brian/src/fuzzpy/cpython/Parser/parsetok.c:208:16 #4 0x6837d4 in PyParser_ParseFileObject /home/brian/src/fuzzpy/cpython/Parser/parsetok.c:134:12 #5 0x52f50c in PyParser_ASTFromFileObject /home/brian/src/fuzzpy/cpython/Python/pythonrun.c:1150:15 #6 0x532e16 in PyRun_FileExFlags /home/brian/src/fuzzpy/cpython/Python/pythonrun.c:916:11 #7 0x52c3f8 in PyRun_SimpleFileExFlags /home/brian/src/fuzzpy/cpython/Python/pythonrun.c:396:13 #8 0x52a460 in PyRun_AnyFileExFlags /home/brian/src/fuzzpy/cpython/Python/pythonrun.c:80:16 #9 0x5cb04a in run_file /home/brian/src/fuzzpy/cpython/Modules/main.c:318:11 #10 0x5c5a42 in Py_Main /home/brian/src/fuzzpy/cpython/Modules/main.c:768:19 #11 0x4fbace in main /home/brian/src/fuzzpy/cpython/./Programs/python.c:69:11 #12 0x7fe8a9a4aa3f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x20a3f) #13 0x431548 in _start (/home/brian/src/fuzzpy/cpython/python+0x431548) 0x62500001e110 is located 16 bytes inside of 8224-byte region [0x62500001e100,0x625000020120) freed by thread T0 here: #0 0x4cdef0 in realloc /home/brian/src/fuzzpy/llvm_src/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:61 #1 0x501280 in _PyMem_RawRealloc /home/brian/src/fuzzpy/cpython/Objects/obmalloc.c:84:12 #2 0x4fc68d in _PyMem_DebugRealloc /home/brian/src/fuzzpy/cpython/Objects/obmalloc.c:1921:18 #3 0x4fdf42 in PyMem_Realloc /home/brian/src/fuzzpy/cpython/Objects/obmalloc.c:343:12 #4 0x69a338 in tok_nextc /home/brian/src/fuzzpy/cpython/Parser/tokenizer.c:1050:34 #5 0x68a2c9 in tok_get /home/brian/src/fuzzpy/cpython/Parser/tokenizer.c:1357:17 #6 0x689d93 in PyTokenizer_Get /home/brian/src/fuzzpy/cpython/Parser/tokenizer.c:1809:18 #7 0x67fec3 in parsetok /home/brian/src/fuzzpy/cpython/Parser/parsetok.c:208:16 #8 0x6837d4 in PyParser_ParseFileObject /home/brian/src/fuzzpy/cpython/Parser/parsetok.c:134:12 #9 0x52f50c in PyParser_ASTFromFileObject /home/brian/src/fuzzpy/cpython/Python/pythonrun.c:1150:15 #10 0x532e16 in PyRun_FileExFlags /home/brian/src/fuzzpy/cpython/Python/pythonrun.c:916:11 #11 0x52c3f8 in PyRun_SimpleFileExFlags /home/brian/src/fuzzpy/cpython/Python/pythonrun.c:396:13 #12 0x52a460 in PyRun_AnyFileExFlags /home/brian/src/fuzzpy/cpython/Python/pythonrun.c:80:16 #13 0x5cb04a in run_file /home/brian/src/fuzzpy/cpython/Modules/main.c:318:11 #14 0x5c5a42 in Py_Main /home/brian/src/fuzzpy/cpython/Modules/main.c:768:19 #15 0x4fbace in main /home/brian/src/fuzzpy/cpython/./Programs/python.c:69:11 #16 0x7fe8a9a4aa3f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x20a3f) previously allocated by thread T0 here: #0 0x4cdb88 in malloc /home/brian/src/fuzzpy/llvm_src/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:40 #1 0x501030 in _PyMem_RawMalloc /home/brian/src/fuzzpy/cpython/Objects/obmalloc.c:62:12 #2 0x5074db in _PyMem_DebugAlloc /home/brian/src/fuzzpy/cpython/Objects/obmalloc.c:1838:22 #3 0x4fc213 in _PyMem_DebugMalloc /home/brian/src/fuzzpy/cpython/Objects/obmalloc.c:1861:12 #4 0x4fdbfa in PyMem_Malloc /home/brian/src/fuzzpy/cpython/Objects/obmalloc.c:325:12 #5 0x68791d in PyTokenizer_FromFile /home/brian/src/fuzzpy/cpython/Parser/tokenizer.c:861:29 #6 0x68359e in PyParser_ParseFileObject /home/brian/src/fuzzpy/cpython/Parser/parsetok.c:126:16 #7 0x52f50c in PyParser_ASTFromFileObject /home/brian/src/fuzzpy/cpython/Python/pythonrun.c:1150:15 #8 0x532e16 in PyRun_FileExFlags /home/brian/src/fuzzpy/cpython/Python/pythonrun.c:916:11 #9 0x52c3f8 in PyRun_SimpleFileExFlags /home/brian/src/fuzzpy/cpython/Python/pythonrun.c:396:13 #10 0x52a460 in PyRun_AnyFileExFlags /home/brian/src/fuzzpy/cpython/Python/pythonrun.c:80:16 #11 0x5cb04a in run_file /home/brian/src/fuzzpy/cpython/Modules/main.c:318:11 #12 0x5c5a42 in Py_Main /home/brian/src/fuzzpy/cpython/Modules/main.c:768:19 #13 0x4fbace in main /home/brian/src/fuzzpy/cpython/./Programs/python.c:69:11 #14 0x7fe8a9a4aa3f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x20a3f) SUMMARY: AddressSanitizer: heap-use-after-free /home/brian/src/fuzzpy/cpython/Parser/tokenizer.c:911:20 in tok_nextc Shadow bytes around the buggy address: 0x0c4a7fffbbd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c4a7fffbbe0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c4a7fffbbf0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c4a7fffbc00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c4a7fffbc10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =>0x0c4a7fffbc20: fd fd[fd]fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c4a7fffbc30: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c4a7fffbc40: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c4a7fffbc50: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c4a7fffbc60: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c4a7fffbc70: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==12168==ABORTING ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 20:27:55 2015 From: report at bugs.python.org (Emanuel Barry) Date: Wed, 04 Nov 2015 01:27:55 +0000 Subject: [issue21243] Auto-generate exceptions.c from a Python file In-Reply-To: <1397585549.14.0.873533303783.issue21243@psf.upfronthosting.co.za> Message-ID: <1446600475.35.0.022811021447.issue21243@psf.upfronthosting.co.za> Changes by Emanuel Barry : ---------- nosy: +ebarry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 20:49:38 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 04 Nov 2015 01:49:38 +0000 Subject: [issue25537] Call `isinstance` instead of `issubclass` during exception handling In-Reply-To: <1446498626.24.0.0841734313123.issue25537@psf.upfronthosting.co.za> Message-ID: <1446601778.44.0.620405226042.issue25537@psf.upfronthosting.co.za> R. David Murray added the comment: The code change may be minor, but the semantic change is not. It needs discussion. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 20:53:04 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 04 Nov 2015 01:53:04 +0000 Subject: [issue25537] Call `isinstance` instead of `issubclass` during exception handling In-Reply-To: <1446498626.24.0.0841734313123.issue25537@psf.upfronthosting.co.za> Message-ID: <1446601984.87.0.579047147829.issue25537@psf.upfronthosting.co.za> R. David Murray added the comment: Let me rephrase that. The semantic change *may* not be. That's what needs discussion :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 21:24:16 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 04 Nov 2015 02:24:16 +0000 Subject: [issue25539] python3 fail on parsing http header In-Reply-To: <1446532683.92.0.439898298366.issue25539@psf.upfronthosting.co.za> Message-ID: <1446603856.11.0.338109393217.issue25539@psf.upfronthosting.co.za> Martin Panter added the comment: Okay, now I understand the problem. There is a quirky header line with a space in the field name ?P3P ?. The HTTP client?s parse_headers() treats this as any other header line, but then it passes the header to the email package, which interprets this line as being invalid and marking the end of the header. Therefore subsequent important header fields are missed, including Set-Cookie and Content-Length. According to , that P3P line is technically not valid. Here is a self-contained demo or test case: from socket import socket from threading import Thread from http.client import HTTPConnection def serve(): [client, _] = server.accept() with client, client.makefile("rb") as reader: while reader.readline().rstrip(b"\r\n"): pass client.sendall( b"HTTP/1.1 200 OK\r\n" b"Content-Length: 0\r\n" b"Extra-Space : invalid\r\n" b"Set-Cookie: name=value\r\n" b"\r\n" ) with socket() as server: server.bind(("localhost", 0)) server.listen() background = Thread(target=serve) background.start() http = HTTPConnection(*server.getsockname()) http.request("GET", "/") response = http.getresponse() print(response.msg.items()) # Set-Cookie is missing http.close() background.join() The question is, should Python go out of its way to handle this server bug? It would probably require implementing a more permissive version of the header parser in the HTTP client, rather than reusing the stricter ?email? module?s parser. ---------- versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 21:57:57 2015 From: report at bugs.python.org (John Mark Vandenberg) Date: Wed, 04 Nov 2015 02:57:57 +0000 Subject: [issue1650090] doctest doesn't find nested functions Message-ID: <1446605877.37.0.306121758656.issue1650090@psf.upfronthosting.co.za> Changes by John Mark Vandenberg : ---------- nosy: +John.Mark.Vandenberg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 22:02:19 2015 From: report at bugs.python.org (John Mark Vandenberg) Date: Wed, 04 Nov 2015 03:02:19 +0000 Subject: [issue12790] doctest.testmod does not run tests in functools.partial functions In-Reply-To: <1313812473.15.0.9197967798.issue12790@psf.upfronthosting.co.za> Message-ID: <1446606139.7.0.355881199642.issue12790@psf.upfronthosting.co.za> Changes by John Mark Vandenberg : ---------- nosy: +John.Mark.Vandenberg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 22:02:29 2015 From: report at bugs.python.org (John Mark Vandenberg) Date: Wed, 04 Nov 2015 03:02:29 +0000 Subject: [issue24925] Allow doctest to find line number of __test__ strings if formatted as a triple quoted string. In-Reply-To: <1440433204.72.0.951879790885.issue24925@psf.upfronthosting.co.za> Message-ID: <1446606149.4.0.565020840343.issue24925@psf.upfronthosting.co.za> Changes by John Mark Vandenberg : ---------- nosy: +John.Mark.Vandenberg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 22:02:37 2015 From: report at bugs.python.org (John Mark Vandenberg) Date: Wed, 04 Nov 2015 03:02:37 +0000 Subject: [issue2275] urllib/httplib header capitalization In-Reply-To: <1205270540.47.0.336665756101.issue2275@psf.upfronthosting.co.za> Message-ID: <1446606157.21.0.330979260051.issue2275@psf.upfronthosting.co.za> Changes by John Mark Vandenberg : ---------- nosy: +John.Mark.Vandenberg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 23:11:47 2015 From: report at bugs.python.org (Kevin Jing Qiu) Date: Wed, 04 Nov 2015 04:11:47 +0000 Subject: [issue25549] call sum on list of timedelta throws TypeError Message-ID: <1446610306.98.0.69863764968.issue25549@psf.upfronthosting.co.za> New submission from Kevin Jing Qiu: Calling sum() on a list of timedelta objects results in TypeError: unsupported operand type(s) for +: 'int' and 'datetime.timedelta' Here's a script that illustrates this behaviour: (also attached) import datetime x = [datetime.timedelta(1), datetime.timedelta(2)] print(x[0] + x[1]) # datetime.timedelta(3) print(sum(x)) # TypeError: unsupported operand type(s) for +: 'int' and 'datetime.timedelta' The bug is present in all version of Python 2 and Python 3 ---------- components: Library (Lib) files: demo.py messages: 254038 nosy: kevinjqiu priority: normal severity: normal status: open title: call sum on list of timedelta throws TypeError type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file40938/demo.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 3 23:34:27 2015 From: report at bugs.python.org (Emanuel Barry) Date: Wed, 04 Nov 2015 04:34:27 +0000 Subject: [issue25549] call sum on list of timedelta throws TypeError In-Reply-To: <1446610306.98.0.69863764968.issue25549@psf.upfronthosting.co.za> Message-ID: <1446611667.03.0.404353938924.issue25549@psf.upfronthosting.co.za> Emanuel Barry added the comment: `sum` has an optional `start` parameter, which defaults to 0, and is used as the first item to add. Since timedeltas and ints are not interoperable, that means you have to explicitly tell sum what to use. The following code works: >>> e=[datetime.timedelta(3), datetime.timedelta(5)] >>> sum(e, datetime.timedelta(0)) datetime.timedelta(8) This is not a bug, but maybe this could use a more descriptive error message? I don't know. ---------- nosy: +ebarry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 4 03:54:37 2015 From: report at bugs.python.org (Evgeny Kapun) Date: Wed, 04 Nov 2015 08:54:37 +0000 Subject: [issue2142] difflib.unified_diff(...) produces invalid patches In-Reply-To: <1203365817.7.0.0998491412302.issue2142@psf.upfronthosting.co.za> Message-ID: <1446627277.87.0.745181433949.issue2142@psf.upfronthosting.co.za> Changes by Evgeny Kapun : ---------- nosy: +abacabadabacaba _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 4 04:02:56 2015 From: report at bugs.python.org (Florian Bruhin) Date: Wed, 04 Nov 2015 09:02:56 +0000 Subject: [issue25550] RecursionError in re with '(' * 500 Message-ID: <1446627776.2.0.048563717292.issue25550@psf.upfronthosting.co.za> New submission from Florian Bruhin: I just found this thanks to Hypothesis[1]: >>> import re >>> re.compile('(' * 500) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.5/re.py", line 224, in compile return _compile(pattern, flags) File "/usr/lib/python3.5/re.py", line 293, in _compile p = sre_compile.compile(pattern, flags) File "/usr/lib/python3.5/sre_compile.py", line 536, in compile p = sre_parse.parse(p, flags) File "/usr/lib/python3.5/sre_parse.py", line 829, in parse p = _parse_sub(source, pattern, 0) File "/usr/lib/python3.5/sre_parse.py", line 437, in _parse_sub itemsappend(_parse(source, state)) File "/usr/lib/python3.5/sre_parse.py", line 778, in _parse p = _parse_sub(source, state) File "/usr/lib/python3.5/sre_parse.py", line 437, in _parse_sub itemsappend(_parse(source, state)) File "/usr/lib/python3.5/sre_parse.py", line 778, in _parse p = _parse_sub(source, state) File "/usr/lib/python3.5/sre_parse.py", line 437, in _parse_sub itemsappend(_parse(source, state)) [...] File "/usr/lib/python3.5/sre_parse.py", line 493, in _parse subpattern = SubPattern(state) RecursionError: maximum recursion depth exceeded It seems a maximum recursion error has been treated as a bug before (like in issue401612), so I'm guessing this isn't intended here either. [1] https://hypothesis.readthedocs.org/ ---------- components: Library (Lib) messages: 254040 nosy: The Compiler, effbot, ezio.melotti, pitrou, serhiy.storchaka priority: normal severity: normal status: open title: RecursionError in re with '(' * 500 type: behavior versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 4 04:04:29 2015 From: report at bugs.python.org (Christian Tanzer) Date: Wed, 04 Nov 2015 09:04:29 +0000 Subject: [issue25545] email.message.get_payload returns wrong encoding In-Reply-To: Your message of "Tue, 03 Nov 2015 19:59:53 +0000" <1446580793.55.0.26948453162.issue25545@psf.upfronthosting.co.za> Message-ID: Christian Tanzer added the comment: R. David Murray wrote at Tue, 03 Nov 2015 19:59:53 +0000: > Your problem is that your input email is ia unicode string. A unicode > string has no RFC defintion as an email, so things do not work right, > as you observed. Whether or not email should throw an error when fed > a non-ascii unicode string is an interesting question, but it hasn't > in the past and so for backward compatibility reasons we won't change > that. Excuse me, I am using `email.message_from_string` which is documented to convert a unicode string to an email object. If you are serious `message_from_string` should not even exist! As long as it is there and documented as:: email.message_from_string(s, _class=email.message.Message, *, policy=policy.compat32) Return a message object structure from a string. This is exactly equivalent to Parser().parsestr(s). _class and policy are interpreted as with the Parser class constructor. Changed in version 3.3: Removed the strict argument. Added the policy keyword. your argument is unfounded and this is definitely a serious bug! > You might also be interested in the newer email API, currently > documented in the 'contentmanager' and 'policy' chapters of the > documentation. It says it is provisional, but the changes (other than > bug fixes) between the current API and what will be final in 3.6 are > trivial. I'm using Python 2.7 and only just exploring 3.5. Unfortunately, there are many bugs and your response is a typical example why moving from 2.7 to 3.x is hard. There is gratuitous breakage but the reaction is:: resolution: -> not a bug I would ask you to reconsider that stance. As long as my code needs to support 2.7, use of any new API doesn't fly. After an eventual switch to 3.5 (probably years in the future), I might use new APIs for new code but changing existing code that used to work won't be in the cards > get_content_charset is None because you don't have any actual headers > in your message, just body. This is because of the leading newline in > your triple quoted string, which the email package takes as the end of > the headers. Thanks for the hint. BTW, removing the leading newline doesn't change the buggy behavior of `message_from_string`! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 4 04:07:10 2015 From: report at bugs.python.org (SilentGhost) Date: Wed, 04 Nov 2015 09:07:10 +0000 Subject: [issue25550] RecursionError in re with '(' * 500 In-Reply-To: <1446627776.2.0.048563717292.issue25550@psf.upfronthosting.co.za> Message-ID: <1446628030.77.0.488098266223.issue25550@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- components: +Regular Expressions nosy: +mrabarnett versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 4 04:27:12 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 04 Nov 2015 09:27:12 +0000 Subject: [issue25550] RecursionError in re with '(' * 500 In-Reply-To: <1446627776.2.0.048563717292.issue25550@psf.upfronthosting.co.za> Message-ID: <1446629232.01.0.273591339993.issue25550@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This isn't a bug, this is a limitation of the implementation. Regular expression parser is recursive and Python has a limit for recursion depth. You can increase this limit if needed. >>> import sys, re >>> sys.setrecursionlimit(2000) >>> re.compile('(' * 500) Traceback (most recent call last): File "/home/serhiy/py/cpython/Lib/sre_parse.py", line 437, in _parse_sub itemsappend(_parse(source, state)) File "/home/serhiy/py/cpython/Lib/sre_parse.py", line 778, in _parse p = _parse_sub(source, state) File "/home/serhiy/py/cpython/Lib/sre_parse.py", line 437, in _parse_sub itemsappend(_parse(source, state)) ... File "/home/serhiy/py/cpython/Lib/sre_parse.py", line 778, in _parse p = _parse_sub(source, state) File "/home/serhiy/py/cpython/Lib/sre_parse.py", line 437, in _parse_sub itemsappend(_parse(source, state)) File "/home/serhiy/py/cpython/Lib/sre_parse.py", line 781, in _parse source.tell() - start) sre_constants.error: missing ), unterminated subpattern at position 499 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 4 04:28:22 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 04 Nov 2015 09:28:22 +0000 Subject: [issue25313] IDLE: gracefully handle themes (or keysets, or ...) not present In-Reply-To: <1443983028.38.0.330062493222.issue25313@psf.upfronthosting.co.za> Message-ID: <1446629302.92.0.111910077089.issue25313@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Here is patch with a subdued message to see Help when IDLE Dark is selected. It goes away when something else is selected. I tried no emphasis, colored background, relief, and the dull red text in the patch. I tested, but I want to retest systematically when fresh. Test on *nix would good, though I do not think anything is system specific. Under some conditions, entry 'new = ' is being put in user config-main.cfg [Theme] section. It seems harmless but I hope to track it down, while retesting, before committing. It might just be something I did in my installed idlelib, but I'd like to know. ---------- versions: +Python 3.4 Added file: http://bugs.python.org/file40939/@cfg_text.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 4 04:30:18 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 04 Nov 2015 09:30:18 +0000 Subject: [issue25313] IDLE: gracefully handle themes (or keysets, or ...) not present In-Reply-To: <1443983028.38.0.330062493222.issue25313@psf.upfronthosting.co.za> Message-ID: <1446629418.3.0.230630092468.issue25313@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I also want to document new Current Theme in docstring and maybe comments for future readers. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 4 05:13:19 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 04 Nov 2015 10:13:19 +0000 Subject: [issue25498] Python 3.4.3 core dump with simple sample code In-Reply-To: <1446055572.58.0.349657416945.issue25498@psf.upfronthosting.co.za> Message-ID: <1446631999.23.0.934130562205.issue25498@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: serhiy.storchaka -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 4 05:17:38 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 04 Nov 2015 10:17:38 +0000 Subject: [issue24726] OrderedDict has strange behaviour when dict.__setitem__ is used. In-Reply-To: <1437906052.21.0.35165181866.issue24726@psf.upfronthosting.co.za> Message-ID: <1446632258.13.0.793497847589.issue24726@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 4 05:26:25 2015 From: report at bugs.python.org (Florian Bruhin) Date: Wed, 04 Nov 2015 10:26:25 +0000 Subject: [issue25550] RecursionError in re with '(' * 500 In-Reply-To: <1446627776.2.0.048563717292.issue25550@psf.upfronthosting.co.za> Message-ID: <1446632785.3.0.590011180655.issue25550@psf.upfronthosting.co.za> Florian Bruhin added the comment: I see how it's not possible to compile that pattern as it's using recursion - I don't mind that. However, I think this should be handled and re-raised as a re.error ("Exception raised [...] when some other error occurs during compilation or matching."). I think no matter what the pattern is, it's quite unexpected to get anything other than a re.error (or a TypeError) from re.compile. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 4 05:47:13 2015 From: report at bugs.python.org (desbma) Date: Wed, 04 Nov 2015 10:47:13 +0000 Subject: [issue25061] Add native enum support for argparse In-Reply-To: <1441908245.42.0.23532628335.issue25061@psf.upfronthosting.co.za> Message-ID: <1446634033.85.0.988010851441.issue25061@psf.upfronthosting.co.za> desbma added the comment: I guess the question is whether Enum should be considered a first class 'native' type that deserves support in argparse, or just a tool among others in the stdlib. The fact that Enum is implemented as a class, and lives in a module, tends to lead to the second, but the fact that some constants were converted to enums in the stdlib (like in socket) tends to the first. As a C/C++ developer, I may have a bias towards enums :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 4 05:48:01 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 04 Nov 2015 10:48:01 +0000 Subject: [issue25539] python3 fail on parsing http header In-Reply-To: <1446532683.92.0.439898298366.issue25539@psf.upfronthosting.co.za> Message-ID: <1446634081.79.0.817549166795.issue25539@psf.upfronthosting.co.za> Martin Panter added the comment: Just noticed the whitespace scenario is mentioned at : ''' No whitespace is allowed between the header field-name and colon. In the past, differences in the handling of such whitespace have led to security vulnerabilities in .?.?. response handling. .?.?. A proxy must remove any such whitespace from a response message before forwarding the message downstream. ''' It would not be possible build a proxy that does that using Python 3?s current HTTP client. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 4 05:54:23 2015 From: report at bugs.python.org (Shin Dong-won) Date: Wed, 04 Nov 2015 10:54:23 +0000 Subject: [issue25539] python3 fail on parsing http header In-Reply-To: <1446532683.92.0.439898298366.issue25539@psf.upfronthosting.co.za> Message-ID: <1446634463.41.0.357173071311.issue25539@psf.upfronthosting.co.za> Shin Dong-won added the comment: Yeah, this is server's fault and python does not have to deal with non-standard cases. I'll close this issue. Thanks! ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 4 05:57:34 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 04 Nov 2015 10:57:34 +0000 Subject: [issue5550] [urllib.request]: Comparison of HTTP headers should be insensitive to the case In-Reply-To: <1237870141.83.0.616869799184.issue5550@psf.upfronthosting.co.za> Message-ID: <1446634654.13.0.327449787068.issue5550@psf.upfronthosting.co.za> Martin Panter added the comment: Regarding the original bug reported by Cocobear, I think this is by design. The ?addheaders? attribute seems to serve as a set of default header fields, although this is hardly obvious from the documentation. In fact the current documentation suggests you have to use the application/x-www-form-urlencoded content type for request data. I think the documentation should be relaxed; I opened Issue 23360 about that. The rest of the thread seems to have side-tracked into patches to make Request.has_header() and friends case insensitive. I?ll have to study the threads closer, but I think this side-track is a duplicate of Issue 2275. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 4 07:04:00 2015 From: report at bugs.python.org (John Hagen) Date: Wed, 04 Nov 2015 12:04:00 +0000 Subject: [issue25521] optparse module does not emit DeprecationWarning In-Reply-To: <1446247354.16.0.386152814173.issue25521@psf.upfronthosting.co.za> Message-ID: <1446638640.71.0.0585815835604.issue25521@psf.upfronthosting.co.za> John Hagen added the comment: Is there any consensus on how to move forward with this? I feel there are at least 4 options: 1) Do nothing. Pro: No work. Con: It feels misleading to the user since the docs clearly state it's deprecated. Some users (especially new ones) may miss the fact they should really be using argparse. 2) Throw PendingDeprecationWarning from optparse, and simply suppress it where it's used. Pro: Not as much work. Users of optparse are properly notified. Con: Kicks the can down the road for someone else to have to eventually port off of optparse. 3) Throw PendingDeprecationWarning from optparse and port stdlib modules to argparse. Pro: Seems like the "purest" solution at least from what is indicated in docs that it will no longer be supported. Users of optparse are properly notified. Con: Most amount of work. argparse has some bugs that need to be patched. 4) Some combination of 2) and 3) where some modules are suppressed and others are ported. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 4 08:55:12 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 04 Nov 2015 13:55:12 +0000 Subject: [issue24802] int and float constructing from non NUL-terminated buffer In-Reply-To: <1438830920.07.0.863152787453.issue24802@psf.upfronthosting.co.za> Message-ID: <1446645311.99.0.31330481373.issue24802@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I prefer to merge issue24802 and issue24803 and discuss them at one place. Here is merged and revised patch. The patch is changed. There is a very rare corner case: when the type of argument is a subclass of bytes or bytearray with overloaded tp_as_buffer->bf_getbuffer, returned view can be not NUL terminated. To avoid ambiguity and for unifying with int constructor, I have added special cases for bytes and bytearray (this is also restores pre-issue22896 behavior for int(bytes, base)). Tests are moved and added additional tests for memoryview slices. >>> int(memoryview(b'123')[1:3]) 23 >>> int(memoryview(b'123\x00')[1:3]) 23 >>> int(memoryview(b'123 ')[1:3]) Traceback (most recent call last): File "", line 1, in ValueError: invalid literal for int() with base 10: b'23' >>> int(memoryview(b'123A')[1:3]) Traceback (most recent call last): File "", line 1, in ValueError: invalid literal for int() with base 10: b'23' >>> int(memoryview(b'1234')[1:3]) Traceback (most recent call last): File "", line 1, in ValueError: invalid literal for int() with base 10: b'23' >>> float(memoryview(b'12.3')[1:4]) 2.3 >>> float(memoryview(b'12.3\x00')[1:4]) 2.3 >>> float(memoryview(b'12.3 ')[1:4]) 2.3 >>> float(memoryview(b'12.3A')[1:4]) 2.3 >>> float(memoryview(b'12.34')[1:4]) Traceback (most recent call last): File "", line 1, in ValueError: could not convert string to float: There is similar dangerously looking code for complex. But it is never executed, because complex accepts only one non-numeric type: str. The patch removes this misleading dead code. ---------- title: PyFloat_FromString Buffer Over-read -> int and float constructing from non NUL-terminated buffer Added file: http://bugs.python.org/file40940/int_float_from_buffer.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 4 08:55:56 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 04 Nov 2015 13:55:56 +0000 Subject: [issue24803] PyNumber_Long Buffer Over-read.patch In-Reply-To: <1438831123.13.0.732585298911.issue24803@psf.upfronthosting.co.za> Message-ID: <1446645356.52.0.630502691156.issue24803@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Merged with issue24802. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 4 09:12:56 2015 From: report at bugs.python.org (Jon Snoo) Date: Wed, 04 Nov 2015 14:12:56 +0000 Subject: [issue23760] Tkinter in Python 3.4 on Windows don't post internal clipboard data to the Windows clipboard on exit In-Reply-To: <1427194076.59.0.225721138053.issue23760@psf.upfronthosting.co.za> Message-ID: <1446646376.44.0.430509250972.issue23760@psf.upfronthosting.co.za> Jon Snoo added the comment: I tested the code posted by Victor with Python 3.5 (which uses Tcl/Tk 8.6.4) and I still get an empty clipboard when the script exits. I also downloaded ActiveState's Tcl binary which is also version 8.6.4, and tested the minimal reproducer posted by Serhiy with this wish issue23760.tcl and it works i.e. I get "Result" in the system clipboard. I don't really know what to make of this. ---------- nosy: +Jon Snoo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 4 10:10:42 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 04 Nov 2015 15:10:42 +0000 Subject: [issue23760] Tkinter in Python 3.4 on Windows don't post internal clipboard data to the Windows clipboard on exit In-Reply-To: <1427194076.59.0.225721138053.issue23760@psf.upfronthosting.co.za> Message-ID: <1446649842.25.0.61674480011.issue23760@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Related Tk issues: http://core.tcl.tk/tk/tktview/822002ffffffffffffff http://core.tcl.tk/tk/tktview/732662ffffffffffffff http://core.tcl.tk/tk/tktview/1844034fffffffffffff http://core.tcl.tk/tk/tktview/939389ffffffffffffff The problem should be fixed (at least on Windows) in the last issue, but perhaps Tkinter doesn't execute this code. A workaround is to make a pause about 0.1 sec (can be depend on perfomance of your computer, it doesn't work if the pause is too short). Append following lines to you example: r.after(100, r.destroy) r.mainloop() ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 4 10:19:30 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 04 Nov 2015 15:19:30 +0000 Subject: [issue25539] python3 fail on parsing http header In-Reply-To: <1446532683.92.0.439898298366.issue25539@psf.upfronthosting.co.za> Message-ID: <1446650370.56.0.0366697063014.issue25539@psf.upfronthosting.co.za> R. David Murray added the comment: Support for handling such headers could be added to the new email API (ie: add a policy setting to accept them), if someone wants to make a feature request. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 4 10:22:31 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 04 Nov 2015 15:22:31 +0000 Subject: [issue25549] call sum on list of timedelta throws TypeError In-Reply-To: <1446610306.98.0.69863764968.issue25549@psf.upfronthosting.co.za> Message-ID: <1446650551.43.0.0622738856179.issue25549@psf.upfronthosting.co.za> R. David Murray added the comment: I don't think this warrants a special error message. If you get it, it is obvious you weren't yourself adding an int to a timedelta, so the next logical course of action should be to look at the docs for sum. ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 4 10:36:27 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 04 Nov 2015 15:36:27 +0000 Subject: [issue25545] email parsing docs need to be clear that only ASCII strings are supported In-Reply-To: <1446561810.16.0.921085816129.issue25545@psf.upfronthosting.co.za> Message-ID: <1446651387.54.0.809862214631.issue25545@psf.upfronthosting.co.za> R. David Murray added the comment: There is no problem with supporting both 2.7 and python3 with the same email API as long as your input strings are ASCII only, which is what is required by the email RFCs (as I said, they do not support unicode...even the new one only supports utf8 (a unicode encoding) not unicode itself). So if your input is RFC compliant (using content transfer encoding to encode non-ASCII characters), things will work fine. Just think of unicode as a 7-bit transmission channel (which is what it is from email's perspective). Otherwise the bytes/string issues are no different than they are for any other shared-code-base application. I have an extensive doc rewrite in process, but I'm not sure when it will land. I thought I had already added the note about ASCII-only to the parser docs, but I see that I did not. I'll reopen this issue to remind myself to do that, since the doc rewrite will only apply to 3.6 (when the new API will no longer be provisional). ---------- resolution: not a bug -> stage: resolved -> needs patch status: closed -> open title: email.message.get_payload returns wrong encoding -> email parsing docs need to be clear that only ASCII strings are supported versions: +Python 3.4, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 4 10:44:51 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 04 Nov 2015 15:44:51 +0000 Subject: [issue25521] optparse module does not emit DeprecationWarning In-Reply-To: <1446247354.16.0.386152814173.issue25521@psf.upfronthosting.co.za> Message-ID: <1446651891.28.0.77869194337.issue25521@psf.upfronthosting.co.za> R. David Murray added the comment: I vote for (4): (2) with a helping of (3). That is, add the warning, but don't try to port all the stdlib modules to argparse beforehand. Those should be addressed one by one, as I mentioned in another issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 4 10:54:55 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 04 Nov 2015 15:54:55 +0000 Subject: [issue25550] RecursionError in re with '(' * 500 In-Reply-To: <1446627776.2.0.048563717292.issue25550@psf.upfronthosting.co.za> Message-ID: <1446652495.92.0.0678488602676.issue25550@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: re.compile can also raise ValueError and OverflowError. Agree that may be these exceptions can be converted to re.error. But it can also raise MemoryError, and KeyboardInterrupt. And these exceptions can't be converted to re.error. RecursionError is closer to the latter case. It depends not only on the pattern itself, but on the place where it is called. A pattern that is compiled successfully at top level can produce a RecursionError if it is compiled deeply in the recursion. >>> import re >>> def r(n): ... if not n: ... return re.compile('x') ... return r(n-1) ... >>> r(990) Traceback (most recent call last): File "", line 1, in File "", line 4, in r File "", line 4, in r ... File "", line 4, in r File "", line 3, in r File "/home/serhiy/py/cpython/Lib/re.py", line 224, in compile return _compile(pattern, flags) File "/home/serhiy/py/cpython/Lib/re.py", line 293, in _compile p = sre_compile.compile(pattern, flags) File "/home/serhiy/py/cpython/Lib/sre_compile.py", line 555, in compile p = sre_parse.parse(p, flags) File "/home/serhiy/py/cpython/Lib/sre_parse.py", line 822, in parse source = Tokenizer(str) File "/home/serhiy/py/cpython/Lib/sre_parse.py", line 225, in __init__ self.__next() RecursionError: maximum recursion depth exceeded >>> re.compile('x') re.compile('x') ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 4 11:06:46 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 04 Nov 2015 16:06:46 +0000 Subject: [issue25521] optparse module does not emit DeprecationWarning In-Reply-To: <1446247354.16.0.386152814173.issue25521@psf.upfronthosting.co.za> Message-ID: <1446653206.61.0.0261834676401.issue25521@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I vote for gradual porting stdlib modules and scripts to argparse and fixing found problems, but doesn't touch optparse right now. We have enough time before 3.6 feature freezing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 4 11:18:11 2015 From: report at bugs.python.org (Michael Selik) Date: Wed, 04 Nov 2015 16:18:11 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <1446653891.92.0.516010912625.issue23883@psf.upfronthosting.co.za> Michael Selik added the comment: many things are not present in os.__all__ that should be, including os.getcwd ---------- nosy: +selik _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 4 11:21:04 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 04 Nov 2015 16:21:04 +0000 Subject: [issue25521] optparse module does not emit DeprecationWarning In-Reply-To: <1446247354.16.0.386152814173.issue25521@psf.upfronthosting.co.za> Message-ID: <1446654064.8.0.458669708183.issue25521@psf.upfronthosting.co.za> St?phane Wirtel added the comment: +1 with @serhiy.storchaka ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 4 11:48:09 2015 From: report at bugs.python.org (Eric Snow) Date: Wed, 04 Nov 2015 16:48:09 +0000 Subject: [issue24726] OrderedDict has strange behaviour when dict.__setitem__ is used. In-Reply-To: <1437906052.21.0.35165181866.issue24726@psf.upfronthosting.co.za> Message-ID: <1446655689.69.0.827832313662.issue24726@psf.upfronthosting.co.za> Eric Snow added the comment: Review posted. Aside from a couple minor comments, LGTM. Thanks for doing this. Incidentally, it should be possible to auto-detect independent changes to the underlying dict and sync the odict with those changes. However, doing so likely isn't worth it. ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 4 11:54:16 2015 From: report at bugs.python.org (paul j3) Date: Wed, 04 Nov 2015 16:54:16 +0000 Subject: [issue25061] Add native enum support for argparse In-Reply-To: <1441908245.42.0.23532628335.issue25061@psf.upfronthosting.co.za> Message-ID: <1446656056.09.0.638655481151.issue25061@psf.upfronthosting.co.za> paul j3 added the comment: The choice of 'type' for this parameter is occasionally confusing, because the connection to the Python 'type()' function or what we think of as 'native types' is only tangential. A name like 'converter' or 'string_converter' would be more accurate (but I'm not advocating any change). There are lots of 'native' types (isn't everything 'first class' in Python?) that are not supported by 'argparse', simply because Python does not have functions that convert from string to that type. For example: bool, list, tuple, dict, set Technically `type=list` works, if you want `list('[1]') =>['[','i',']']`. `type=json` is probably a better choice. `type=int` works because there is a Python function, int(), that takes a string and returns an object of the same type name. 'argparse' does not do anything special to support it. FileType is a nice example of how a factory class can be used as 'type' parameter, but shouldn't be confused with support for the 'file' 'native type'. There's an on going tension between adding useful features and maintaining some level of simplicity and clarity in this module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 4 12:41:28 2015 From: report at bugs.python.org (Christian Tanzer) Date: Wed, 04 Nov 2015 17:41:28 +0000 Subject: [issue25545] email parsing docs need to be clear that only ASCII strings are supported In-Reply-To: Your message of "Wed, 04 Nov 2015 15:36:27 +0000" <1446651387.54.0.809862214631.issue25545@psf.upfronthosting.co.za> Message-ID: Christian Tanzer added the comment: R. David Murray wrote at Wed, 04 Nov 2015 15:36:27 +0000: > There is no problem with supporting both 2.7 and python3 with the same > email API as long as your input strings are ASCII only, which is what > is required by the email RFCs (as I said, they do not support > unicode...even the new one only supports utf8 (a unicode encoding) not > unicode itself). You are talking about byte strings. And of course the email RFCs only talk about byte strings. But the email package offers the use of unicode strings for various functions, including `email.message_from_string`, `email.Message.as_string`, and `email.Message.__str__`. These functions could be useful (and were useful in Python 2) but aren't in Python 3. Assume I load an email satisfying all relevant RFCs from a file. Say that email contains three MIMEText parts with content-transfer-encoding "8bit", all with different encodings: * I don't see any use for `as_string` to obfuscate that by re-encoding each of the three to content-transfer-encoding "base64", which is completely unreadable when it could be converted painlessly to a real unicode string. One of my usage scenarios is something of the form:: >>> print(msg) Of course, in this case I'll better use `utf-8` as my output encoding otherwise the print might fail. If I wanted to output a RFC-compliant byte string, I should have used `as_bytes`, not `as_string`. But that would be a different usage scenario. * The same argument applies in reverse to `message_from_string`. If one wants RFC compliance one should use `message_from_bytes`. But if one builds up a unicode string for an email in Python, it should be possible to convert that to a `email.Message` instance via `message_from_string`. I have several use cases where I want to convert an `email.Message` to a unicode string without any embedded content-transfer-encodings like "base64", do some transformations on that string and then convert that back into an `email.Message` instance. > I have an extensive doc rewrite in process, but I'm not sure when it > will land. I thought I had already added the note about ASCII-only to > the parser docs, but I see that I did not. I'll reopen this issue to > remind myself to do that, since the doc rewrite will only apply to 3.6 > (when the new API will no longer be provisional). I don't see any point in the semantics of the string-functions as they are currently implemented, after all one can do things like easily `message_from_string(...).decode("latin-1")` or `msg.as_bytes().encode("latin-1")` if one really wants to convert an RFC-compatible byte-string to/from unicode strings as-is. But this as-is conversion normally isn't very useful because it isn't * human-readable * well suited to search and replace operations or any other text transformations So documenting the current situation would improve the situation slightly but it's more like putting lipstick on a pig. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 4 13:29:00 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 04 Nov 2015 18:29:00 +0000 Subject: [issue25545] email parsing docs need to be clear that only ASCII strings are supported In-Reply-To: <1446561810.16.0.921085816129.issue25545@psf.upfronthosting.co.za> Message-ID: <1446661740.5.0.2692128738.issue25545@psf.upfronthosting.co.za> R. David Murray added the comment: Yes, the port from python2 to python3 of the email package was...suboptimal. (I wasn't a contributor when that happened, and the person who did it simply did not have time to do the needed rewrite...he had to settle for just making it more-or-less work.) The whole concept of using unicode as a 7bit data channel only is just...weird. But, we are now stuck with maintaining that API for backward compatibility reasons. To fix it, I rewrote significant parts of the email package, which is the new API. And even with that the internals are more than a bit hackish and I'd love to make further changes. I probably won't have time, though, since what we have now works and I'm not (currently) getting paid to work on it. It also is...fraught with the danger of bugs...to talk about serializing an email message as a string, transforming it, and then trying to re-parse it as an email message. If your transformations are simple, it will probably work, but anything at all complex runs the risk of breaking the message. And having non-ascii bodies counts as non-trivial. The whole point of the Message model is to allow you to transform an email message and be able to produce an RFC valid serialization as the output after you are done. You do have to conditionalize your 2/3 code to use the bytes parser and generator if you are dealing with 8-bit messages. There's just no way around that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 4 15:34:10 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 04 Nov 2015 20:34:10 +0000 Subject: [issue25449] Test OrderedDict subclass In-Reply-To: <1445375538.53.0.781433530973.issue25449@psf.upfronthosting.co.za> Message-ID: <20151104203402.57627.99410@psf.io> Roundup Robot added the comment: New changeset 499398d91b97 by Serhiy Storchaka in branch '3.5': Issue #25449: Iterating OrderedDict with keys with unstable hash now raises https://hg.python.org/cpython/rev/499398d91b97 New changeset 9db4191723eb by Serhiy Storchaka in branch 'default': Issue #25449: Iterating OrderedDict with keys with unstable hash now raises https://hg.python.org/cpython/rev/9db4191723eb New changeset 59c7615ea921 by Serhiy Storchaka in branch '3.5': Issue #25449: Fixed a crash and leaking NULL in repr() of OrderedDict that https://hg.python.org/cpython/rev/59c7615ea921 New changeset 76e848554b5d by Serhiy Storchaka in branch 'default': Issue #25449: Fixed a crash and leaking NULL in repr() of OrderedDict that https://hg.python.org/cpython/rev/76e848554b5d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 4 15:39:05 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 04 Nov 2015 20:39:05 +0000 Subject: [issue24726] OrderedDict has strange behaviour when dict.__setitem__ is used. In-Reply-To: <1437906052.21.0.35165181866.issue24726@psf.upfronthosting.co.za> Message-ID: <20151104203902.9004.37038@psf.io> Roundup Robot added the comment: New changeset 88d97cd99d16 by Serhiy Storchaka in branch '3.5': Issue #24726: Fixed issue number for previous changeset 59c7615ea921. https://hg.python.org/cpython/rev/88d97cd99d16 New changeset 965109e81ffa by Serhiy Storchaka in branch 'default': Issue #24726: Fixed issue number for previous changeset 76e848554b5d. https://hg.python.org/cpython/rev/965109e81ffa ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 4 15:40:14 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 04 Nov 2015 20:40:14 +0000 Subject: [issue25449] Test OrderedDict subclass In-Reply-To: <1445375538.53.0.781433530973.issue25449@psf.upfronthosting.co.za> Message-ID: <1446669614.4.0.560786985189.issue25449@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: 59c7615ea921 and 76e848554b5d were related to issue24726. ---------- assignee: -> serhiy.storchaka resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 4 16:09:06 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 04 Nov 2015 21:09:06 +0000 Subject: [issue24726] OrderedDict has strange behaviour when dict.__setitem__ is used. In-Reply-To: <1437906052.21.0.35165181866.issue24726@psf.upfronthosting.co.za> Message-ID: <1446671346.75.0.342338986758.issue24726@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thanks for your review Eric. test_delitem_2 was not added because it fails in just added TestCase for COrderedDict subclass. Added tests for direct calls of other dict methods as Eric suggested. During writing new tests for direct calls of other dict methods I found yet one bug. Following code makes Python to hang and eat memory. from collections import OrderedDict od = OrderedDict() for i in range(10): od[str(i)] = i for i in range(9): dict.__delitem__(od, str(i)) list(od) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 4 16:19:33 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 04 Nov 2015 21:19:33 +0000 Subject: [issue25410] Clean up and fix OrderedDict In-Reply-To: <1444896308.75.0.718152743923.issue25410@psf.upfronthosting.co.za> Message-ID: <1446671973.6.0.327811573259.issue25410@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could you please make a review of last three patches Eric? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 4 17:23:28 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 04 Nov 2015 22:23:28 +0000 Subject: [issue24934] django_v2 benchmark not working in Python 3.6 In-Reply-To: <1440508179.01.0.645988058251.issue24934@psf.upfronthosting.co.za> Message-ID: <1446675808.45.0.845114786765.issue24934@psf.upfronthosting.co.za> R. David Murray added the comment: An additional argument for waiting is issue 25486. ---------- type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 4 17:45:50 2015 From: report at bugs.python.org (Nir Soffer) Date: Wed, 04 Nov 2015 22:45:50 +0000 Subject: [issue25551] Event's test_reset_internal_locks too fragile Message-ID: <1446677150.66.0.649715763686.issue25551@psf.upfronthosting.co.za> New submission from Nir Soffer: test_reset_internal_locks is looking at Event's _cond._lock - this make it harder to change internal details of the Condition object and make the test fragile. We should test the condition behavior instead. ---------- components: Tests messages: 254074 nosy: nirs priority: normal severity: normal status: open title: Event's test_reset_internal_locks too fragile type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 4 17:50:54 2015 From: report at bugs.python.org (Nir Soffer) Date: Wed, 04 Nov 2015 22:50:54 +0000 Subject: [issue25551] Event's test_reset_internal_locks too fragile In-Reply-To: <1446677150.66.0.649715763686.issue25551@psf.upfronthosting.co.za> Message-ID: <1446677454.57.0.681035160903.issue25551@psf.upfronthosting.co.za> Changes by Nir Soffer : ---------- keywords: +patch Added file: http://bugs.python.org/file40941/0001-Issue-254074-Test-condition-behavior-instead-of-inte.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 4 18:04:17 2015 From: report at bugs.python.org (Eric Snow) Date: Wed, 04 Nov 2015 23:04:17 +0000 Subject: [issue25410] Clean up and fix OrderedDict In-Reply-To: <1444896308.75.0.718152743923.issue25410@psf.upfronthosting.co.za> Message-ID: <1446678257.37.0.531811193117.issue25410@psf.upfronthosting.co.za> Eric Snow added the comment: I will review those patches soon. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 4 18:34:05 2015 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 04 Nov 2015 23:34:05 +0000 Subject: [issue23571] Raise SystemError if a function returns a result with an exception set In-Reply-To: <1425383921.42.0.283584513916.issue23571@psf.upfronthosting.co.za> Message-ID: <1446680045.99.0.0346079538976.issue23571@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 4 18:37:43 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 04 Nov 2015 23:37:43 +0000 Subject: [issue24802] int and float constructing from non NUL-terminated buffer In-Reply-To: <1438830920.07.0.863152787453.issue24802@psf.upfronthosting.co.za> Message-ID: <1446680263.66.0.199816042854.issue24802@psf.upfronthosting.co.za> Martin Panter added the comment: The patch looks good to me. However I don?t understand what you meant about restoring int(bytes, base) behaviour. None of the patches here, nor in Issue 22896, touch long_new() in /Objects/longobject.c. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 4 19:01:01 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 05 Nov 2015 00:01:01 +0000 Subject: [issue24802] int and float constructing from non NUL-terminated buffer In-Reply-To: <1438830920.07.0.863152787453.issue24802@psf.upfronthosting.co.za> Message-ID: <1446681661.85.0.468887433018.issue24802@psf.upfronthosting.co.za> Martin Panter added the comment: Going through the commits for Issue 22896, I noticed compile(), eval() and exec() also suffer from a similar flaw. They check strlen(buffer) but the buffer may not be null-terminated: >>> eval(memoryview(b"1234")[1:3]) TypeError: source code string cannot contain null bytes ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 4 21:00:20 2015 From: report at bugs.python.org (Anthony C) Date: Thu, 05 Nov 2015 02:00:20 +0000 Subject: [issue25552] python turtle page does not run Message-ID: <1446688819.99.0.0895353718927.issue25552@psf.upfronthosting.co.za> New submission from Anthony C: Making this simple code to mess with turtle well it seems like after awhile I have encountered the window = turtle.Screen() doesnt seem to even open it up only the shell window and does nothing afterwards. Its quite annoying especially trying to practice with it and it doesnt work. import turtle def draw_square(some_turtle) : for i in range(1,5) : some_turtle.forward(100) some_turtle.right(90) def draw_art() : window = turtle.Screen() window.bgcolor("red") brad = turtle.Turtle() brad.shape("turtle") brad.color("blue") brad.speed(2) for i in range (1,4) : draw_square(brad) brad.right(10) window.exitonclick() ---------- files: movies.py messages: 254078 nosy: Anthony C priority: normal severity: normal status: open title: python turtle page does not run type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file40942/movies.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 4 22:48:07 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 05 Nov 2015 03:48:07 +0000 Subject: [issue24802] int and float constructing from non NUL-terminated buffer In-Reply-To: <1438830920.07.0.863152787453.issue24802@psf.upfronthosting.co.za> Message-ID: <1446695287.33.0.827941253982.issue24802@psf.upfronthosting.co.za> Martin Panter added the comment: This patch builds on Serhiy?s, and also fixes compile(), eval() and exec(). Also, I took the liberty of converting your assertRaises() calls to assertRaisesRegex() with context managers. I find this is a good general practice, to avoid hiding an accidental exception. ---------- Added file: http://bugs.python.org/file40943/unterminated-buffer.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 4 22:53:37 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 05 Nov 2015 03:53:37 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <1446695617.44.0.0728260106828.issue23883@psf.upfronthosting.co.za> Martin Panter added the comment: Michael: According to Issue 18554, os.__all__ was fixed in 3.5. Can you confirm? It is working for me: Python 3.5.0 (default, Sep 20 2015, 11:28:25) [GCC 5.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> "getcwd" in os.__all__ True ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 4 22:59:18 2015 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 05 Nov 2015 03:59:18 +0000 Subject: [issue25534] SimpleHTTPServer throwed an exception due to negtive st_mtime attr in file In-Reply-To: <1446478517.38.0.562445062137.issue25534@psf.upfronthosting.co.za> Message-ID: <1446695958.34.0.851039709868.issue25534@psf.upfronthosting.co.za> Xiang Zhang added the comment: I'm afraid we can't say negative epoch is handled successfully on Linux. Use $ touch -d "1 Jan 1900" test as a test, time.gmtime(os.fstat(f.fileno()).st_mtime) gives time.struct_time(tm_year=1899, tm_mon=12, tm_mday=31, tm_hour=15, tm_min=54, tm_sec=17, tm_wday=6, tm_yday=365, tm_isdst=0), which does not equals "1 Jan 1900". I think this is caused by python gmtime directly uses gmtime in C. Use the epoch of "1 Jan 1900" with C's gmtime does not give a right result. And while I am searching, I can not find any evidence that gmtime in C can give a right result with a negtive epoch. And when I try the epoch of "1 Jan 1900" with "date -d @", it can generate the right result. ---------- nosy: +xiang.zhang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 4 23:15:11 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 05 Nov 2015 04:15:11 +0000 Subject: [issue25534] SimpleHTTPServer throwed an exception due to negtive st_mtime attr in file In-Reply-To: <1446478517.38.0.562445062137.issue25534@psf.upfronthosting.co.za> Message-ID: <1446696911.5.0.739711236819.issue25534@psf.upfronthosting.co.za> Martin Panter added the comment: Perhaps you have a timezone set (I don?t). This might work better: touch -d "1 Jan 1900 UTC" test My thinking is if os.stat() returns a negative timestamp from the OS (GNU C library in the case of Linux), it may be worth trying gmtime() on that value since it also calls the OS (glibc) function. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 4 23:44:05 2015 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 05 Nov 2015 04:44:05 +0000 Subject: [issue25534] SimpleHTTPServer throwed an exception due to negtive st_mtime attr in file In-Reply-To: <1446478517.38.0.562445062137.issue25534@psf.upfronthosting.co.za> Message-ID: <1446698645.46.0.782183614803.issue25534@psf.upfronthosting.co.za> Xiang Zhang added the comment: You're right. Actually I do think of timezone when I do the experiment. But I think different timezone will only affect the hour. It turns out I should learn more about time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 01:15:13 2015 From: report at bugs.python.org (Michael Selik) Date: Thu, 05 Nov 2015 06:15:13 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <1446704113.2.0.00190657571083.issue23883@psf.upfronthosting.co.za> Michael Selik added the comment: @Martin, my mistake. You're correct. I forgot I was using Python v3.4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 01:50:43 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 05 Nov 2015 06:50:43 +0000 Subject: [issue5550] [urllib.request]: Comparison of HTTP headers should be insensitive to the case In-Reply-To: <1237870141.83.0.616869799184.issue5550@psf.upfronthosting.co.za> Message-ID: <1446706243.04.0.42155577144.issue5550@psf.upfronthosting.co.za> Martin Panter added the comment: The patch here does the same thing as John?s issue2775.patch in Issue 2275. I am closing this thread, because I think John?s patch in the other one is superior (except for being way out of date). ---------- resolution: -> duplicate status: open -> closed superseder: -> Implement PEP 3108 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 01:51:52 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 05 Nov 2015 06:51:52 +0000 Subject: [issue5550] [urllib.request]: Comparison of HTTP headers should be insensitive to the case In-Reply-To: <1237870141.83.0.616869799184.issue5550@psf.upfronthosting.co.za> Message-ID: <1446706312.4.0.530396033243.issue5550@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- superseder: Implement PEP 3108 -> urllib/httplib header capitalization _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 01:51:55 2015 From: report at bugs.python.org (Deli Zhang) Date: Thu, 05 Nov 2015 06:51:55 +0000 Subject: [issue25553] SMTP.data(msg) function may cause the last CRLF of msg lost if msg is quoted-printable encoding. Message-ID: <1446706315.09.0.659513655808.issue25553@psf.upfronthosting.co.za> New submission from Deli Zhang: It's well known that in quoted-printable encoding the "CRLF" can be encoded to "=CRLF". For example, in attachment file test.eml, the last line is "test message.=CRLF" But after the mail is sent via SMTP and received by mail server (e.g. postfix), the last line will become "test message.=", then after decoding, you will see the unnecessary char "=" shown following "test message.". The problem is caused by below code: ------------------------------------------------ class SMTP: ... def data(self, msg): ... q = quotedata(msg) if q[-2:] != CRLF: q = q + CRLF q = q + "." + CRLF self.send(q) ... ------------------------------------------------ Before it sends the message q, it will try to append the end-of-data sequence ".". As the implement, it checks whether there is "" in the message end, if yes then just need to append ".". It looks rigorous and efficient, but it does not consider how mail server handle it. As we know mail server will remove end-of-data sequence directly, and the left message is treat as mail data. Thus the corresponding action should be taken on SMTP client side, it's to say no need to check and just append end-of-data sequence here: ------------------------------------------------ class SMTP: ... def data(self, msg): ... q = quotedata(msg) q = q + CRLF + "." + CRLF self.send(q) ... ------------------------------------------------ ---------- components: Library (Lib) files: test.eml messages: 254086 nosy: Deli Zhang priority: normal severity: normal status: open title: SMTP.data(msg) function may cause the last CRLF of msg lost if msg is quoted-printable encoding. type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file40944/test.eml _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 02:05:08 2015 From: report at bugs.python.org (Deli Zhang) Date: Thu, 05 Nov 2015 07:05:08 +0000 Subject: [issue25553] SMTP.data(msg) function may cause the last CRLF of msg lost if msg is quoted-printable encoding. In-Reply-To: <1446706315.09.0.659513655808.issue25553@psf.upfronthosting.co.za> Message-ID: <1446707108.13.0.320768432587.issue25553@psf.upfronthosting.co.za> Deli Zhang added the comment: Correct the action of appending the end-of-data sequence "." ---------- Added file: http://bugs.python.org/file40945/smtplib.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 02:13:24 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 05 Nov 2015 07:13:24 +0000 Subject: [issue2275] Make urllib.request.Request.has_header() etc case-insensitive In-Reply-To: <1205270540.47.0.336665756101.issue2275@psf.upfronthosting.co.za> Message-ID: <1446707604.49.0.370744340794.issue2275@psf.upfronthosting.co.za> Martin Panter added the comment: Rui: See Issue 12455 about changing the letter case of field names sent to the server. Unless someone wants to write a patch to fix all the bugs at once, I suggest to keep this thread focussed on Request.has_header() etc. I closed Issue 5550 as a duplicate of this one. There is a patch there from 2014 which does the same sort of thing as John?s issue2775.patch from 2008, but IMO John?s patch would be more efficient. It needs updating for Python 3.6 though. The remove_header() method (added in 3.4) should also be adjusted to be case-insensitive. It may also be worth clarifying in the header_items() documentation that the keys have been converted as if by str.capitalize(). FTR: John?s issue2775.patch seems to be Patch Set 1 in the code review, despite being third in the list above. ---------- nosy: +martin.panter stage: patch review -> needs patch title: urllib/httplib header capitalization -> Make urllib.request.Request.has_header() etc case-insensitive type: behavior -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 02:22:01 2015 From: report at bugs.python.org (William Orr) Date: Thu, 05 Nov 2015 07:22:01 +0000 Subject: [issue12978] Figure out extended attributes on BSDs In-Reply-To: <1316014526.21.0.982877507813.issue12978@psf.upfronthosting.co.za> Message-ID: <1446708121.96.0.52518506842.issue12978@psf.upfronthosting.co.za> William Orr added the comment: After a considerable amount of rework, I've gotten something worth submitting. All unit tests pass, and it handles some of the more unfortunate differences between FreeBSD's extended attribute syscalls and Linux's. One of the bigger changes is that I reworked the calls to getxattr and listxattr. These used to be called with a small buffer, and if the size of the extended attribute(s) exceeded the buffer length, we'd throw out that buffer and start again with a buffer of the maximum possible attribute size allocated. I threw this out, and opted for always making two calls - one to get the size of the buffer, and one to actually get the contents (or list of attributes). This works the same for both FreeBSD and Linux. FreeBSD's extattr_get_* and extattr_list_* unfortunately only return the number of bytes read, *not* the number of bytes in the attribute value or the list. That means that there's no real way to determine if we've read less data than there is in the attribute. This passes the unit tests (on FreeBSD 10.1). I'd be interested to see results from other users and comments. ---------- Added file: http://bugs.python.org/file40946/extattrs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 02:23:16 2015 From: report at bugs.python.org (Marius Gedminas) Date: Thu, 05 Nov 2015 07:23:16 +0000 Subject: [issue12612] Valgrind suppressions In-Reply-To: <1311352571.88.0.0623185894462.issue12612@psf.upfronthosting.co.za> Message-ID: <1446708196.92.0.135280064536.issue12612@psf.upfronthosting.co.za> Marius Gedminas added the comment: Could this fix be backported to the 2.7 branch as well? ---------- nosy: +mgedmin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 03:08:54 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 05 Nov 2015 08:08:54 +0000 Subject: [issue892902] problem with pickling newstyle class instances Message-ID: <1446710934.74.0.236023639311.issue892902@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Updated patch addresses Alexandre's comments. ---------- Added file: http://bugs.python.org/file40947/pickle_recursive-2.7_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 03:27:44 2015 From: report at bugs.python.org (Jeroen van der Heijden) Date: Thu, 05 Nov 2015 08:27:44 +0000 Subject: [issue25554] memory leak (reference cycles) using re Message-ID: <1446712064.78.0.0396170354874.issue25554@psf.upfronthosting.co.za> New submission from Jeroen van der Heijden: When compiling a regular expression with groups (subpatterns), circular references are created. Here is an example to illustrate the problem: >>> import gc >>> import re >>> gc.disable() # disable garbage collector >>> gc.collect() # make sure we start with 0 0 >>> re.compile('(a|b)') # compile something with groups re.compile('(a|b)') >>> gc.collect() # collects x objects depending on the compiled string 11 To fix the issue a weakref object for p is used. ---------- components: Library (Lib) files: fix_mem_sre_parse.patch keywords: patch messages: 254092 nosy: joente priority: normal severity: normal status: open title: memory leak (reference cycles) using re type: resource usage versions: Python 3.5 Added file: http://bugs.python.org/file40948/fix_mem_sre_parse.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 04:42:04 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 05 Nov 2015 09:42:04 +0000 Subject: [issue25555] Fix parser and AST: fill lineno and col_offset when compiling AST from Python objects Message-ID: <1446716524.88.0.975797398415.issue25555@psf.upfronthosting.co.za> New submission from STINNER Victor: I wrote an AST optimizer which build AST from source code using ast.parse(), modify AST in place, and then compile the AST to bytecode. The problem is that the lineno and col_offset attributes of the "arg" AST node are uninitialized when AST is rebuild from Python objects: compile(ast_tree, ...). As a consequence, the compilation may fail because lineno or col_offset values are invalid. Attached patch enhances Parser/asdl_c.py to take "arg" attributes in account. It also updates the generated files Include/Python-ast.h and Python/Python-ast.c, and fix usage of the arg() function in Python/ast.c. It looks like only the "arg" AST node had attributes which were initialized (other AST nodes are handled with a different code path which already filled attributes). See Parser/Python.asdl for the definition of the "arg" AST node. Note: Python 2.7 is not affected. In Python 2, function arguments are simple expressions, they don't have a dedicated type with lineno and col_offset attributes. "arg" was introduced in Python 3 with the PEP 3107 (function annotations). ---------- files: ast.patch keywords: patch messages: 254093 nosy: benjamin.peterson, haypo, matrixise, yselivanov priority: normal severity: normal status: open title: Fix parser and AST: fill lineno and col_offset when compiling AST from Python objects versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file40949/ast.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 04:52:03 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 05 Nov 2015 09:52:03 +0000 Subject: [issue25556] Fixes for PyObject_GetItem() Message-ID: <1446717123.25.0.590354154492.issue25556@psf.upfronthosting.co.za> New submission from STINNER Victor: Attached patch adds assertions to PyObject_GetItem() to ensure that an exception is raised if the function failed. _Py_CheckFunctionResult() could be used to implement such check, but it might adds a little overhead, whereas I really don't think that such bug occurs in the wild. The assertion only helps when you develop a new custom type implementing the mapping API. The patch also simplifies Python/ceval.c: it now considers that an exception is raised if PyObject_GetItem() returns NULL. Finally, the patch also fixes a bug in the LOAD_NAME bytecode, when globals are not a dict but a custom type and the name doesn't exist in globals: clear the exception before calling PyObject_GetItem() on builtins. ---------- components: Interpreter Core messages: 254094 nosy: haypo, serhiy.storchaka priority: normal severity: normal status: open title: Fixes for PyObject_GetItem() versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 04:58:20 2015 From: report at bugs.python.org (Christian Tanzer) Date: Thu, 05 Nov 2015 09:58:20 +0000 Subject: [issue25545] email parsing docs need to be clear that only ASCII strings are supported In-Reply-To: Your message of "Wed, 04 Nov 2015 18:29:00 +0000" <1446661740.5.0.2692128738.issue25545@psf.upfronthosting.co.za> Message-ID: Christian Tanzer added the comment: > Yes, the port from python2 to python3 of the email package > was...suboptimal. > ... > The whole concept of using unicode as a 7bit data channel only is > just...weird. +100 to both. > But, we are now stuck with maintaining that API for backward > compatibility reasons. That's a weird definition of backward compatibility, though. The API breaks backward compatibility to Python 2. Any Python 3 user shouldn't use the broken API anyway, IMHO. > To fix it, I rewrote significant parts of the email package, which > is the new API. Which unfortunately isn't any help if one needs to stay compatible to 2.7. > It also is...fraught with the danger of bugs...to talk about > serializing an email message as a string, transforming it, and then > trying to re-parse it as an email message. If your transformations > are simple, it will probably work, but anything at all complex runs > the risk of breaking the message. One of Python's mottos used to be: We are all consenting adults here. But there are other uses for converting a message instance to a unicode string. Display, printing, and grepping come to mind. > And having non-ascii bodies counts as non-trivial. For anybody living in a non-ascii country that statement sounds **very strange**. To start with, I have many friends with names that contain non-ascii characters. > You do have to conditionalize your 2/3 code to use the bytes parser > and generator if you are dealing with 8-bit messages. There's just no > way around that. I did that yesterday. There are problems with that though: * Recognizing the problem for what it is. Trying to run Python 2.7 code that *should* run under 3.5 but breaks with weird errors wastes a lot of time. Multiply with the number of Python programmers that want to migrate and you get a problem. If `message_as_string` and `as_string` just weren't there in 3.x it would be much less of a problem (clear documentation would also help but not as much). * Lots of ugly workarounds for the same problem. Most of them (mine certainly included) are done quick and ad-hoc and probably break in many ways. The question then arises: why should one use the email package at all. But of course that way lies madness. Just more roadblocks for the move to Python 3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 04:59:54 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 05 Nov 2015 09:59:54 +0000 Subject: [issue25556] Fixes for PyObject_GetItem() In-Reply-To: <1446717123.25.0.590354154492.issue25556@psf.upfronthosting.co.za> Message-ID: <1446717593.98.0.849091161226.issue25556@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Where is a patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 05:11:19 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 05 Nov 2015 10:11:19 +0000 Subject: [issue25557] Optimize LOAD_NAME bytecode Message-ID: <1446718279.47.0.148828829851.issue25557@psf.upfronthosting.co.za> New submission from STINNER Victor: The LOAD_GLOBAL bytecode has a fast-path when globals and builtins have exactly the type 'dict'. It calls the _PyDict_LoadGlobal() function. I propose to implement a similar optimization for LOAD_NAME, see attached patch. The patch also fixes LOAD_GLOBAL and LOAD_NAME bytecodes when locals, globals or builtins are not exactly the type 'dict'. It clears the KeyError before trying the next PyObject_GetItem(). The patch changes also _PyDict_LoadGlobal() to call PyObject_Hash() if the hash was not computed yet. It might make it a little bit faster. ---------- components: Interpreter Core files: pydict_loadname.patch keywords: patch messages: 254097 nosy: haypo, serhiy.storchaka priority: normal severity: normal status: open title: Optimize LOAD_NAME bytecode type: performance versions: Python 3.6 Added file: http://bugs.python.org/file40950/pydict_loadname.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 05:11:57 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 05 Nov 2015 10:11:57 +0000 Subject: [issue25556] Fixes for PyObject_GetItem() In-Reply-To: <1446717123.25.0.590354154492.issue25556@psf.upfronthosting.co.za> Message-ID: <1446718317.21.0.983088128465.issue25556@psf.upfronthosting.co.za> STINNER Victor added the comment: Oops, sorry. It's now attached to the issue :-) ---------- keywords: +patch Added file: http://bugs.python.org/file40951/pyobject_getitem.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 05:16:13 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 05 Nov 2015 10:16:13 +0000 Subject: [issue25556] Fixes for PyObject_GetItem() In-Reply-To: <1446717123.25.0.590354154492.issue25556@psf.upfronthosting.co.za> Message-ID: <1446718573.02.0.0983147376611.issue25556@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 05:16:35 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 05 Nov 2015 10:16:35 +0000 Subject: [issue25557] Optimize LOAD_NAME bytecode In-Reply-To: <1446718279.47.0.148828829851.issue25557@psf.upfronthosting.co.za> Message-ID: <1446718595.0.0.21607515183.issue25557@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 05:31:24 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 05 Nov 2015 10:31:24 +0000 Subject: [issue25554] memory leak (reference cycles) using re In-Reply-To: <1446712064.78.0.0396170354874.issue25554@psf.upfronthosting.co.za> Message-ID: <1446719484.97.0.0543862962304.issue25554@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your report and patch Jeroen. Indeed, there is a regression, and your patch fixes it. But I don't like the idea of using weakref. For now sre_parse has very little dependencies, but weakref depends on collections that depends on a number of modules. For now importing weakref works, but it is too easy to create a dependency loop in future. Here is alternative patch that gets rid of references at all. The subpatterns list was added in the patch for issue9179 and is an implementation detail. We can replace it with a list of subpattern widths. ---------- assignee: -> serhiy.storchaka components: +Regular Expressions nosy: +ezio.melotti, mrabarnett, serhiy.storchaka stage: -> patch review versions: +Python 2.7, Python 3.4, Python 3.6 Added file: http://bugs.python.org/file40952/fix_mem_sre_parse_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 06:02:56 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 05 Nov 2015 11:02:56 +0000 Subject: [issue25495] binascii documentation incorrect In-Reply-To: <1445987417.55.0.122139453671.issue25495@psf.upfronthosting.co.za> Message-ID: <1446721376.13.0.522908936106.issue25495@psf.upfronthosting.co.za> Martin Panter added the comment: Perhaps we can focus on the Python 2 version where there is always a newline appended. Here is a possible patch. ---------- Added file: http://bugs.python.org/file40953/issue25495.base64.2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 06:26:13 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 05 Nov 2015 11:26:13 +0000 Subject: [issue25557] Optimize LOAD_NAME bytecode In-Reply-To: <1446718279.47.0.148828829851.issue25557@psf.upfronthosting.co.za> Message-ID: <1446722773.52.0.41204282618.issue25557@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: When LOAD_NAME is generated? Is it worth to optimize this case? Aren't LOAD_FAST and LOAD_GLOBAL used in performance critical code? It looks to me that there is a bug in fast path of _PyDict_LoadGlobal. If the first lookup fails, it can raise an exception. We have to add if (PyErr_Occurred()) return NULL; before the second lookup. Just for reference, the fast path for LOAD_GLOBAL was added in 8f8fe990e82c. ---------- nosy: +benjamin.peterson, rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 06:49:17 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 05 Nov 2015 11:49:17 +0000 Subject: [issue25557] Optimize LOAD_NAME bytecode In-Reply-To: <1446718279.47.0.148828829851.issue25557@psf.upfronthosting.co.za> Message-ID: <1446724157.6.0.97424935894.issue25557@psf.upfronthosting.co.za> STINNER Victor added the comment: > When LOAD_NAME is generated? Is it worth to optimize this case? Aren't LOAD_FAST and LOAD_GLOBAL used in performance critical code? I guess that it's only used to execute the body of modules. > Is it worth to optimize this case? Hum, I don't know :-) > It looks to me that there is a bug in fast path of _PyDict_LoadGlobal. If the first lookup fails, it can raise an exception. Sorry, where exactly? Can you maybe put a comment on the review? I see many checks to handle errors. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 06:56:21 2015 From: report at bugs.python.org (gul916) Date: Thu, 05 Nov 2015 11:56:21 +0000 Subject: [issue25150] 3.5: Include/pyatomic.h is incompatible with OpenMP (compilation of the third-party yt module fails on Python 3.5) In-Reply-To: <1442494739.31.0.584117765088.issue25150@psf.upfronthosting.co.za> Message-ID: <1446724581.37.0.636771566557.issue25150@psf.upfronthosting.co.za> gul916 added the comment: Hi, Just a few words to tell you that I had the same problem to compile scipy 0.16.0 with mkl libraries under python 3.5 and linux fedora 22. Pyatomic-2.patch solved the problem. Thanks ---------- nosy: +gul916 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 07:01:19 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 05 Nov 2015 12:01:19 +0000 Subject: [issue25150] 3.5: Include/pyatomic.h is incompatible with OpenMP (compilation of the third-party yt module fails on Python 3.5) In-Reply-To: <1442494739.31.0.584117765088.issue25150@psf.upfronthosting.co.za> Message-ID: <1446724879.89.0.331756459147.issue25150@psf.upfronthosting.co.za> STINNER Victor added the comment: "Pyatomic-2.patch solved the problem." Great! The good news is that the Python 3.5.1 release has now a schedule: https://www.python.org/dev/peps/pep-0478/ "3.5.1 final: December 6, 2015" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 07:50:17 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 05 Nov 2015 12:50:17 +0000 Subject: [issue25556] Fixes for PyObject_GetItem() In-Reply-To: <1446717123.25.0.590354154492.issue25556@psf.upfronthosting.co.za> Message-ID: <1446727817.4.0.609255842509.issue25556@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. The fix for LOAD_GLOBAL should be applied for all versions. ---------- assignee: -> haypo stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 08:02:24 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 05 Nov 2015 13:02:24 +0000 Subject: [issue25556] Fixes for PyObject_GetItem() In-Reply-To: <1446717123.25.0.590354154492.issue25556@psf.upfronthosting.co.za> Message-ID: <20151105130216.57611.86030@psf.io> Roundup Robot added the comment: New changeset 1e87bcf20707 by Victor Stinner in branch '3.5': Issue #25556: Fix LOAD_GLOBAL bytecode when globals type is not dict and the https://hg.python.org/cpython/rev/1e87bcf20707 New changeset c1414f80ebc9 by Victor Stinner in branch 'default': Issue #25556: Add assertions to PyObject_GetItem() to ensure that an exception https://hg.python.org/cpython/rev/c1414f80ebc9 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 08:02:26 2015 From: report at bugs.python.org (Alex Champandard) Date: Thu, 05 Nov 2015 13:02:26 +0000 Subject: =?utf-8?q?=5Bissue24875=5D_pyvenv_doesn=C2=B4t_install_PIP_inside_a_new_v?= =?utf-8?q?env_with_--system-site-package?= In-Reply-To: <1439699040.07.0.199956094974.issue24875@psf.upfronthosting.co.za> Message-ID: <1446728546.57.0.195314265299.issue24875@psf.upfronthosting.co.za> Alex Champandard added the comment: I agree this makes --system-site-packages a useless option unless it's fixed. We just had many beginners install pyvenv's and get very confused because of this. Passing ensurepip a new option to force it to install within a venv I think would work. What would it take to make progress on this? ---------- nosy: +alexjc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 08:03:08 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 05 Nov 2015 13:03:08 +0000 Subject: [issue25556] Fixes for PyObject_GetItem() In-Reply-To: <1446717123.25.0.590354154492.issue25556@psf.upfronthosting.co.za> Message-ID: <1446728588.15.0.901439407901.issue25556@psf.upfronthosting.co.za> STINNER Victor added the comment: > LGTM. The fix for LOAD_GLOBAL should be applied for all versions. Thanks for the review. I applied the LOAD_GLOBAL fix to Python 3.5 and 3.6. Python 2.7 doesn't support globals not being dict. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 08:04:30 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 05 Nov 2015 13:04:30 +0000 Subject: [issue25556] Fixes for PyObject_GetItem() In-Reply-To: <1446717123.25.0.590354154492.issue25556@psf.upfronthosting.co.za> Message-ID: <1446728670.93.0.256917061806.issue25556@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: -> fixed status: open -> closed versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 08:05:06 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 05 Nov 2015 13:05:06 +0000 Subject: [issue25556] Fixes for PyObject_GetItem() In-Reply-To: <1446717123.25.0.590354154492.issue25556@psf.upfronthosting.co.za> Message-ID: <1446728706.38.0.581017818171.issue25556@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What about 3.4? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 08:06:26 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 05 Nov 2015 13:06:26 +0000 Subject: [issue25556] Fixes for PyObject_GetItem() In-Reply-To: <1446717123.25.0.590354154492.issue25556@psf.upfronthosting.co.za> Message-ID: <1446728786.36.0.222243736624.issue25556@psf.upfronthosting.co.za> STINNER Victor added the comment: > What about 3.4? I consider it as almost dead (no more bugfixes), and this really is really a corner case. Except me, I don't think that anyone uses globals which are not dict :-D (It never worked...) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 08:32:54 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 05 Nov 2015 13:32:54 +0000 Subject: [issue25556] Fixes for PyObject_GetItem() In-Reply-To: <1446717123.25.0.590354154492.issue25556@psf.upfronthosting.co.za> Message-ID: <1446730374.23.0.668674289813.issue25556@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: In issue25557 I mentioned that there is the same error for globals which are dict. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 08:38:01 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 05 Nov 2015 13:38:01 +0000 Subject: [issue25557] Optimize LOAD_NAME bytecode In-Reply-To: <1446718279.47.0.148828829851.issue25557@psf.upfronthosting.co.za> Message-ID: <1446730681.36.0.347297254747.issue25557@psf.upfronthosting.co.za> STINNER Victor added the comment: Rebased patch (ceval.c was modified by the changeset of c1414f80ebc9, issue #25556). ---------- Added file: http://bugs.python.org/file40954/pydict_loadname-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 08:39:39 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 05 Nov 2015 13:39:39 +0000 Subject: [issue25556] Fixes for PyObject_GetItem() In-Reply-To: <1446717123.25.0.590354154492.issue25556@psf.upfronthosting.co.za> Message-ID: <1446730779.66.0.881561714323.issue25556@psf.upfronthosting.co.za> STINNER Victor added the comment: > In issue25557 I mentioned that there is the same error for globals which are dict. This issue fixed a bug for LOAD_GLOBAL bytecode bytecode when globals are not dict. (Sorry, I wrote LOAD_NAME bytecode in my first message, it was a mistake.) Please discuss the issue #25557 in the issue #issue25557. (I already replied there, I don't understand where you spotted a bug.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 10:13:59 2015 From: report at bugs.python.org (Jeroen van der Heijden) Date: Thu, 05 Nov 2015 15:13:59 +0000 Subject: [issue25554] memory leak (reference cycles) using re In-Reply-To: <1446712064.78.0.0396170354874.issue25554@psf.upfronthosting.co.za> Message-ID: <1446736439.67.0.110236822168.issue25554@psf.upfronthosting.co.za> Jeroen van der Heijden added the comment: Thanks Serhiy, I totally agree with your solution. Using a list with subpattern widths is definitely better compared to using weakref. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 10:52:03 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 05 Nov 2015 15:52:03 +0000 Subject: [issue25554] memory leak (reference cycles) using re In-Reply-To: <1446712064.78.0.0396170354874.issue25554@psf.upfronthosting.co.za> Message-ID: <20151105155139.101535.67519@psf.io> Roundup Robot added the comment: New changeset 7f4fca8f13a2 by Serhiy Storchaka in branch '3.5': Issue #25554: Got rid of circular references in regular expression parsing. https://hg.python.org/cpython/rev/7f4fca8f13a2 New changeset 8621727dd9f7 by Serhiy Storchaka in branch 'default': Issue #25554: Got rid of circular references in regular expression parsing. https://hg.python.org/cpython/rev/8621727dd9f7 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 11:41:20 2015 From: report at bugs.python.org (Stefan Krah) Date: Thu, 05 Nov 2015 16:41:20 +0000 Subject: [issue24623] Parser: broken line numbers for triple-quoted strings In-Reply-To: <1436730078.84.0.940151456611.issue24623@psf.upfronthosting.co.za> Message-ID: <1446741680.82.0.281648717193.issue24623@psf.upfronthosting.co.za> Stefan Krah added the comment: Victor, I'm adding you just in case this also affects your optimizer (like #25555). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 11:41:30 2015 From: report at bugs.python.org (Stefan Krah) Date: Thu, 05 Nov 2015 16:41:30 +0000 Subject: [issue24623] Parser: broken line numbers for triple-quoted strings In-Reply-To: <1436730078.84.0.940151456611.issue24623@psf.upfronthosting.co.za> Message-ID: <1446741690.75.0.928343653592.issue24623@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 11:43:26 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 05 Nov 2015 16:43:26 +0000 Subject: [issue25554] memory leak (reference cycles) using re In-Reply-To: <1446712064.78.0.0396170354874.issue25554@psf.upfronthosting.co.za> Message-ID: <1446741806.68.0.392811451853.issue25554@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: -Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 11:46:40 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 05 Nov 2015 16:46:40 +0000 Subject: [issue25558] Use static asserts in C code Message-ID: <1446742000.61.0.314081889142.issue25558@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Proposed patch converts some dynamic assert to static asserts (Py_BUILD_ASSERT_EXPR). This allows to check static invariants at compile time. ---------- components: Extension Modules, Interpreter Core files: use_Py_BUILD_ASSERT_EXPR.patch keywords: patch messages: 254117 nosy: haypo, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Use static asserts in C code type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file40955/use_Py_BUILD_ASSERT_EXPR.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 11:50:59 2015 From: report at bugs.python.org (Mouse) Date: Thu, 05 Nov 2015 16:50:59 +0000 Subject: [issue25495] binascii documentation incorrect In-Reply-To: <1445987417.55.0.122139453671.issue25495@psf.upfronthosting.co.za> Message-ID: <1446742259.04.0.658363749346.issue25495@psf.upfronthosting.co.za> Mouse added the comment: Unfortunately, NO. The problem (and this bug report) is for Python-3 documentation, so trying to address it in Python-2 rather than in Python-3 does not make sense. We seem to both understand and agree that there is no length limitation on b2a_base64() input, either recommended or enforced - contrary to what the current Python-3 documentation implies. We understand that *if* the *output* of this function is intended for use in MIME (rather than X.509 or whatever else Base64 is good for), then the caller should do other things besides calling b2a_base64(), and in all likelihood the caller is already aware of that - after all, if he figured that he needs Base64 in his stuff, he probably knows something about what MIME standards say and require?. I repeat my original complaint: Python-3 documentation is buggy because it implies a restriction on the input that is not there. This reference should be removed from there because it confuses people. I've talked to those confused personally, so this is first-hand. I refer you to the original msg253572 of this bug report. If you want to write a MIME-in-Python tutorial, it is up to you - but b2a_base64() does not seem to be the right place for it. (And I'd rather see an X.509 tutorial if you're dead set on writing something besides strict plain b2a_base64() doc. :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 11:52:11 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 05 Nov 2015 16:52:11 +0000 Subject: [issue25552] python turtle page does not run In-Reply-To: <1446688819.99.0.0895353718927.issue25552@psf.upfronthosting.co.za> Message-ID: <1446742331.5.0.122102547175.issue25552@psf.upfronthosting.co.za> R. David Murray added the comment: This is not a place to get help with turtle programming, but rather a place to report bugs. We know turtle works, we have tests :). For help your best bet would be the python-list mailing list, or perhaps python-tutor. Probably the latter: I note that your program doesn't actually do anything, it just defines some functions. ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 11:53:35 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 05 Nov 2015 16:53:35 +0000 Subject: [issue25558] Use static asserts in C code In-Reply-To: <1446742000.61.0.314081889142.issue25558@psf.upfronthosting.co.za> Message-ID: <1446742415.92.0.519205819647.issue25558@psf.upfronthosting.co.za> STINNER Victor added the comment: + (void)Py_BUILD_ASSERT_EXPR(INT_MAX <= _PyTime_MAX / SEC_TO_NS); Hum, maybe the existing macro should be renamed to Py_BUILD_ASSERT_EXPR and a new Py_BUILD_ASSERT_EXPR macro should add the (void) to ignore the result? It would avoid to have to repeat (void) everywhere. What do you think? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 11:54:37 2015 From: report at bugs.python.org (Tom Meagher) Date: Thu, 05 Nov 2015 16:54:37 +0000 Subject: [issue25559] signal.siginterrupt description has typo Message-ID: <1446742477.79.0.638926215917.issue25559@psf.upfronthosting.co.za> New submission from Tom Meagher: "if flag is False, system calls will be restarted when interrupted by signal signalnum, otherwise system calls will be interrupted." This sentence doesn't make any sense as written. I assume there should be a "not" in there somewhere, but I'm unclear if signal calls are not interrupted when the flag is false, or not interrupted when they are true. ---------- assignee: docs at python components: Documentation messages: 254121 nosy: Tom Meagher, docs at python priority: normal severity: normal status: open title: signal.siginterrupt description has typo type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 11:56:20 2015 From: report at bugs.python.org (Mouse) Date: Thu, 05 Nov 2015 16:56:20 +0000 Subject: [issue25495] binascii documentation incorrect In-Reply-To: <1445987417.55.0.122139453671.issue25495@psf.upfronthosting.co.za> Message-ID: <1446742580.67.0.804434045657.issue25495@psf.upfronthosting.co.za> Mouse added the comment: To add: I do not understand your attachment to that 57 "...(exactly 57 bytes of input data per line)", and request that this parenthesized sentence is removed from your Python-2.7 doc patch. Please give the reader the benefit of the doubt, and allow that *if* he wants to repeatedly call b2a_base64() instead of splitting its output - the ability to compute (76 * 3 / 4) is within his skill level. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 11:56:40 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 05 Nov 2015 16:56:40 +0000 Subject: [issue25558] Use static asserts in C code In-Reply-To: <1446742000.61.0.314081889142.issue25558@psf.upfronthosting.co.za> Message-ID: <1446742600.06.0.233076160323.issue25558@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This is a public name and can be used in third-party code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 11:57:23 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 05 Nov 2015 16:57:23 +0000 Subject: [issue25558] Use static asserts in C code In-Reply-To: <1446742000.61.0.314081889142.issue25558@psf.upfronthosting.co.za> Message-ID: <1446742643.48.0.300798291609.issue25558@psf.upfronthosting.co.za> STINNER Victor added the comment: > This is a public name and can be used in third-party code. Do you mean that a library can really rely on the result!? It would be insane :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 11:59:37 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 05 Nov 2015 16:59:37 +0000 Subject: [issue25558] Use static asserts in C code In-Reply-To: <1446742000.61.0.314081889142.issue25558@psf.upfronthosting.co.za> Message-ID: <1446742777.66.0.40844339011.issue25558@psf.upfronthosting.co.za> STINNER Victor added the comment: Hum, maybe I wasn't clear: I propose attached macro.patch. ---------- Added file: http://bugs.python.org/file40956/macro.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 12:03:07 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 05 Nov 2015 17:03:07 +0000 Subject: [issue25558] Use static asserts in C code In-Reply-To: <1446742000.61.0.314081889142.issue25558@psf.upfronthosting.co.za> Message-ID: <1446742987.11.0.773693921098.issue25558@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: A library can follow the example in the comment. #define foo_to_char(foo) \ ((char *)(foo) \ + Py_BUILD_ASSERT_EXPR(offsetof(struct foo, string) == 0)) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 12:14:13 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 05 Nov 2015 17:14:13 +0000 Subject: [issue25553] SMTP.data(msg) function may cause the last CRLF of msg lost if msg is quoted-printable encoding. In-Reply-To: <1446706315.09.0.659513655808.issue25553@psf.upfronthosting.co.za> Message-ID: <1446743653.62.0.929615586069.issue25553@psf.upfronthosting.co.za> R. David Murray added the comment: RFC 2812 says: Note that the first of this terminating sequence is also the that ends the final line of the data (message text) So, smtplib is correct. If you have a server that is not respecting this, then that server is out of compliance and there isn't anything we can do about it. However, I don't think that is your problem. = at the end of a line actually represents a "soft carriage return", which means one that is *eliminated* in the decoded output. If you will read section 6.7 of rfc 2045, specifically notes (2) and (3) in the second block of numbered paragraphs, you will see that an 'ultimate' = (an = at the end of an encoded block, with or without a CRLF after it), such as you have in your sample, is illegal. Further, the recommended recovery action if one is seen while decoding is to leave the = in the decoded output, just as you are observing happening. So, there is no bug here except in your message :) ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 12:18:57 2015 From: report at bugs.python.org (Stefan Krah) Date: Thu, 05 Nov 2015 17:18:57 +0000 Subject: [issue25558] Use static asserts in C code In-Reply-To: <1446742000.61.0.314081889142.issue25558@psf.upfronthosting.co.za> Message-ID: <1446743937.67.0.835318052586.issue25558@psf.upfronthosting.co.za> Stefan Krah added the comment: Serhiy, could you please not change stuff that I maintain? I know you have the best intentions, but I really don't like these kinds of changes (just like you don't like trailing whitespace :). ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 12:20:53 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 05 Nov 2015 17:20:53 +0000 Subject: [issue25558] Use static asserts in C code In-Reply-To: <1446742000.61.0.314081889142.issue25558@psf.upfronthosting.co.za> Message-ID: <1446744053.16.0.230588991717.issue25558@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: OK, I'll exclude Modules/_decimal/_decimal.c. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 12:22:51 2015 From: report at bugs.python.org (Stefan Krah) Date: Thu, 05 Nov 2015 17:22:51 +0000 Subject: [issue25558] Use static asserts in C code In-Reply-To: <1446742000.61.0.314081889142.issue25558@psf.upfronthosting.co.za> Message-ID: <1446744171.97.0.0730663543846.issue25558@psf.upfronthosting.co.za> Stefan Krah added the comment: Thank you! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 12:35:37 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 05 Nov 2015 17:35:37 +0000 Subject: [issue25545] email parsing docs need to be clear that only ASCII strings are supported In-Reply-To: <1446561810.16.0.921085816129.issue25545@psf.upfronthosting.co.za> Message-ID: <1446744937.56.0.0775324107287.issue25545@psf.upfronthosting.co.za> R. David Murray added the comment: I agree that the situation is not the best, but it is the one we have. I can't delete those methods now, they've existed in Python3 for too long, and initially were the only thing that worked (albeit only with ASCII only strings). If you can suggest ways of improving the string support without breaking existing python3 code that may be using it (most likely wrongly, but working for them), then I will happily review them. As for "that sounds strange" about non-ascii bodies being non-trivial, remember that the context is the byte-string serialization protocol defined in RFC 5322. This is the *evolution* of a protocol that started out ascii only, learned something about 8-bit data, then learned something about using bytes for handling other languages. It is an evolutionary mess that has lots of pitfalls. You can't simply serialize a message to unicode, preserving the RFC 5322/MIME markup, and have a valid email, unless you make it a 7-bit clean (ascii only) representation. And that is what the email package does. So, conversely, email can only *parse* (as a string) a 7-bit, ASCII only, representation. To do what you appear to want, to be able to represent non-ascii as the equivalent unicode *cannot work*, because email messages may contain binary data which *cannot* be represented in printable unicode. So, it is *unfortunate* that a non-ascii body is non-trivial in email, but there's no getting around the fact that it is. The new API in python3 aims to make it as simple as possible, but of course that doesn't help python2 users. But, making unicode easier is one big reason python3 exists (the biggest one, in practice). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 12:49:27 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 05 Nov 2015 17:49:27 +0000 Subject: [issue25559] signal.siginterrupt description has typo In-Reply-To: <1446742477.79.0.638926215917.issue25559@psf.upfronthosting.co.za> Message-ID: <1446745767.36.0.391739697084.issue25559@psf.upfronthosting.co.za> R. David Murray added the comment: The first phase says "restarted when interrupted", the second phrase says "interrupted". So the difference is whether the system call is restarted or left in interrupted state (ie: the signal will propagate, which is confirmed by the second paragraph). I can't see a way to phrase it any more clearly, can you? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 13:31:58 2015 From: report at bugs.python.org (ppperry) Date: Thu, 05 Nov 2015 18:31:58 +0000 Subject: [issue25560] Unhandled warning in test_unicode_file Message-ID: <1446748318.85.0.363249133538.issue25560@psf.upfronthosting.co.za> New submission from ppperry: >python -Wall -m test.regrtest test_unicode_file [1/1] test_unicode_file C:\Python27\lib\shutil.py:64: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal os.path.normcase(os.path.abspath(dst))) C:\Python27\lib\shutil.py:64: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal os.path.normcase(os.path.abspath(dst))) C:\Python27\lib\shutil.py:64: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal os.path.normcase(os.path.abspath(dst))) C:\Python27\lib\shutil.py:64: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal os.path.normcase(os.path.abspath(dst))) 1 test OK. ---------- components: Tests messages: 254133 nosy: ppperry priority: normal severity: normal status: open title: Unhandled warning in test_unicode_file type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 14:16:29 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 05 Nov 2015 19:16:29 +0000 Subject: [issue25560] Unhandled warning in test_unicode_file In-Reply-To: <1446748318.85.0.363249133538.issue25560@psf.upfronthosting.co.za> Message-ID: <1446750989.0.0.671529227086.issue25560@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 14:20:56 2015 From: report at bugs.python.org (GuiHome) Date: Thu, 05 Nov 2015 19:20:56 +0000 Subject: [issue24424] xml.dom.minidom: performance issue with Node.insertBefore() In-Reply-To: <1433942956.66.0.599460998017.issue24424@psf.upfronthosting.co.za> Message-ID: <1446751256.76.0.437649585557.issue24424@psf.upfronthosting.co.za> GuiHome added the comment: We have been running this patch for several month now without any issue. Would be glad if a maintainer could review it and merge it upstream. thanks ---------- nosy: +guihome _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 14:42:18 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 05 Nov 2015 19:42:18 +0000 Subject: [issue12612] Valgrind suppressions In-Reply-To: <1311352571.88.0.0623185894462.issue12612@psf.upfronthosting.co.za> Message-ID: <20151105194215.1981.35177@psf.io> Roundup Robot added the comment: New changeset 92dda5f00b0f by doko in branch '2.7': Issue #12612: Add some Valgrind suppressions for 64-bit machines. https://hg.python.org/cpython/rev/92dda5f00b0f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 14:57:36 2015 From: report at bugs.python.org (Ivan Bykov) Date: Thu, 05 Nov 2015 19:57:36 +0000 Subject: [issue25561] unstable result of time.monotonic Message-ID: <1446753456.41.0.00863124653173.issue25561@psf.upfronthosting.co.za> New submission from Ivan Bykov: Python 3.4.3 (v3.4.3:9b73f1c3e601, Feb 24 2015, 22:44:40) [MSC v.1600 64 bit (AMD64)] on win32 Type "copyright", "credits" or "license()" for more information. >>> import platform >>> platform.win32_ver() ('7', '6.1.7601', 'SP1', 'Multiprocessor Free') >>> Result of test.py: C:\1>"test.py" 0.000000 0.001000 C:\1>"test.py" 0.000000 0.001001 C:\1>"test.py" 0.000000 0.001000 C:\1>"test.py" 0.016000 0.001000 C:\1>"test.py" 0.000000 0.001000 C:\1>"test.py" 0.016000 0.001000 C:\1>"test.py" 0.000000 0.001000 C:\1>"test.py" 0.000000 0.001000 C:\1>"test.py" 0.016000 0.001000 ---------- components: Windows files: test.py messages: 254136 nosy: haypo, ivb, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: unstable result of time.monotonic type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file40957/test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 15:18:12 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 05 Nov 2015 20:18:12 +0000 Subject: [issue24802] int and float constructing from non NUL-terminated buffer In-Reply-To: <1438830920.07.0.863152787453.issue24802@psf.upfronthosting.co.za> Message-ID: <1446754692.75.0.737386813856.issue24802@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Great! Besides few nitpicks the patch LGTM. > However I don?t understand what you meant about restoring int(bytes, base) behaviour. None of the patches here, nor in Issue 22896, touch long_new() in /Objects/longobject.c. long_new() uses PyNumber_Long(). I was wrong, the contrary case is affected, when the base is not specified. ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 15:20:23 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 05 Nov 2015 20:20:23 +0000 Subject: [issue25561] unstable result of time.monotonic In-Reply-To: <1446753456.41.0.00863124653173.issue25561@psf.upfronthosting.co.za> Message-ID: <1446754823.31.0.388037446904.issue25561@psf.upfronthosting.co.za> STINNER Victor added the comment: > unstable result of time.monotonic I'm sorry, I don't understand your problem. What do you expect? Why do you consider that your results are a bug? You computed the duration of "import unicodedata" using the system clock and using the monotonic clock. So what? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 15:24:23 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 05 Nov 2015 20:24:23 +0000 Subject: [issue18010] pydoc search chokes on import errors In-Reply-To: <1368896719.35.0.915741072389.issue18010@psf.upfronthosting.co.za> Message-ID: <1446755063.5.0.309438305004.issue18010@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Oh, I were not expected that the test will be so complex, and now I'm not sure that want it. :-( But looks it can't be written simpler. The patch LGTM in any case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 15:24:32 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 05 Nov 2015 20:24:32 +0000 Subject: [issue18010] pydoc search chokes on import errors In-Reply-To: <1368896719.35.0.915741072389.issue18010@psf.upfronthosting.co.za> Message-ID: <1446755072.22.0.073243660264.issue18010@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 15:30:22 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 05 Nov 2015 20:30:22 +0000 Subject: [issue25559] signal.siginterrupt description has typo In-Reply-To: <1446742477.79.0.638926215917.issue25559@psf.upfronthosting.co.za> Message-ID: <1446755422.46.0.216500289862.issue25559@psf.upfronthosting.co.za> STINNER Victor added the comment: For more information on how Python handles signals, you can also read the PEP 475 (which changed how Python 3.5 handles signals ;-)) ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 15:58:42 2015 From: report at bugs.python.org (Georg Brandl) Date: Thu, 05 Nov 2015 20:58:42 +0000 Subject: [issue25495] binascii documentation incorrect In-Reply-To: <1445987417.55.0.122139453671.issue25495@psf.upfronthosting.co.za> Message-ID: <1446757122.3.0.374938903007.issue25495@psf.upfronthosting.co.za> Georg Brandl added the comment: issue25495.base64.2.7.patch looks good to me. A similar patch can be adapted for 3.x. ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 16:10:24 2015 From: report at bugs.python.org (Lukas Lueg) Date: Thu, 05 Nov 2015 21:10:24 +0000 Subject: [issue25465] Pickle uses O(n) memory overhead In-Reply-To: <1445593043.5.0.334623277706.issue25465@psf.upfronthosting.co.za> Message-ID: <1446757824.14.0.65508262495.issue25465@psf.upfronthosting.co.za> Lukas Lueg added the comment: I very strongly doubt that it actually crashes your kernel - it basically can't. Your desktop becomes unresponsive for up to several minutes as the kernel has paged out about every single bit of memory to disk, raising access times by several orders of magnitude. Disable your swap and try again, it will just die. ---------- nosy: +ebfe _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 16:49:02 2015 From: report at bugs.python.org (tzickel) Date: Thu, 05 Nov 2015 21:49:02 +0000 Subject: [issue25562] Python 2 & 3 don't allow the user to disable ctypes SEH in windows Message-ID: <1446760142.46.0.74280732074.issue25562@psf.upfronthosting.co.za> New submission from tzickel: In Windows, there is a mechanizm called SEH that allows C/C++ programs to catch OS Exceptions (such as divide by zero, page faults, etc..). Python's ctypes module for some reason forces the user to wrap all ctypes FFI calls with a special SEH wrapper that converts those exceptions to Python exceptions. For the UNIX people think about it that python installs a signal handler without you asking (or being able to remove it) when calling FFI functions. The main issue with this, is that when you want to debug why a DLL behaves badly and you want a process dump (or catch the stack trace in the DLL) you can't without attaching a debugger and catching first-chance exceptions (because the ctypes SEH handling masks the issue). My proposal is to have both in python 2 and in python 3 an option to call an FFI function with selectively using or not SEH. Here is the SEH wrap (as you can see it's not optional in runtime): https://github.com/python/cpython/blob/master/Modules/_ctypes/callproc.c#L806 ---------- components: ctypes messages: 254143 nosy: amaury.forgeotdarc, belopolsky, meador.inge, tzickel priority: normal severity: normal status: open title: Python 2 & 3 don't allow the user to disable ctypes SEH in windows type: behavior versions: Python 2.7, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 17:28:29 2015 From: report at bugs.python.org (Lester Veenstra) Date: Thu, 05 Nov 2015 22:28:29 +0000 Subject: [issue25563] Windows 10 IDLE /Tniker startup problem Message-ID: <1446762509.1.0.723427764258.issue25563@psf.upfronthosting.co.za> New submission from Lester Veenstra: C:\Users\lbv>python Python 2.7.10 (default, May 23 2015, 09:40:32) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import Tkinter Traceback (most recent call last): File "", line 1, in File "d:\python27\lib\lib-tk\Tkinter.py", line 38, in import FixTk File "d:\python27\lib\lib-tk\FixTk.py", line 65, in import _tkinter ImportError: DLL load failed: %1 is not a valid Win32 application. ---------- components: Tkinter messages: 254144 nosy: veensl priority: normal severity: normal status: open title: Windows 10 IDLE /Tniker startup problem type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 17:32:38 2015 From: report at bugs.python.org (Vilnis Termanis) Date: Thu, 05 Nov 2015 22:32:38 +0000 Subject: [issue25469] multiprocessing .Condition.notify(_all) function has O(N) time complexity where N is the number of wait() calls with a timeout since the last notify(_all) call In-Reply-To: <1445681395.35.0.393874869917.issue25469@psf.upfronthosting.co.za> Message-ID: <1446762758.54.0.521137586911.issue25469@psf.upfronthosting.co.za> Vilnis Termanis added the comment: I've added a regression test for the proposed patch along the lines of the example script (i.e. fails before and passes with patch). Apologies if the test is a bit clumsy - maybe there is a more elegant way? ---------- Added file: http://bugs.python.org/file40958/mp_sync_condition_with_test.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 17:56:17 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 05 Nov 2015 22:56:17 +0000 Subject: [issue25562] Python 2 & 3 don't allow the user to disable ctypes SEH in windows In-Reply-To: <1446760142.46.0.74280732074.issue25562@psf.upfronthosting.co.za> Message-ID: <1446764177.68.0.611784987111.issue25562@psf.upfronthosting.co.za> R. David Murray added the comment: This would be a new feature and so would not be acceptable for python2.7. I wonder if cffi has such a switch. ---------- nosy: +r.david.murray type: behavior -> enhancement versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 17:56:47 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 05 Nov 2015 22:56:47 +0000 Subject: [issue25563] Windows 10 IDLE / Tkinter startup problem In-Reply-To: <1446762509.1.0.723427764258.issue25563@psf.upfronthosting.co.za> Message-ID: <1446764207.01.0.723594365428.issue25563@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware title: Windows 10 IDLE /Tniker startup problem -> Windows 10 IDLE / Tkinter startup problem _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 18:08:10 2015 From: report at bugs.python.org (ppperry) Date: Thu, 05 Nov 2015 23:08:10 +0000 Subject: [issue25563] Windows 10 IDLE / Tkinter startup problem In-Reply-To: <1446762509.1.0.723427764258.issue25563@psf.upfronthosting.co.za> Message-ID: <1446764890.63.0.730854226823.issue25563@psf.upfronthosting.co.za> ppperry added the comment: This might be a duplicate of issue8820 ---------- nosy: +ppperry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 18:11:58 2015 From: report at bugs.python.org (ppperry) Date: Thu, 05 Nov 2015 23:11:58 +0000 Subject: [issue25563] Windows 10 IDLE / Tkinter startup problem In-Reply-To: <1446762509.1.0.723427764258.issue25563@psf.upfronthosting.co.za> Message-ID: <1446765118.61.0.163174184002.issue25563@psf.upfronthosting.co.za> Changes by ppperry : ---------- nosy: -ppperry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 18:24:19 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 05 Nov 2015 23:24:19 +0000 Subject: [issue25495] binascii documentation incorrect In-Reply-To: <1445987417.55.0.122139453671.issue25495@psf.upfronthosting.co.za> Message-ID: <1446765859.97.0.965101610387.issue25495@psf.upfronthosting.co.za> Martin Panter added the comment: Mouse, I know you originally opened this against 3.5. Apart from the module description at the bottom, my patch should be valid for 3.5 also. The relevant wording is identical to 2.7. I have resisted removing the magic number 57 for a couple of reasons. Reading existing code that uses this number may be harder. David said he would be happier with it kept. I believed we could solve your original complaint and explain why the number was really there at the same time. It helps explain how the function was originally to be used, and why the newline is appended. Anyway, I think it is best if I let this go, and someone else pick it up. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 18:26:04 2015 From: report at bugs.python.org (ppperry) Date: Thu, 05 Nov 2015 23:26:04 +0000 Subject: [issue25564] IDLE behaves differently that the standard interpreter when someone types `del __builtins__` Message-ID: <1446765964.78.0.0240100073004.issue25564@psf.upfronthosting.co.za> New submission from ppperry: In IDLE the following code silently works: >>> del __builtins__ >>> min In the standard interpreter, it produces an error: >>> del __builtins__ >>> min Traceback (most recent call last): File "", line 1, in NameError: name 'min' is not defined Note that saying `__builtins__ = 7` fails in idle as well. ---------- components: IDLE, Interpreter Core messages: 254149 nosy: ppperry priority: normal severity: normal status: open title: IDLE behaves differently that the standard interpreter when someone types `del __builtins__` _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 18:28:14 2015 From: report at bugs.python.org (ppperry) Date: Thu, 05 Nov 2015 23:28:14 +0000 Subject: [issue25564] IDLE behaves differently that the standard interpreter when someone types `del __builtins__` In-Reply-To: <1446765964.78.0.0240100073004.issue25564@psf.upfronthosting.co.za> Message-ID: <1446766094.23.0.735200450147.issue25564@psf.upfronthosting.co.za> ppperry added the comment: If you type `del __builtins__;min` an error is raise in both IDLE and the standard interpreter. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 18:31:20 2015 From: report at bugs.python.org (ppperry) Date: Thu, 05 Nov 2015 23:31:20 +0000 Subject: [issue25564] IDLE behaves differently that the standard interpreter when someone types `del __builtins__` In-Reply-To: <1446765964.78.0.0240100073004.issue25564@psf.upfronthosting.co.za> Message-ID: <1446766280.97.0.706569080756.issue25564@psf.upfronthosting.co.za> ppperry added the comment: `del __builtins__;min` only fails in IDLE if someone has previously set `__builtins__ to something else. >>>__builtins__ = 7 >>> min Traceback (most recent call last): File "", line 1, in min NameError: name 'min' is not defined >>>del __builtins__;min Traceback (most recent call last): File "", line 1, in del __builtins__;min NameError: name 'min' is not defined >>del __builtins__;min ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 18:31:46 2015 From: report at bugs.python.org (ppperry) Date: Thu, 05 Nov 2015 23:31:46 +0000 Subject: [issue25564] IDLE behaves differently that the standard interpreter when someone types `del __builtins__` In-Reply-To: <1446765964.78.0.0240100073004.issue25564@psf.upfronthosting.co.za> Message-ID: <1446766306.01.0.925637961568.issue25564@psf.upfronthosting.co.za> Changes by ppperry : ---------- versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 19:02:04 2015 From: report at bugs.python.org (Eric Snow) Date: Fri, 06 Nov 2015 00:02:04 +0000 Subject: [issue25410] Clean up and fix OrderedDict In-Reply-To: <1444896308.75.0.718152743923.issue25410@psf.upfronthosting.co.za> Message-ID: <1446768124.46.0.99387651019.issue25410@psf.upfronthosting.co.za> Eric Snow added the comment: All 3 patches look fine to me. In "odict_resize_sentinel.patch", it would be nice if you could accomplish that with a single sentinel. However, fixing the bug is more critical. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 19:02:30 2015 From: report at bugs.python.org (Eric Snow) Date: Fri, 06 Nov 2015 00:02:30 +0000 Subject: [issue25410] Clean up and fix OrderedDict In-Reply-To: <1444896308.75.0.718152743923.issue25410@psf.upfronthosting.co.za> Message-ID: <1446768150.47.0.169377011859.issue25410@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 19:59:46 2015 From: report at bugs.python.org (Steven D'Aprano) Date: Fri, 06 Nov 2015 00:59:46 +0000 Subject: [issue25564] IDLE behaves differently that the standard interpreter when someone types `del __builtins__` In-Reply-To: <1446765964.78.0.0240100073004.issue25564@psf.upfronthosting.co.za> Message-ID: <1446771586.43.0.0302074492648.issue25564@psf.upfronthosting.co.za> Steven D'Aprano added the comment: __builtins__ is a private implementation detail in CPython. There is no guarantees made about whether it exists or not. E.g. it doesn't exist in Jython. steve at orac:~/python$ jython Jython 2.5.1+ (Release_2_5_1, Aug 4 2010, 07:18:19) [OpenJDK Server VM (Sun Microsystems Inc.)] on java1.6.0_31 Type "help", "copyright", "credits" or "license" for more information. >>> __builtins__ Traceback (most recent call last): File "", line 1, in NameError: name '__builtins__' is not defined You should use `__builtin__` in Python 2 and `builtins` in Python 3. *Anything* you do to `__builtins__` with an S is implementation-dependent. I don't think it is a bug that CPython behaves differently regarding __builtins__ depending on whether IDLE is running or not. ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 20:01:29 2015 From: report at bugs.python.org (Steven D'Aprano) Date: Fri, 06 Nov 2015 01:01:29 +0000 Subject: [issue25564] IDLE behaves differently that the standard interpreter when someone types `del __builtins__` In-Reply-To: <1446765964.78.0.0240100073004.issue25564@psf.upfronthosting.co.za> Message-ID: <1446771689.91.0.177426427931.issue25564@psf.upfronthosting.co.za> Changes by Steven D'Aprano : ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 20:06:43 2015 From: report at bugs.python.org (Steven D'Aprano) Date: Fri, 06 Nov 2015 01:06:43 +0000 Subject: [issue25177] OverflowError in statistics.mean when summing large floats In-Reply-To: <1442662840.23.0.781753910755.issue25177@psf.upfronthosting.co.za> Message-ID: <1446772003.69.0.527144220615.issue25177@psf.upfronthosting.co.za> Steven D'Aprano added the comment: Has anyone confirmed that this bug actually exists? I'm afraid that I cannot verify it. I get these results on three different computers: py> x = 8.988465674311579e+307 py> statistics.mean([x, x]) 8.988465674311579e+307 py> statistics.mean([x, x]) == x True running Python 3.4.3, a backport on 3.3.0rc3, and the default branch in the repo (3.6.0a). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 20:07:21 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Fri, 06 Nov 2015 01:07:21 +0000 Subject: [issue25555] Fix parser and AST: fill lineno and col_offset when compiling AST from Python objects In-Reply-To: <1446716524.88.0.975797398415.issue25555@psf.upfronthosting.co.za> Message-ID: <1446772041.43.0.432591480139.issue25555@psf.upfronthosting.co.za> St?phane Wirtel added the comment: Hi Victor, 1. Result of the compilation -> success 2. I have checked your patch, I think there is no problem. 3. How can I test it? currently, everything is fine. For me, this patch is ok and working, but I need the point 3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 20:10:00 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 06 Nov 2015 01:10:00 +0000 Subject: [issue18010] pydoc search chokes on import errors In-Reply-To: <1368896719.35.0.915741072389.issue18010@psf.upfronthosting.co.za> Message-ID: <20151106010955.57609.68223@psf.io> Roundup Robot added the comment: New changeset 9098731de840 by Martin Panter in branch '3.4': Issue #18010: Fix pydoc web server search to handle package exceptions https://hg.python.org/cpython/rev/9098731de840 New changeset 8702efa1feb4 by Martin Panter in branch '3.5': Issue #18010: Merge pydoc web search fix from 3.4 into 3.5 https://hg.python.org/cpython/rev/8702efa1feb4 New changeset d86ff708f545 by Martin Panter in branch 'default': Issue #18010: Merge pydoc web search fix from 3.5 https://hg.python.org/cpython/rev/d86ff708f545 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 20:16:07 2015 From: report at bugs.python.org (Steven D'Aprano) Date: Fri, 06 Nov 2015 01:16:07 +0000 Subject: [issue25177] OverflowError in statistics.mean when summing large floats In-Reply-To: <1446772003.69.0.527144220615.issue25177@psf.upfronthosting.co.za> Message-ID: <20151106011319.GQ10946@ando.pearwood.info> Steven D'Aprano added the comment: > Has anyone confirmed that this bug actually exists? Confirmed. The initial report is not quite correct: you need three values to trigger the overflow, not two: py> x = 8.988465674311579e+307 py> statistics.mean([x]*2) == x True py> statistics.mean([x]*3) == x Traceback (most recent call last): File "", line 1, in File "./statistics.py", line 289, in mean return _sum(data)/n File "./statistics.py", line 184, in _sum return T(total) File "/usr/local/lib/python3.3/numbers.py", line 296, in __float__ return self.numerator / self.denominator OverflowError: integer division result too large for a float ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 20:19:12 2015 From: report at bugs.python.org (Eric V. Smith) Date: Fri, 06 Nov 2015 01:19:12 +0000 Subject: [issue25561] unstable result of time.monotonic In-Reply-To: <1446753456.41.0.00863124653173.issue25561@psf.upfronthosting.co.za> Message-ID: <1446772752.62.0.769553017423.issue25561@psf.upfronthosting.co.za> Eric V. Smith added the comment: I agree that there's no bug here: the timers are working as expected. ivb: if you disagree, please explain what behavior you expected, versus what you see. ---------- nosy: +eric.smith resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 20:23:36 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Fri, 06 Nov 2015 01:23:36 +0000 Subject: [issue21224] BaseHTTPRequestHandler, update the protocol version to http 1.1 by default? In-Reply-To: <1397508232.09.0.0337317788686.issue21224@psf.upfronthosting.co.za> Message-ID: <1446773016.14.0.801199854355.issue21224@psf.upfronthosting.co.za> St?phane Wirtel added the comment: pong patience is one key to success ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 20:31:40 2015 From: report at bugs.python.org (Lester Veenstra) Date: Fri, 06 Nov 2015 01:31:40 +0000 Subject: [issue25563] Windows 10 IDLE / Tkinter startup problem In-Reply-To: <1446762509.1.0.723427764258.issue25563@psf.upfronthosting.co.za> Message-ID: <1446773500.53.0.489708267378.issue25563@psf.upfronthosting.co.za> Lester Veenstra added the comment: May well be a duplicate of issue 8820 but never the less it is still a real problem ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 20:36:03 2015 From: report at bugs.python.org (Giampaolo Rodola') Date: Fri, 06 Nov 2015 01:36:03 +0000 Subject: [issue25157] Installing Python 3.5.0 32bit on Windows 8.1 64bit system gives Error 0x80240017 In-Reply-To: <1442526643.4.0.412457342038.issue25157@psf.upfronthosting.co.za> Message-ID: <1446773763.55.0.42045571255.issue25157@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: I confirm the problem can be fixed by installing SP-1 (on Windows 7). Thanks eryksun. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 21:01:18 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 06 Nov 2015 02:01:18 +0000 Subject: [issue18010] pydoc search chokes on import errors In-Reply-To: <1368896719.35.0.915741072389.issue18010@psf.upfronthosting.co.za> Message-ID: <1446775278.59.0.390168226128.issue18010@psf.upfronthosting.co.za> Martin Panter added the comment: In Python 2, it looks like instead of the web server search function there is a GUI search function. Here is a patch to fix the equivalent problem there. However I am not volunteering to make a test case; there does not seem to be any GUI tests to start with. ---------- stage: commit review -> patch review Added file: http://bugs.python.org/file40959/gui-search.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 21:30:37 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 06 Nov 2015 02:30:37 +0000 Subject: [issue21224] BaseHTTPRequestHandler, update the protocol version to http 1.1 by default? In-Reply-To: <1397508232.09.0.0337317788686.issue21224@psf.upfronthosting.co.za> Message-ID: <1446777037.95.0.451230134901.issue21224@psf.upfronthosting.co.za> Martin Panter added the comment: What are the advantages of changing the default? Just that the user no longer has to set it manually? What do you think of the problem mentioned in the documentation? If an existing HTTP 1.0 server that works fine in Python 3.5 were to suddenly have protocol_version="HTTP/1.1" forced by default, it sounds like all its responses may stop working (hang from the client?s POV) if they don?t explicitly close the connection. One option could be to wrap the ?wfile? stream in a chunk encoder, and insert Transfer-Encoding: chunked. I haven?t thought through this much, and it may not work very well because Python?s HTTP server is so low-level. This would basically be a HTTP 1.1 to HTTP 1.0 proxy. Similarly, I understand HTTP 1.1 requires chunked encoding support for requests, but there is no support for that in the Python implementation. Existing servers accepting e.g. POST uploads would expect a Content-Length header, which would be hard to fake with a compatibility proxy (may need to buffer it all to count the bytes). Another way might be a deprecation cycle, to force people using 3.6 to set protocol_version. ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 21:39:08 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 06 Nov 2015 02:39:08 +0000 Subject: [issue21224] BaseHTTPRequestHandler, update the protocol version to http 1.1 by default? In-Reply-To: <1397508232.09.0.0337317788686.issue21224@psf.upfronthosting.co.za> Message-ID: <1446777548.91.0.992882090057.issue21224@psf.upfronthosting.co.za> Martin Panter added the comment: Actually RFC 7230 says ?A server may reject a request that contains a message body but not a Content-Length by responding with 411 (Length Required)?, so maybe it is only clients that have to support chunked decoding. So I take back my paragraph about POST requests. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 22:12:09 2015 From: report at bugs.python.org (Rose Ames) Date: Fri, 06 Nov 2015 03:12:09 +0000 Subject: [issue3353] make built-in tokenizer available via Python C API In-Reply-To: <1216035196.11.0.15913194841.issue3353@psf.upfronthosting.co.za> Message-ID: <1446779529.49.0.667664102947.issue3353@psf.upfronthosting.co.za> Changes by Rose Ames : ---------- nosy: +superluser _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 22:16:17 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 06 Nov 2015 03:16:17 +0000 Subject: [issue13153] IDLE crashes when pasting non-BMP unicode char on Py3 In-Reply-To: <1318363292.9.0.682519731008.issue13153@psf.upfronthosting.co.za> Message-ID: <1446779777.65.0.84302492872.issue13153@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I am puzzled at the following. Some reported today that IDLE crashed when pasting the Snake emoji U+1F40D ?. I copied from Thunderbird and pasted in IDLE on Win10, with same UnicodeDecodeError as before. I then ran this simple code from tkinter import * # 3.4, 3.5, 2.7 with Tkinter root = Tk() text = Text(root) text.pack() text.focus_set() # required to work root.mainloop() pasted the char there, and to my surprise, a black & white version of the snake appeared. How? I thought tk does not support astral chars? I copied from the Text window to paste above, where it is green for me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 22:17:54 2015 From: report at bugs.python.org (Davin Potts) Date: Fri, 06 Nov 2015 03:17:54 +0000 Subject: [issue20607] multiprocessing cx_Freeze windows GUI bug (& easy fixes) In-Reply-To: <1392210007.55.0.703344543531.issue20607@psf.upfronthosting.co.za> Message-ID: <1446779874.23.0.777730726253.issue20607@psf.upfronthosting.co.za> Davin Potts added the comment: Mark: Patches to 3.3 are generally not being considered (due to its age) but patches to 3.5 (possibly 3.4) would be. You suggest the issue can't be reproduced in 3.4 but have to tried in the current 3.5 release? ---------- nosy: +davin type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 22:20:20 2015 From: report at bugs.python.org (Davin Potts) Date: Fri, 06 Nov 2015 03:20:20 +0000 Subject: [issue25469] multiprocessing .Condition.notify(_all) function has O(N) time complexity where N is the number of wait() calls with a timeout since the last notify(_all) call In-Reply-To: <1445681395.35.0.393874869917.issue25469@psf.upfronthosting.co.za> Message-ID: <1446780020.57.0.487441649333.issue25469@psf.upfronthosting.co.za> Changes by Davin Potts : ---------- nosy: +davin versions: +Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 5 22:54:44 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 06 Nov 2015 03:54:44 +0000 Subject: [issue3559] Pasted \n not same as typed \n In-Reply-To: <1218778489.95.0.525643042727.issue3559@psf.upfronthosting.co.za> Message-ID: <1446782084.86.0.914729366033.issue3559@psf.upfronthosting.co.za> Terry J. Reedy added the comment: In #9618, it was pointed out that IDLE Shell inherits from code.InteractiveConsole, and that #7741 proposes to allow multiple statements there. In 3.5, this example from msg114561 now gives a SyntaxError, as it should. >>> x = 3 y = 7 Seven years after opening this, I am more appreciative of 'enter and execute (and recall)' one statement at a time, especially for beginners. Ditto for being able to edit a paste before executing. So I am more inclined to just add the note to the doc (which currently says nothing about executing anyway). Someone who wants to paste, execute, and recall multiple statements as a block, without having output interleaved, can wrap with 'if 1:'. >>> if 1: 1+2 3+4 3 7 ---------- assignee: -> terry.reedy components: +Documentation stage: patch review -> needs patch versions: +Python 3.5, Python 3.6 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 00:22:27 2015 From: report at bugs.python.org (Jack O'Connor) Date: Fri, 06 Nov 2015 05:22:27 +0000 Subject: [issue25565] subprocess.Popen creates inheritable file descriptors on Windows, can leak to other child processes Message-ID: <1446787347.51.0.846654506724.issue25565@psf.upfronthosting.co.za> New submission from Jack O'Connor: The Windows implementation of Popen calls _make_inheritable(), which creates inheritable copies of Popen's file descriptors. If two Popen calls happen at the same time on different threads, these descriptors can leak to both child processes. Here's a demonstration of a deadlock caused by this bug: https://gist.github.com/oconnor663/b1d39d58b232fc627d84 Victor Stinner also wrote up a summary of the security issues associated with leaking file descriptors in PEP 0446. A workaround for this issue is to protect all Popen calls with a lock. Calls to wait() and communicate() don't need to be protected, so you can release the lock before you make those blocking calls. I don't see a way to safely use run() or the other convenience functions, if you're using pipes and multiple threads. Unfortunately close_fds=True is not allowed on Windows when any of stdin/stdout/stderr are set, which is going the be the case here. Would it be feasible for Popen.__init__() to automatically protect the inheritable copies it creates, with a lock around that section? We already have the _waitpid_lock for POSIX, so it seems like thread safety is a goal. ---------- components: Library (Lib) messages: 254168 nosy: oconnor663 priority: normal severity: normal status: open title: subprocess.Popen creates inheritable file descriptors on Windows, can leak to other child processes type: security versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 01:51:55 2015 From: report at bugs.python.org (Mark Summerfield) Date: Fri, 06 Nov 2015 06:51:55 +0000 Subject: [issue20607] multiprocessing cx_Freeze windows GUI bug (& easy fixes) In-Reply-To: <1392210007.55.0.703344543531.issue20607@psf.upfronthosting.co.za> Message-ID: <1446792715.48.0.881777579235.issue20607@psf.upfronthosting.co.za> Mark Summerfield added the comment: No, I'm sorry I haven't tried with 3.5; in fact, there doesn't seem to be a cx_Freeze available for 3.5 yet. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 02:15:52 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 06 Nov 2015 07:15:52 +0000 Subject: [issue13153] IDLE crashes when pasting non-BMP unicode char on Py3 In-Reply-To: <1318363292.9.0.682519731008.issue13153@psf.upfronthosting.co.za> Message-ID: <1446794152.31.0.346242659495.issue13153@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: There is no the Snake emoji in my font, I use the Cat Face emoji U+1F431 ? (\xf0\x9f\x90\xb1 in UTF-8, \x3d\xd8\x31\xdc in UTF-16LE). Move cursor or press Backspace. I had needed to press Left 2 times to move cursor to the begin of the line, press Right 4 times to move cursor back to the end of line, and press Backspace 4 times to remove all stuff. What is called "Tk doesn't support astral characters". Get the text programmically. >>> text.get('1.0', '1.end') '????' >>> print(ascii(text.get('1.0', '1.end'))) '\xf0\uff9f\uff90\uffb1' On Linux the clipboard uses UTF-8, and this symbol is represented by 4-bytes bytestring b'\xf0\x9f\x90\xb1' (that is why Tk sometimes interpret it as 4 characters). When you request the text content as a Unicode, Tcl fails to decode the string from UTF-8 and falls back to Latin1. Due to other bug it extends the sign of some bytes. When you programmically insert the same string back, it will be encoded to b'\xc3\xb0\xef\xbe\x9f\xef\xbe\x90\xef\xbe\xb1' and displayed as '????'. On Windows the clipboard uses UTF-16LE and you can see different results. The underlying graphical system can support astral characters, but Tk fails to handle them correctly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 02:32:02 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 06 Nov 2015 07:32:02 +0000 Subject: [issue18010] pydoc search chokes on import errors In-Reply-To: <1368896719.35.0.915741072389.issue18010@psf.upfronthosting.co.za> Message-ID: <1446795122.97.0.884714266506.issue18010@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: gui-search.patch LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 02:35:43 2015 From: report at bugs.python.org (Ned Deily) Date: Fri, 06 Nov 2015 07:35:43 +0000 Subject: [issue25531] greenlet header file is missing inside virtualenv In-Reply-To: <1446407383.6.0.829207834021.issue25531@psf.upfronthosting.co.za> Message-ID: <1446795343.99.0.159265620066.issue25531@psf.upfronthosting.co.za> Ned Deily added the comment: I've looked at this some more using variations of Alexy's test case and I now think there are at least two problems here. And both issues have to do with confusion about exactly where a distribution's header files should be installed in venvs (created with the standard library venv) or virtual environments (created with the third-party virtualenv). One, when building an extension module from a venv, py3 Distutils tries to add the path of the venv include directory to the list of include directories supplied to the C compiler front-end. However, build_ext assumes that the include files have been installed in venv/include (Lib/distutils/command/build_ext.py#l157) while install.py uses an "install scheme"-specific location to install headers (Lib/distutils/command/install.py#l22); for unix non-user installs, that may be something like venv/include/python3.5m. This is particularly a problem for a situation like here where the build of an extension module from one distribution, uwsgi, is dependent on the header files for an extension module from a previously installed distribution, greenlet. So, to resolve this, it seems like build_ext needs to be smarter about the include path for venvs. There should also be test case(s) to ensure that install_headers and build_ext are using the same paths in all relevant environments, e.g. venv, non-venv, user install, Windows, etc. But even if that is fixed, there is another issue. It appears pip uses yet another location for installing distribution header files in virtualenvs and venvs: venv/include/site/python3.5. So, if pip is used to install the distribution supplying the include files, the dependent distribution will still fail to build. From the deleted comments in a recent commit (https://github.com/pypa/pip/commit/882cd358d1abd5e42df6333dddc42f52ab7d6ff2), it appears the reason why pip does this is that virtualenv creates a symlink to the interpreter's global include directory which means that include files from distributions installing to the virtualenv cannot be written to the normal (non-virtualenv) path. It also looks like venv does not create such a symlink but depends on Distutils build_ext to supply paths to both the venv include directory and the global include directory to compilers. I'm not sure what the right solution is here and I certainly may be missing something. In any case, it must be possible for distributions to find the header files from other distributions regardless how they were installed. Since these are all packaging issues, I think the PyPA folks need to take this and decide what action(s) are needed where. ---------- components: +Distutils -Macintosh nosy: +Marcus.Smith, dstufft, eric.araujo, ncoghlan, paul.moore -ronaldoussoren versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 02:39:51 2015 From: report at bugs.python.org (Ned Deily) Date: Fri, 06 Nov 2015 07:39:51 +0000 Subject: [issue25531] greenlet header file is missing inside virtualenv In-Reply-To: <1446407383.6.0.829207834021.issue25531@psf.upfronthosting.co.za> Message-ID: <1446795591.94.0.232155375041.issue25531@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 03:37:07 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 06 Nov 2015 08:37:07 +0000 Subject: [issue25564] IDLE behaves differently than python on `del __builtins__` In-Reply-To: <1446765964.78.0.0240100073004.issue25564@psf.upfronthosting.co.za> Message-ID: <1446799027.47.0.164262255164.issue25564@psf.upfronthosting.co.za> Terry J. Reedy added the comment: We try to have IDLE work the same as Python (and CPython, where relevant), except where differences are intentional or unavoidable. I am trying to eliminate some unintentional avoidable differences in other issues. However, this one is unavoidable given IDLE's basic design. Also, Steven is correct; see https://docs.python.org/3/library/builtins.html#module-builtins IDLE executes user code with "exec(code, self.locals)" (run.py, l.351 in 3.5). https://docs.python.org/3/library/functions.html#exec says "If the globals dictionary does not contain a value for the key __builtins__, a reference to the dictionary of the built-in module builtins is inserted under that key." (Doc issus: From the builtins doc and the Jython example, this seems implementation dependent. Steven, does >>> d = {}; exec('', d); d.keys() dict_keys(['__builtins__']) have this result in Jython?) In the IDLE shell, each statement is exec'ed separately. With two statements, __builtins__ is added back before 'min' , while with one statement, it is not. Editor: Run Module execs the entire file at once. I expected print(min) to fail either way, but it works either way. I verified that globals().keys() lost '__builtins__', so I don't know how __builtins__.min is found. I left this open to consider adding a line to https://docs.python.org/3/library/idle.html#idle-console-differences ---------- assignee: -> terry.reedy components: +Documentation stage: -> needs patch title: IDLE behaves differently that the standard interpreter when someone types `del __builtins__` -> IDLE behaves differently than python on `del __builtins__` type: -> behavior versions: +Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 04:21:56 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 06 Nov 2015 09:21:56 +0000 Subject: [issue24726] OrderedDict has strange behaviour when dict.__setitem__ is used. In-Reply-To: <1437906052.21.0.35165181866.issue24726@psf.upfronthosting.co.za> Message-ID: <20151106092153.123067.76469@psf.io> Roundup Robot added the comment: New changeset 1594c23d8c2f by Serhiy Storchaka in branch '3.5': Issue #24726: Revert setting the value on the dict if https://hg.python.org/cpython/rev/1594c23d8c2f New changeset b391e97ccfe5 by Serhiy Storchaka in branch 'default': Issue #24726: Revert setting the value on the dict if https://hg.python.org/cpython/rev/b391e97ccfe5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 04:21:56 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 06 Nov 2015 09:21:56 +0000 Subject: [issue25558] Use static asserts in C code In-Reply-To: <1446742000.61.0.314081889142.issue25558@psf.upfronthosting.co.za> Message-ID: <20151106092153.123067.90529@psf.io> Roundup Robot added the comment: New changeset ad44d551c13c by Serhiy Storchaka in branch '3.5': Issue #25558: Refactoring OrderedDict iteration. https://hg.python.org/cpython/rev/ad44d551c13c New changeset 51f3547da99c by Serhiy Storchaka in branch 'default': Issue #25558: Refactoring OrderedDict iteration. https://hg.python.org/cpython/rev/51f3547da99c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 04:25:10 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 06 Nov 2015 09:25:10 +0000 Subject: [issue25558] Use static asserts in C code In-Reply-To: <1446742000.61.0.314081889142.issue25558@psf.upfronthosting.co.za> Message-ID: <1446801910.6.0.286120416689.issue25558@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Wrong issue. The correct one is issue24726. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 04:26:39 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 06 Nov 2015 09:26:39 +0000 Subject: [issue25558] Use static asserts in C code In-Reply-To: <1446742000.61.0.314081889142.issue25558@psf.upfronthosting.co.za> Message-ID: <1446801999.63.0.768660525086.issue25558@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Oh, no, the correct one is issue25410. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 04:27:22 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 06 Nov 2015 09:27:22 +0000 Subject: [issue24726] OrderedDict has strange behaviour when dict.__setitem__ is used. In-Reply-To: <1437906052.21.0.35165181866.issue24726@psf.upfronthosting.co.za> Message-ID: <1446802042.8.0.468028453404.issue24726@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Wrong issue. The correct one is issue25410. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 04:59:59 2015 From: report at bugs.python.org (Christian Tanzer) Date: Fri, 06 Nov 2015 09:59:59 +0000 Subject: [issue25545] email parsing docs need to be clear that only ASCII strings are supported In-Reply-To: Your message of "Thu, 05 Nov 2015 17:35:37 +0000" <1446744937.56.0.0775324107287.issue25545@psf.upfronthosting.co.za> Message-ID: Christian Tanzer added the comment: > If you can suggest ways of improving the string support without > breaking existing python3 code that may be using it (most likely > wrongly, but working for them), then I will happily review them. At the moment, I'm mainly interested in having code that runs correctly in both python2.7 and python3. Having the same method behave totally differently in the two versions is what triggered this bug report. Adding new methods won't help with 2.7. > To do what you appear to want, to be able to represent non-ascii as > the equivalent unicode *cannot work*, because email messages may > contain binary data which *cannot* be represented in printable > unicode. I have no problem whatsoever if, and would actually expect that, binary message parts are encoded as necessary for RFS compliance. My beef is with message parts that are text and are naturally represented as unicode not as charset- and transfer-encoded 7-bit strings! I also don't see how such a representation would break existing python3 code but that might just be another example of famous last words. > But, making unicode easier is one big reason python3 exists (the > biggest one, in practice). >From what I have seen up to now, that has failed (spectacularly, in my opinion, if you consider things like unpickling python2-created pickles with binary strings, e.g., datetime instances). Using unicode in python2 worked well enough although there was the problem that one couldn't specify which strings were supposed to be binary. Exactly those strings are a big problem for code that wants to run in both python2 and python3. python3 solves the problem of binary strings, though badly because of the various missing string functions. But there seem to be bugs all over the standard library and in third party modules. That library APIs still haven't settled down yet in python3 is even worse! Maybe python3 would work well if one threw away all existing code and started with completely new code but I don't think that was the intention. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 05:01:06 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 06 Nov 2015 10:01:06 +0000 Subject: [issue25410] Clean up and fix OrderedDict In-Reply-To: <1444896308.75.0.718152743923.issue25410@psf.upfronthosting.co.za> Message-ID: <20151106100103.2124.84930@psf.io> Roundup Robot added the comment: New changeset 45ce4c6b4f36 by Serhiy Storchaka in branch '3.5': Issue #25410: Made testing that od_fast_nodes and dk_entries are in sync more https://hg.python.org/cpython/rev/45ce4c6b4f36 New changeset c16af48153a4 by Serhiy Storchaka in branch 'default': Issue #25410: Made testing that od_fast_nodes and dk_entries are in sync more https://hg.python.org/cpython/rev/c16af48153a4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 05:10:40 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 06 Nov 2015 10:10:40 +0000 Subject: [issue25410] Clean up and fix OrderedDict In-Reply-To: <1444896308.75.0.718152743923.issue25410@psf.upfronthosting.co.za> Message-ID: <1446804640.42.0.569772656704.issue25410@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your review Eric. I made error in commit messages, that is why they are non shown here. odict_revert_setting_on_error.patch and odict_iternext_simpler.patch were committed in 1594c23d8c2f and ad44d551c13c. od_resize_sentinel2 in odict_resize_sentinel.patch was renamed to od_fast_nodes_size. Now I see that this is not enough. It is possible that ma_keys is located on the same place, has the same size, but has different layout for keys with matched hashes. I'm trying to write more reliable checks. ---------- stage: commit review -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 05:18:13 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 06 Nov 2015 10:18:13 +0000 Subject: [issue25462] Avoid repeated hash calculation in C implementation of OrderedDict In-Reply-To: <1445537707.4.0.965290035462.issue25462@psf.upfronthosting.co.za> Message-ID: <1446805093.78.0.124630121753.issue25462@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could you please make a review of this patch Eric? It is moved to separate issue because it is enough large and complex. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 06:23:33 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 06 Nov 2015 11:23:33 +0000 Subject: [issue25462] Avoid repeated hash calculation in C implementation of OrderedDict In-Reply-To: <1445537707.4.0.965290035462.issue25462@psf.upfronthosting.co.za> Message-ID: <1446809013.4.0.140386088007.issue25462@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file40960/odict_knownhash_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 06:38:33 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Fri, 06 Nov 2015 11:38:33 +0000 Subject: [issue21224] BaseHTTPRequestHandler, update the protocol version to http 1.1 by default? In-Reply-To: <1397508232.09.0.0337317788686.issue21224@psf.upfronthosting.co.za> Message-ID: <1446809913.24.0.761822712199.issue21224@psf.upfronthosting.co.za> St?phane Wirtel added the comment: After your remarks, maybe we can close this issue. It's not just a simple modification of a string. Do you know if we want to support the HTTP 1.1 and 2.0 in the future, directly in CPython and not via an external library (gunicorn, ...) What do you think ? we close this issue and open an other with "Support of HTTP 1.1 and 2.0" ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 06:43:35 2015 From: report at bugs.python.org (Jeroen van der Heijden) Date: Fri, 06 Nov 2015 11:43:35 +0000 Subject: [issue25566] asyncio reference cycles after ConnectionResetError Message-ID: <1446810215.4.0.896282956786.issue25566@psf.upfronthosting.co.za> New submission from Jeroen van der Heijden: When a ConnectionResetError occurs, reference cycles are created due to __traceback__. As far as I can see there's no way to prevent this to happen since the event loop exception handler is not called for the following events: BrokenPipeError, ConnectionResetError and ConnectionAbortedError. (selector_events.py, line 579) In this case the connection is probably lost so '_protocol.connection_lost()' will not be called either. (at least we can't rely on this) Maybe it's possible to just call the exception handler? Or, in case we want to ignore these errors set __traceback__ to None? ---------- components: asyncio messages: 254184 nosy: gvanrossum, haypo, joente, yselivanov priority: normal severity: normal status: open title: asyncio reference cycles after ConnectionResetError type: resource usage versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 07:06:37 2015 From: report at bugs.python.org (Deli Zhang) Date: Fri, 06 Nov 2015 12:06:37 +0000 Subject: [issue25553] SMTP.data(msg) function may cause the last CRLF of msg lost if msg is quoted-printable encoding. In-Reply-To: <1446706315.09.0.659513655808.issue25553@psf.upfronthosting.co.za> Message-ID: <1446811597.49.0.734631849813.issue25553@psf.upfronthosting.co.za> Deli Zhang added the comment: I can understand you, while could you please consider below fact: Once our SMTP server module smtpd.py receives the sample mail, it will remove the end-of-data sequence, that makes the "=" become the last char of mail data. I think it's inconsistent to our SMTP client module smtplib.py. If we can just add "." following mail data like postfix, which is influential amd authoritative in SMTP field, that will make things simple and will not make any trouble in reality situation. I just advise this, if you think no need then I can compromise. Thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 07:52:23 2015 From: report at bugs.python.org (Jonas Thiem) Date: Fri, 06 Nov 2015 12:52:23 +0000 Subject: [issue25567] shlex.quote doesn't work on bytestrings Message-ID: <1446814343.82.0.823951892686.issue25567@psf.upfronthosting.co.za> New submission from Jonas Thiem: Demonstration: >>> import shlex >>> shlex.quote(b"abc") Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python3.4/shlex.py", line 285, in quote if _find_unsafe(s) is None: TypeError: can't use a string pattern on a bytes-like object >>> Your question is now probably, why would anyone not want to use unicode strings here? The reason is that for some operations (e.g. file access to some known paths) decoding and encoding from/to any sort of unicode interpretation can be lossy, specifically when the file path on the filesystem has broken/mixed encoding characters. In such a case, the shell command might need to be supplied as bytestring to ensure it is sent exactly as-is so such broken files can still be dealt with, without the Unicode interpretation possibly deforming the path in some bytes. Since shlex.quote seems targeted at shell usage, it should therefore support this. ---------- components: Library (Lib) messages: 254186 nosy: Jonas Thiem, The Compiler priority: normal severity: normal status: open title: shlex.quote doesn't work on bytestrings type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 08:11:26 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 06 Nov 2015 13:11:26 +0000 Subject: [issue25565] subprocess.Popen creates inheritable file descriptors on Windows, can leak to other child processes In-Reply-To: <1446787347.51.0.846654506724.issue25565@psf.upfronthosting.co.za> Message-ID: <1446815486.02.0.662736418259.issue25565@psf.upfronthosting.co.za> R. David Murray added the comment: This looks like a duplicate of issue 24909? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 08:12:41 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Fri, 06 Nov 2015 13:12:41 +0000 Subject: [issue25565] subprocess.Popen creates inheritable file descriptors on Windows, can leak to other child processes In-Reply-To: <1446787347.51.0.846654506724.issue25565@psf.upfronthosting.co.za> Message-ID: <1446815561.69.0.67954574699.issue25565@psf.upfronthosting.co.za> St?phane Wirtel added the comment: yep, maybe, because in the other issue, it's about a race condition. similar. ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 08:20:57 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 06 Nov 2015 13:20:57 +0000 Subject: [issue25545] email parsing docs need to be clear that only ASCII strings are supported In-Reply-To: <1446561810.16.0.921085816129.issue25545@psf.upfronthosting.co.za> Message-ID: <1446816057.3.0.239683147448.issue25545@psf.upfronthosting.co.za> R. David Murray added the comment: Python3 is easier to do unicode in for programs that start with a clear bytes/string split. Yes, porting from python2 has bumps arising from the places where bytes and string are blurred. Yes if we could redo python3 knowing what we know now we could improve matters. But IMO we did a pretty good job given that we *didn't* know what we know now. This is not the forum to discuss such matters further :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 08:31:16 2015 From: report at bugs.python.org (Jack O'Connor) Date: Fri, 06 Nov 2015 13:31:16 +0000 Subject: [issue25565] subprocess.Popen creates inheritable file descriptors on Windows, can leak to other child processes In-Reply-To: <1446787347.51.0.846654506724.issue25565@psf.upfronthosting.co.za> Message-ID: <1446816676.62.0.461360111464.issue25565@psf.upfronthosting.co.za> Jack O'Connor added the comment: Definitely a duplicate, thanks for pointing me to the original. Should I mark it resolved, or let someone from the project do that? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 08:32:48 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 06 Nov 2015 13:32:48 +0000 Subject: [issue892902] problem with pickling newstyle class instances Message-ID: <1446816768.67.0.537901758263.issue892902@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is revised patch that uses different approach to tests. cPickleFastPicklerTests overridden old recursive tests to check that they raises an exception. The patch extends this to new recursive tests. ---------- Added file: http://bugs.python.org/file40961/pickle_recursive-2.7_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 08:38:54 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Fri, 06 Nov 2015 13:38:54 +0000 Subject: [issue25565] subprocess.Popen creates inheritable file descriptors on Windows, can leak to other child processes In-Reply-To: <1446787347.51.0.846654506724.issue25565@psf.upfronthosting.co.za> Message-ID: <1446817134.77.0.329756464573.issue25565@psf.upfronthosting.co.za> St?phane Wirtel added the comment: I don't have the right to close it. can you close it ? Thanks ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 08:40:47 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Fri, 06 Nov 2015 13:40:47 +0000 Subject: [issue22829] Add --prompt option to venv In-Reply-To: <1415555957.14.0.777244809784.issue22829@psf.upfronthosting.co.za> Message-ID: <1446817247.57.0.0543276257053.issue22829@psf.upfronthosting.co.za> St?phane Wirtel added the comment: oops, forgotten to provide the patch :/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 08:44:21 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 06 Nov 2015 13:44:21 +0000 Subject: [issue25553] smtpd strips final carraige return from received message body In-Reply-To: <1446706315.09.0.659513655808.issue25553@psf.upfronthosting.co.za> Message-ID: <1446817461.2.0.886028486521.issue25553@psf.upfronthosting.co.za> R. David Murray added the comment: That does indeed appear to be a bug in smtpd.py. Even if postfix's client mode does do an unconditional add of an extra newline, it is wrong according to the RFC, so I don't think that we'd change smtplib. Especially since we've had no other reports of the current code causing problems (the only problem case you have reported is against smtpd.py, which is a bug in smtpd.py). ---------- resolution: not a bug -> stage: resolved -> needs patch status: closed -> open title: SMTP.data(msg) function may cause the last CRLF of msg lost if msg is quoted-printable encoding. -> smtpd strips final carraige return from received message body versions: +Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 08:44:38 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 06 Nov 2015 13:44:38 +0000 Subject: [issue25553] smtpd strips final carraige return from received message body In-Reply-To: <1446706315.09.0.659513655808.issue25553@psf.upfronthosting.co.za> Message-ID: <1446817478.84.0.76855118714.issue25553@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- components: +email nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 08:51:01 2015 From: report at bugs.python.org (Mouse) Date: Fri, 06 Nov 2015 13:51:01 +0000 Subject: [issue25495] binascii documentation incorrect In-Reply-To: <1445987417.55.0.122139453671.issue25495@psf.upfronthosting.co.za> Message-ID: <1446817861.07.0.713138097141.issue25495@psf.upfronthosting.co.za> Mouse added the comment: > my patch should be valid for 3.5 also. > The relevant wording is identical to 2.7. OK. > I have resisted removing the magic number 57 for a couple > of reasons. Reading existing code that uses this number may > be harder. You expect to see "existing code that uses this number" in Python-3.5+? Interesting... (Care to point me at a couple of samples of such "existing" Python-3 code?) And you expect that the main info source for understanding the reason behind that "57" (assuming this function is invoked that way, as opposed to splitting the output :) would be the doc for this function, rather than the main program, or RFC 2045, or...? Fine. > It helps explain how the function was originally to be used, > and why the newline is appended. Pardon me, but why do you think anybody would care...? There are tons of functions, old and new, with more new ones popping up fast enough. I'd really envy a person who has time to enjoy history of one minuscule function of an old (albeit still useful :) library. OK. You think a history of this function should be documented - fine. I don't need it (and don't think anybody else wants to read it either), but it's not my doc or my decision. Just get the darn bug fixed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 08:58:12 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 06 Nov 2015 13:58:12 +0000 Subject: [issue25567] shlex.quote doesn't work on bytestrings In-Reply-To: <1446814343.82.0.823951892686.issue25567@psf.upfronthosting.co.za> Message-ID: <1446818292.72.0.196327303662.issue25567@psf.upfronthosting.co.za> R. David Murray added the comment: I think that this is a reasonable request, and probably applies to the whole shlex module, although less strongly. You could use the surrogateescape hack to work around the problem: shlex.quote(mydata.encode('ascii', 'surrogateescape')).decode('ascii', 'surrogateescape) That might be the only practical way to handle bytes input to the shlex parser, if we do also want to tackle that. Note that it is already the case that os module functions that retrn filenames and stdin/stdout use surrogateescape, so a naive program may actually work with binary filenames (which is why the handler is used in those contexts). ---------- keywords: +easy nosy: +r.david.murray stage: -> needs patch type: behavior -> enhancement versions: +Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 08:59:48 2015 From: report at bugs.python.org (eryksun) Date: Fri, 06 Nov 2015 13:59:48 +0000 Subject: [issue25565] subprocess.Popen creates inheritable file descriptors on Windows, can leak to other child processes In-Reply-To: <1446787347.51.0.846654506724.issue25565@psf.upfronthosting.co.za> Message-ID: <1446818388.23.0.0428442728657.issue25565@psf.upfronthosting.co.za> Changes by eryksun : ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Windows: subprocess.Popen: race condition for leaking inheritable handles _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 09:13:08 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Fri, 06 Nov 2015 14:13:08 +0000 Subject: [issue22829] Add --prompt option to venv In-Reply-To: <1415555957.14.0.777244809784.issue22829@psf.upfronthosting.co.za> Message-ID: <1446819188.32.0.738113619608.issue22829@psf.upfronthosting.co.za> St?phane Wirtel added the comment: Hi @berker.peksag Please, could you review this patch, I have followed your remarks and adjust the patch. Thank you ---------- Added file: http://bugs.python.org/file40962/venv-prompt-argument-3_6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 09:56:13 2015 From: report at bugs.python.org (nicolas33) Date: Fri, 06 Nov 2015 14:56:13 +0000 Subject: [issue25568] typing backport: AttributeError: 'module' object has no attribute 'GeneratorType' Message-ID: <1446821773.07.0.324057164116.issue25568@psf.upfronthosting.co.za> New submission from nicolas33: $ pip3 install typing $ python3 >>> import typing Traceback (most recent call last): File "", line 1, in File "/home/nicolas/.local/lib64/python3.4/site-packages/typing.py", line 1449, in _G_base = types.GeneratorType AttributeError: 'module' object has no attribute 'GeneratorType' >>> ---------- messages: 254198 nosy: nicolas33 priority: normal severity: normal status: open title: typing backport: AttributeError: 'module' object has no attribute 'GeneratorType' type: crash versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 09:59:18 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Fri, 06 Nov 2015 14:59:18 +0000 Subject: [issue22829] Add --prompt option to venv In-Reply-To: <1415555957.14.0.777244809784.issue22829@psf.upfronthosting.co.za> Message-ID: <1446821958.79.0.917257588282.issue22829@psf.upfronthosting.co.za> Changes by St?phane Wirtel : ---------- versions: +Python 3.6 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 10:08:17 2015 From: report at bugs.python.org (nicolas33) Date: Fri, 06 Nov 2015 15:08:17 +0000 Subject: [issue25568] typing backport: AttributeError: 'module' object has no attribute 'GeneratorType' In-Reply-To: <1446821773.07.0.324057164116.issue25568@psf.upfronthosting.co.za> Message-ID: <1446822497.11.0.401271382077.issue25568@psf.upfronthosting.co.za> nicolas33 added the comment: My bad. This happens while running on Python3.3 (while pip3 installed module using python3.4). ---------- resolution: -> works for me status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 10:11:05 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 06 Nov 2015 15:11:05 +0000 Subject: [issue25568] typing backport: AttributeError: 'module' object has no attribute 'GeneratorType' In-Reply-To: <1446821773.07.0.324057164116.issue25568@psf.upfronthosting.co.za> Message-ID: <1446822665.45.0.646248711699.issue25568@psf.upfronthosting.co.za> STINNER Victor added the comment: https://github.com/JukkaL/typing/ looks to be the upstream project for the third party "typing" module. See https://github.com/JukkaL/typing/issues/46 ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 10:36:57 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 06 Nov 2015 15:36:57 +0000 Subject: [issue25558] Use static asserts in C code In-Reply-To: <1446742000.61.0.314081889142.issue25558@psf.upfronthosting.co.za> Message-ID: <1446824217.13.0.320221788905.issue25558@psf.upfronthosting.co.za> STINNER Victor added the comment: use_Py_BUILD_ASSERT_EXPR.patch looks good to me. But you should revert the change on decimal, as asked by Stefan, and I suggested to move an assertion inside the related function (see my comment on Rietveld). """ A library can follow the example in the comment. #define foo_to_char(foo) \ ((char *)(foo) \ + Py_BUILD_ASSERT_EXPR(offsetof(struct foo, string) == 0)) """ Hum ok, I know understand the "_EXPR" suffix of the macro name. Maybe it's worth to add a new #define Py_BUILD_ASSERT(expr) (void)Py_BUILD_ASSERT_EXPR(expr)" macro? By the way, I don't know what happens if you pass a variable to Py_BUILD_ASSERT_EXPR() rather than a constant. Maybe we could use __builtin_constant_p() on GCC? Maybe it's overcomplexicated :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 11:02:35 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 06 Nov 2015 16:02:35 +0000 Subject: [issue25555] Fix parser and AST: fill lineno and col_offset when compiling AST from Python objects In-Reply-To: <1446716524.88.0.975797398415.issue25555@psf.upfronthosting.co.za> Message-ID: <20151106160232.24918.75323@psf.io> Roundup Robot added the comment: New changeset 54d4290f0ec6 by Victor Stinner in branch 'default': Issue #25555: Fix parser and AST: fill lineno and col_offset of "arg" node when https://hg.python.org/cpython/rev/54d4290f0ec6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 11:05:58 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 06 Nov 2015 16:05:58 +0000 Subject: [issue25555] Fix parser and AST: fill lineno and col_offset when compiling AST from Python objects In-Reply-To: <1446716524.88.0.975797398415.issue25555@psf.upfronthosting.co.za> Message-ID: <1446825958.27.0.896140722512.issue25555@psf.upfronthosting.co.za> STINNER Victor added the comment: > 3. How can I test it? currently, everything is fine. Sorry, I don't know how to test it. To write my fix, I had to modify the compile() builtin function to be able to compile Python to AST, and then AST to Python. But without this fix I don't know how to test. I tried to revert the AST patch on my FAT Python to try to find which part of the code fails without the fix, but FAT Python doesn't compile anymore. I reverted the revert, and it still doesn't work!? For this bug, sorry, you have to trust me :-( I applied the fix to Python 3.6. I will wait a bit for buildbots before backporting to 3.5. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 11:07:51 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Fri, 06 Nov 2015 16:07:51 +0000 Subject: [issue25555] Fix parser and AST: fill lineno and col_offset when compiling AST from Python objects In-Reply-To: <1446716524.88.0.975797398415.issue25555@psf.upfronthosting.co.za> Message-ID: <1446826071.27.0.161654269836.issue25555@psf.upfronthosting.co.za> St?phane Wirtel added the comment: I trust you, I have reviewed the source code and it seems to be right. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 12:27:13 2015 From: report at bugs.python.org (Kevin Phillips) Date: Fri, 06 Nov 2015 17:27:13 +0000 Subject: [issue22919] Update PCBuild for VS 2015 In-Reply-To: <1416692407.19.0.899325125222.issue22919@psf.upfronthosting.co.za> Message-ID: <1446830833.76.0.0912213485865.issue22919@psf.upfronthosting.co.za> Kevin Phillips added the comment: This change has the adverse side effect of requiring users of Python 3.5 to use the Visual Studio 2015 runtime library. Further, as is documented on Microsoft's website, the minimum system requirements for installing and running this runtime is Windows 7 SP1 or newer. As a result, adopting this new compiler for the Python runtime prevents users of operating systems older than this from using this version. Even users with Windows 7 pre service pack are unable to use it. Based on a quick review of the comment thread here, the choice for adopting the 2015 compiler was relatively arbitrary and thus an older version, say 2013 for example, could have been used instead and older operation systems would still be supported with little to no impact on Python. While this is unfortunate to say the least, what makes matters worse is there appears to be little to no information on the Python.org website indicating that the minimum system requirements have now been affected in this way. Also, for users attempting to install v3.5 on a system older than this are presented with a cryptic error message basically just saying that "some unknown error has occurred", leaving them scratching their head trying to figure out what's wrong. Seeing as how you can't go back in time and fix this in 3.5.0, I am hoping that at the very least you could add some information about this to some obvious location on the main Python.org website, and maybe consider updating the installation for future 3.5.x releases such that a check is done to see if the operating system meets these new minimum requirements and present the user with some helpful information that would lead them to a resolution. ---------- nosy: +Kevin.Phillips _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 13:08:00 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 06 Nov 2015 18:08:00 +0000 Subject: [issue22919] Update PCBuild for VS 2015 In-Reply-To: <1416692407.19.0.899325125222.issue22919@psf.upfronthosting.co.za> Message-ID: <1446833280.53.0.625108741658.issue22919@psf.upfronthosting.co.za> Steve Dower added the comment: The check is already added and will be in 3.5.1. Changes to the python.org website should be suggested on https://github.com/python/pythondotorg (but I agree it could be more clear on the main site - the rule that we only support the same versions of Windows that Microsoft supports is not very well known, unfortunately). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 14:18:56 2015 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Fri, 06 Nov 2015 19:18:56 +0000 Subject: [issue21247] test_asyncio: test_subprocess_send_signal hangs on Fedora builders In-Reply-To: <1397597632.61.0.772376521638.issue21247@psf.upfronthosting.co.za> Message-ID: <1446837536.84.0.929550844521.issue21247@psf.upfronthosting.co.za> ???? ????????? added the comment: Bug still reproduced. Jenkins running from init.d use /usr/bin/daemon. This mean SIGHUP will be in SIG_IGN state. Since echo.py does not setup sighup handler, sighup will be equivalent of SIGKILL. So, why not to use, say, SIGTERM instead? After such change all tests passed. If not, signal handling tests should reset signal handling to SIG_DFL. Please reopen ---------- nosy: +mmarkk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 14:38:27 2015 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 06 Nov 2015 19:38:27 +0000 Subject: [issue25177] OverflowError in statistics.mean when summing large floats In-Reply-To: <1442662840.23.0.781753910755.issue25177@psf.upfronthosting.co.za> Message-ID: <1446838707.46.0.0265991487122.issue25177@psf.upfronthosting.co.za> Mark Dickinson added the comment: I can reproduce here (OS X 10.9, Python 3.5), exactly as described in the original post. Python 3.5.0 (default, Sep 22 2015, 18:26:54) [GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import statistics >>> statistics.mean([8.988465674311579e+307, 8.98846567431158e+307]) Traceback (most recent call last): File "", line 1, in File "/opt/local/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/statistics.py", line 293, in mean return _sum(data)/n File "/opt/local/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/statistics.py", line 184, in _sum return T(total) File "/opt/local/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/numbers.py", line 291, in __float__ return self.numerator / self.denominator OverflowError: integer division result too large for a float ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 14:40:54 2015 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 06 Nov 2015 19:40:54 +0000 Subject: [issue25177] OverflowError in statistics.mean when summing large floats In-Reply-To: <1442662840.23.0.781753910755.issue25177@psf.upfronthosting.co.za> Message-ID: <1446838854.84.0.565387334655.issue25177@psf.upfronthosting.co.za> Mark Dickinson added the comment: Note that the two input values given in the original report are not the same: [8.988465674311579e+307, 8.98846567431158e+307] != [8.988465674311579e+307] * 2. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 15:08:01 2015 From: report at bugs.python.org (Alex Gaynor) Date: Fri, 06 Nov 2015 20:08:01 +0000 Subject: [issue25569] Memory leak in SSLSocket.getpeercert() Message-ID: <1446840481.06.0.811345685129.issue25569@psf.upfronthosting.co.za> New submission from Alex Gaynor: Run the following code: import socket import ssl import sys def main(): ctx = ssl.create_default_context() s = socket.create_connection(('www.bing.com', 443)) s = ctx.wrap_socket(s, server_hostname='www.bing.com') while True: s.getpeercert() sys.stderr.write('.') sys.stderr.flush() if __name__ == '__main__': main() and observe memory usage, you'll see it increases by a MB/s or so. ---------- messages: 254210 nosy: alex priority: normal severity: normal status: open title: Memory leak in SSLSocket.getpeercert() versions: Python 2.7, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 15:08:08 2015 From: report at bugs.python.org (Alex Gaynor) Date: Fri, 06 Nov 2015 20:08:08 +0000 Subject: [issue25569] Memory leak in SSLSocket.getpeercert() In-Reply-To: <1446840481.06.0.811345685129.issue25569@psf.upfronthosting.co.za> Message-ID: <1446840488.63.0.0602800507651.issue25569@psf.upfronthosting.co.za> Changes by Alex Gaynor : ---------- nosy: +christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 15:09:54 2015 From: report at bugs.python.org (Alex Gaynor) Date: Fri, 06 Nov 2015 20:09:54 +0000 Subject: [issue25569] Memory leak in SSLSocket.getpeercert() In-Reply-To: <1446840481.06.0.811345685129.issue25569@psf.upfronthosting.co.za> Message-ID: <1446840594.92.0.472476883126.issue25569@psf.upfronthosting.co.za> Alex Gaynor added the comment: A probably source of the leak is here: https://github.com/python/cpython/blob/master/Modules/_ssl.c#L1073-L1076 `dps` is never freed. (This is with OpenSSL 0.9.8zg) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 15:30:33 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Fri, 06 Nov 2015 20:30:33 +0000 Subject: [issue25569] Memory leak in SSLSocket.getpeercert() In-Reply-To: <1446840481.06.0.811345685129.issue25569@psf.upfronthosting.co.za> Message-ID: <1446841833.38.0.789032764755.issue25569@psf.upfronthosting.co.za> St?phane Wirtel added the comment: Hi Alex, not sure, but I think the right function to free the memory is AUTHORITY_INFO_ACCESS_free(dps) I will provide a patch for a review asap ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 15:38:03 2015 From: report at bugs.python.org (Alex Gaynor) Date: Fri, 06 Nov 2015 20:38:03 +0000 Subject: [issue25569] Memory leak in SSLSocket.getpeercert() In-Reply-To: <1446840481.06.0.811345685129.issue25569@psf.upfronthosting.co.za> Message-ID: <1446842283.96.0.517953833707.issue25569@psf.upfronthosting.co.za> Alex Gaynor added the comment: I think you want sk_DIST_POINT_free actually. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 15:39:12 2015 From: report at bugs.python.org (Christian Rickert) Date: Fri, 06 Nov 2015 20:39:12 +0000 Subject: [issue25570] urllib.request > Request.add_header("abcd", "efgh") fails with character ":" in first parameter string Message-ID: <1446842352.31.0.869437789925.issue25570@psf.upfronthosting.co.za> New submission from Christian Rickert: A piece of software stopped working after the update from Python 3.4.x to 3.5 (both Linux and Windows). I found the cause in the Request.add_header("abcd","efgh") function: If the first parameter string "abcd" contains a colon (":") character, a ValueError is raised and the execution stops. This is an example code: >>> import urllib.request >>> import urllib.parse >>> data = urllib.parse.urlencode({'spam': 1, 'eggs': 2, 'bacon': 0}) >>> data = data.encode('utf-8') >>> request = urllib.request.Request("http://requestb.in/xrbl82xr") >>> # adding charset parameter to the Content-Type header. >>> request.add_header("Content-Type:","application/x-www-form-urlencoded;charset=utf-8") >>> with urllib.request.urlopen(request, data) as f: ... print(f.read().decode('utf-8')) ... This is the error: Traceback (most recent call last): File "C:\Users\user\Desktop\example.py", line 9, in with urllib.request.urlopen(request, data) as f: File "C:\python\lib\urllib\request.py", line 162, in urlopen return opener.open(url, data, timeout) File "C:\python\lib\urllib\request.py", line 465, in open response = self._open(req, data) File "C:\python\lib\urllib\request.py", line 483, in _open '_open', req) File "C:\python\lib\urllib\request.py", line 443, in _call_chain result = func(*args) File "C:\python\lib\urllib\request.py", line 1268, in http_open return self.do_open(http.client.HTTPConnection, req) File "C:\python\lib\urllib\request.py", line 1240, in do_open h.request(req.get_method(), req.selector, req.data, headers) File "C:\python\lib\http\client.py", line 1083, in request self._send_request(method, url, body, headers) File "C:\python\lib\http\client.py", line 1123, in _send_request self.putheader(hdr, value) File "C:\python\lib\http\client.py", line 1050, in putheader raise ValueError('Invalid header name %r' % (header,)) ValueError: Invalid header name b'Content-Type:' Steps to reproduce: Add a colon character anywhere into the first parameter of the Request.add_header() function and execute the code using Python 3.5.x. ---------- components: Library (Lib) messages: 254214 nosy: crickert priority: normal severity: normal status: open title: urllib.request > Request.add_header("abcd","efgh") fails with character ":" in first parameter string type: crash versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 15:47:36 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Fri, 06 Nov 2015 20:47:36 +0000 Subject: [issue25569] Memory leak in SSLSocket.getpeercert() In-Reply-To: <1446840481.06.0.811345685129.issue25569@psf.upfronthosting.co.za> Message-ID: <1446842856.38.0.3126345945.issue25569@psf.upfronthosting.co.za> St?phane Wirtel added the comment: Maybe you are right, I didn't see that this function returns a pointer in function of the parameter. sorry. Could you try with this patch, really sorry but my internet connection is really slow and I have a problem with the _ssl module on my laptop (problem with the compilation and the dependencies because I am on OSX). Thank you ---------- keywords: +patch Added file: http://bugs.python.org/file40963/issue25569.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 15:49:06 2015 From: report at bugs.python.org (Christian Rickert) Date: Fri, 06 Nov 2015 20:49:06 +0000 Subject: [issue25570] urllib.request > Request.add_header("abcd", "efgh") fails with character ":" in first parameter string In-Reply-To: <1446842352.31.0.869437789925.issue25570@psf.upfronthosting.co.za> Message-ID: <1446842946.26.0.466488190963.issue25570@psf.upfronthosting.co.za> Christian Rickert added the comment: The URL "http://requestb.in/xrbl82xr" is invalid, you'll get a "urllib.error.HTTPError: HTTP Error 404: NOT FOUND" error." Instead, please use "http://www.example.com" to confirm. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 16:08:46 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 06 Nov 2015 21:08:46 +0000 Subject: [issue25570] urllib.request > Request.add_header("abcd", "efgh") fails with character ":" in first parameter string In-Reply-To: <1446842352.31.0.869437789925.issue25570@psf.upfronthosting.co.za> Message-ID: <1446844126.19.0.0844330714913.issue25570@psf.upfronthosting.co.za> R. David Murray added the comment: This behavior change was part of a security fix, and will appear in the next version of 3.4 as well. See issue 22928. Header names may not contain colons, the colon separator is added when the header is rendered. Detecting and rejecting them guards against header injection attacks. However, that fix was done in httplib. I think it would also be worthwhile to fix add_header so that it rejects invalid header components when called, instead of only having the check done later in httplib, at a point distant from where the problem occurred. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 16:13:46 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Fri, 06 Nov 2015 21:13:46 +0000 Subject: [issue25571] Improve the lltrace feature with the Py_Debug mode Message-ID: <1446844426.01.0.118649403374.issue25571@psf.upfronthosting.co.za> New submission from St?phane Wirtel: When we use the Py_Debug flag for the compilation, we can see the Bytecodes and the opcode arguments. Here is a small patch, it will show the label of the opcode in the ceval.c file. ---------- messages: 254218 nosy: matrixise priority: normal severity: normal status: open title: Improve the lltrace feature with the Py_Debug mode _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 16:14:25 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Fri, 06 Nov 2015 21:14:25 +0000 Subject: [issue25571] Improve the lltrace feature with the Py_Debug mode In-Reply-To: <1446844426.01.0.118649403374.issue25571@psf.upfronthosting.co.za> Message-ID: <1446844465.0.0.889877591061.issue25571@psf.upfronthosting.co.za> St?phane Wirtel added the comment: Here is my patch with the improvement. ---------- keywords: +patch Added file: http://bugs.python.org/file40964/issue25571.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 16:16:34 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Fri, 06 Nov 2015 21:16:34 +0000 Subject: [issue11822] Improve disassembly to show embedded code objects In-Reply-To: <1302467152.39.0.854888976189.issue11822@psf.upfronthosting.co.za> Message-ID: <1446844594.71.0.353681469651.issue11822@psf.upfronthosting.co.za> St?phane Wirtel added the comment: Hi all, For this feature, I have an other output: stephane at sg1 /tmp> python3 dump_bytecode.py -------- 3 0 LOAD_BUILD_CLASS 1 LOAD_CONST 0 (", line 3>) 4 LOAD_CONST 1 ('User') 7 MAKE_FUNCTION 0 10 LOAD_CONST 1 ('User') 13 CALL_FUNCTION 2 (2 positional, 0 keyword pair) 16 STORE_NAME 0 (User) 8 19 LOAD_NAME 0 (User) 22 LOAD_CONST 2 ('user') 25 LOAD_CONST 3 ('password') 28 CALL_FUNCTION 2 (2 positional, 0 keyword pair) 31 STORE_NAME 1 (user) 34 LOAD_CONST 4 (None) 37 RETURN_VALUE .User ------------- 3 0 LOAD_NAME 0 (__name__) 3 STORE_NAME 1 (__module__) 6 LOAD_CONST 0 ('User') 9 STORE_NAME 2 (__qualname__) 4 12 LOAD_CONST 1 (", line 4>) 15 LOAD_CONST 2 ('User.__init__') 18 MAKE_FUNCTION 0 21 STORE_NAME 3 (__init__) 24 LOAD_CONST 3 (None) 27 RETURN_VALUE .User.__init__ ---------------------- 5 0 LOAD_FAST 1 (email) 3 LOAD_FAST 0 (self) 6 STORE_ATTR 0 (email) 6 9 LOAD_FAST 2 (password) 12 LOAD_FAST 0 (self) 15 STORE_ATTR 1 (password) 18 LOAD_CONST 0 (None) 21 RETURN_VALUE ---------- nosy: +matrixise versions: +Python 3.6 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 16:26:06 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 06 Nov 2015 21:26:06 +0000 Subject: [issue25570] urllib.request > Request.add_header("abcd", "efgh") fails with character ":" in first parameter string In-Reply-To: <1446842352.31.0.869437789925.issue25570@psf.upfronthosting.co.za> Message-ID: <1446845166.37.0.632978708343.issue25570@psf.upfronthosting.co.za> R. David Murray added the comment: By the way, that your application worked before was pure luck, here is what httplib sends in 3.4 given your test program: POST / HTTP/1.1 Accept-Encoding: identity User-Agent: Python-urllib/3.4 Connection: close Host: xxxx.xxxx.com:9999 Content-Length: 21 Content-Type:: application/x-www-form-urlencoded;charset=utf-8 Content-Type: application/x-www-form-urlencoded ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 16:29:59 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Fri, 06 Nov 2015 21:29:59 +0000 Subject: [issue25572] _ssl doesn't build on OSX 10.11 Message-ID: <1446845399.36.0.0648529481801.issue25572@psf.upfronthosting.co.za> New submission from St?phane Wirtel: On OSX 10.11, if you don't use Homebrew or MacPorts, the _ssl module is not built with Makefile. Homebrew supports OpenSSL and LibreSSL, but OpenSSL is in /usr/local/opt/openssl and not in /usr/local/ssl (see setup.py) So, the next point, I am not sure, but the headers of OpenSSL has not provided with OSX 10.11 ---------- messages: 254222 nosy: matrixise priority: normal severity: normal status: open title: _ssl doesn't build on OSX 10.11 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 16:30:20 2015 From: report at bugs.python.org (Harsh Patel) Date: Fri, 06 Nov 2015 21:30:20 +0000 Subject: [issue11907] SysLogHandler can't send long messages In-Reply-To: <1303480338.6.0.255798757577.issue11907@psf.upfronthosting.co.za> Message-ID: <1446845420.6.0.836911822408.issue11907@psf.upfronthosting.co.za> Harsh Patel added the comment: I know this has been closed as "Not a bug" but it would have been convenient if the message was broken down into multiple packets and transmitted, should it exceed the packet limit. Raising an exception [Errno 40 or Errno 90] or silently ignoring the packet (by setting logging.raiseExceptions to False) doesn't help much in terms of robustness and reliability. I eventually ended up extending these Handler classes and overriding the send to accomplish breaking messages into multiple parts ---------- nosy: +Harsh Patel _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 16:31:46 2015 From: report at bugs.python.org (Zachary Ware) Date: Fri, 06 Nov 2015 21:31:46 +0000 Subject: [issue25572] _ssl doesn't build on OSX 10.11 In-Reply-To: <1446845399.36.0.0648529481801.issue25572@psf.upfronthosting.co.za> Message-ID: <1446845506.42.0.992991126951.issue25572@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- components: +Macintosh nosy: +ned.deily, ronaldoussoren, zach.ware stage: -> needs patch versions: +Python 2.7, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 16:34:26 2015 From: report at bugs.python.org (Alexandre Macabies) Date: Fri, 06 Nov 2015 21:34:26 +0000 Subject: [issue25573] traceback documentation example is lying about FrameSummary repr() Message-ID: <1446845666.11.0.0803768990935.issue25573@psf.upfronthosting.co.za> New submission from Alexandre Macabies: https://docs.python.org/3.5/library/traceback.html#traceback-examples See second code sample and its sample output. According to the docs, the call: print(repr(traceback.extract_tb(exc_traceback))) is supposed to print something that looks like an array with only strings; that is what the doc sample output states: [('', 10, '', 'lumberjack()'), But actually, in 3.5+, this call outputs the repr() of a list of FrameSummary instances that do not go further in repr()esenting their state: [, line 10 in >, By looking at the docs I thought I was able to get a nice string representation of a FrameSummary. I actually have to format it myself. It should be reflected in the doc sample output. ---------- assignee: docs at python components: Documentation messages: 254224 nosy: Alexandre Macabies, docs at python priority: normal severity: normal status: open title: traceback documentation example is lying about FrameSummary repr() versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 16:34:38 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 06 Nov 2015 21:34:38 +0000 Subject: [issue25388] tokenizer crash/misbehavior -- heap use-after-free In-Reply-To: <1444706115.92.0.283351483962.issue25388@psf.upfronthosting.co.za> Message-ID: <1446845678.91.0.520538985619.issue25388@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yes, there is a bug. When decoding_fgets() encounter non-UTF-8 bytes, it fails and free input buffer in error_ret(). But since tok->cur != tok->inp, next call of tok_nextc() reads freed memory. if (tok->cur != tok->inp) { return Py_CHARMASK(*tok->cur++); /* Fast path */ } If Python is not crashed here, new buffer is allocated and assigned to tok->buf, then PyTokenizer_Get returns error, parsetok() calculates the position of the error err_ret->offset = (int)(tok->cur - tok->buf); but tok->cur points inside old freed buffer, and the offset becomes too large integer. err_input() tries to decode the part of the string before error with the "replace" error handler, but since the position was wrongly calculated, it reads out of allocated memory. Proposed patch fixes the issue. It sets tok->done and pointers in case of decoding error, so they now are in consistent state. It also removes some duplicated or dead code. ---------- stage: -> patch review Added file: http://bugs.python.org/file40965/issue25388.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 16:35:16 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 06 Nov 2015 21:35:16 +0000 Subject: [issue11907] SysLogHandler can't send long messages In-Reply-To: <1303480338.6.0.255798757577.issue11907@psf.upfronthosting.co.za> Message-ID: <1446845716.23.0.12678297546.issue11907@psf.upfronthosting.co.za> R. David Murray added the comment: Writing your own handler is what Vinay recommended. Is it even possible to determine the maximum message size? If we can't do that reliably, then the best we can do is recommend writing your own exception handler using local knowledge. If it can be determined reliably, you could open a new issue with that feature request. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 16:43:01 2015 From: report at bugs.python.org (Christian Rickert) Date: Fri, 06 Nov 2015 21:43:01 +0000 Subject: [issue25570] urllib.request > Request.add_header("abcd", "efgh") fails with character ":" in first parameter string In-Reply-To: <1446842352.31.0.869437789925.issue25570@psf.upfronthosting.co.za> Message-ID: <1446846181.27.0.773082392904.issue25570@psf.upfronthosting.co.za> Christian Rickert added the comment: Hi David, Thanks for looking into this. IMHO it would be very helpful for code debugging, if "add_header" rejects invalid header arguments ad hoc. As an alternative, the documentation I used for the implementation [https://docs.python.org/3.6/library/urllib.request.html] could be updated. "Content-Type:: application/x-www-form-urlencoded;charset=utf-8" A scope resolution operator thingy in the header? - What could possibly go wrong? ^^ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 16:43:40 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 06 Nov 2015 21:43:40 +0000 Subject: [issue25520] unittest load_tests protocol not working as documented In-Reply-To: <1446239702.03.0.964231995407.issue25520@psf.upfronthosting.co.za> Message-ID: <1446846220.97.0.307547880621.issue25520@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: +ezio.melotti, michael.foord, rbcollins _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 16:43:54 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 06 Nov 2015 21:43:54 +0000 Subject: [issue25573] FrameSummary repr() does not support previously working uses of repr in traceback module In-Reply-To: <1446845666.11.0.0803768990935.issue25573@psf.upfronthosting.co.za> Message-ID: <1446846234.16.0.352664731123.issue25573@psf.upfronthosting.co.za> R. David Murray added the comment: IMO, that is neither a lie nor a doc bug, it is a bug in the new traceback features that were added in 3.5. ---------- assignee: docs at python -> keywords: +3.5regression nosy: +r.david.murray, rbcollins stage: -> needs patch title: traceback documentation example is lying about FrameSummary repr() -> FrameSummary repr() does not support previously working uses of repr in traceback module _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 16:44:16 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Fri, 06 Nov 2015 21:44:16 +0000 Subject: [issue11907] SysLogHandler can't send long messages In-Reply-To: <1303480338.6.0.255798757577.issue11907@psf.upfronthosting.co.za> Message-ID: <1446846256.7.0.931047102184.issue11907@psf.upfronthosting.co.za> St?phane Wirtel added the comment: This issue will stay closed, BUT I propose you to create a new issue with a new title: Feature: Support message over 1024 bytes for the SysLogHandler. and propose a patch for this feature. ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 16:45:41 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Fri, 06 Nov 2015 21:45:41 +0000 Subject: [issue25573] FrameSummary repr() does not support previously working uses of repr in traceback module In-Reply-To: <1446845666.11.0.0803768990935.issue25573@psf.upfronthosting.co.za> Message-ID: <1446846341.76.0.776011993007.issue25573@psf.upfronthosting.co.za> St?phane Wirtel added the comment: Could you check with Python 3.4 ? ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 16:48:49 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 06 Nov 2015 21:48:49 +0000 Subject: [issue25527] Invalid (... and confusing) warning raised by 2to3 regarding repeat In-Reply-To: <1446371398.34.0.43007110205.issue25527@psf.upfronthosting.co.za> Message-ID: <1446846529.82.0.197125664778.issue25527@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 16:49:37 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 06 Nov 2015 21:49:37 +0000 Subject: [issue25528] Attempt to further increase test coverage of calendar module In-Reply-To: <1446371863.84.0.773420016182.issue25528@psf.upfronthosting.co.za> Message-ID: <1446846577.36.0.59164933978.issue25528@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 16:50:46 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 06 Nov 2015 21:50:46 +0000 Subject: [issue25570] urllib.request > Request.add_header("abcd", "efgh") fails with character ":" in first parameter string In-Reply-To: <1446842352.31.0.869437789925.issue25570@psf.upfronthosting.co.za> Message-ID: <1446846646.93.0.983589165628.issue25570@psf.upfronthosting.co.za> R. David Murray added the comment: I don't think the docs need updating if the ValueError is raised by add_header. The 'key' in the docs is the header name, as examples in other sections of that doc make clear. Granted you won't necessarily see that if you just read the add_header entry, but we can't explain every detail in every entry. Hmm. Perhaps an example could be added, though. ---------- keywords: +easy stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 16:53:38 2015 From: report at bugs.python.org (Tim Smith) Date: Fri, 06 Nov 2015 21:53:38 +0000 Subject: [issue25572] _ssl doesn't build on OSX 10.11 In-Reply-To: <1446845399.36.0.0648529481801.issue25572@psf.upfronthosting.co.za> Message-ID: <1446846818.16.0.869370256743.issue25572@psf.upfronthosting.co.za> Changes by Tim Smith : ---------- nosy: +tdsmith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 16:56:28 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 06 Nov 2015 21:56:28 +0000 Subject: [issue25548] Show the address in the repr for class objects In-Reply-To: <1446576011.58.0.372024983976.issue25548@psf.upfronthosting.co.za> Message-ID: <1446846988.13.0.116583680949.issue25548@psf.upfronthosting.co.za> Terry J. Reedy added the comment: In 3.x, old style classes are gone, so you get a new style class with or without '(object)'. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 17:03:43 2015 From: report at bugs.python.org (Ned Deily) Date: Fri, 06 Nov 2015 22:03:43 +0000 Subject: [issue25572] _ssl doesn't build on OS X 10.11 without third-party ssl headers In-Reply-To: <1446845399.36.0.0648529481801.issue25572@psf.upfronthosting.co.za> Message-ID: <1446847423.28.0.924512604869.issue25572@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- assignee: -> ned.deily title: _ssl doesn't build on OSX 10.11 -> _ssl doesn't build on OS X 10.11 without third-party ssl headers _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 17:08:39 2015 From: report at bugs.python.org (leewz) Date: Fri, 06 Nov 2015 22:08:39 +0000 Subject: [issue25428] Have `datetime` understand integer arguments for timezones In-Reply-To: <1445045654.46.0.202441860249.issue25428@psf.upfronthosting.co.za> Message-ID: <1446847719.84.0.445268839513.issue25428@psf.upfronthosting.co.za> leewz added the comment: Thanks. Will visit them. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 17:10:52 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Fri, 06 Nov 2015 22:10:52 +0000 Subject: [issue25573] FrameSummary repr() does not support previously working uses of repr in traceback module In-Reply-To: <1446845666.11.0.0803768990935.issue25573@psf.upfronthosting.co.za> Message-ID: <1446847852.41.0.863580904222.issue25573@psf.upfronthosting.co.za> St?phane Wirtel added the comment: Oops, sorry, ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 17:14:28 2015 From: report at bugs.python.org (Christian Rickert) Date: Fri, 06 Nov 2015 22:14:28 +0000 Subject: [issue25570] urllib.request > Request.add_header("abcd", "efgh") fails with character ":" in first parameter string In-Reply-To: <1446842352.31.0.869437789925.issue25570@psf.upfronthosting.co.za> Message-ID: <1446848068.66.0.0914332425298.issue25570@psf.upfronthosting.co.za> Christian Rickert added the comment: I would suggest a red warning box that informs the reader about her/his responsibility to comply with HTTP specifications - i.e. ensuring compatibility and security. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 17:22:05 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 06 Nov 2015 22:22:05 +0000 Subject: [issue25550] RecursionError in re with '(' * 500 In-Reply-To: <1446627776.2.0.048563717292.issue25550@psf.upfronthosting.co.za> Message-ID: <1446848525.97.0.739060696478.issue25550@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Is the recursion limit hit enough in real-world problems that we should consider replacing recursive calls and the implicit C call stack with loops and an explicit stack? ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 17:35:05 2015 From: report at bugs.python.org (wim glenn) Date: Fri, 06 Nov 2015 22:35:05 +0000 Subject: [issue25574] 2.7 incorrectly documents objects hash as equal to id Message-ID: <1446849305.52.0.678156368856.issue25574@psf.upfronthosting.co.za> New submission from wim glenn: The 2.7 glossary still incorrectly mentions instances of user-defined classes hash equal to their id. https://docs.python.org/2/glossary.html#term-hashable Just a minor documentation bug that was unfortunately missed by http://bugs.python.org/issue21782 ---------- assignee: docs at python components: Documentation files: mywork.patch keywords: patch messages: 254237 nosy: docs at python, wim.glenn priority: normal severity: normal status: open title: 2.7 incorrectly documents objects hash as equal to id versions: Python 2.7 Added file: http://bugs.python.org/file40966/mywork.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 17:38:30 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 06 Nov 2015 22:38:30 +0000 Subject: [issue25563] Windows 10 Tkinter startup problem In-Reply-To: <1446762509.1.0.723427764258.issue25563@psf.upfronthosting.co.za> Message-ID: <1446849510.54.0.20495167405.issue25563@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- title: Windows 10 IDLE / Tkinter startup problem -> Windows 10 Tkinter startup problem _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 17:39:58 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 06 Nov 2015 22:39:58 +0000 Subject: [issue25563] Windows 10: _tkinter import fails In-Reply-To: <1446762509.1.0.723427764258.issue25563@psf.upfronthosting.co.za> Message-ID: <1446849598.68.0.83457590945.issue25563@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- title: Windows 10 Tkinter startup problem -> Windows 10: _tkinter import fails _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 17:49:57 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 06 Nov 2015 22:49:57 +0000 Subject: [issue25545] email parsing docs: clarify that only ASCII strings are supported In-Reply-To: <1446561810.16.0.921085816129.issue25545@psf.upfronthosting.co.za> Message-ID: <1446850197.83.0.681230639348.issue25545@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- title: email parsing docs need to be clear that only ASCII strings are supported -> email parsing docs: clarify that only ASCII strings are supported _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 18:15:25 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 06 Nov 2015 23:15:25 +0000 Subject: [issue25570] urllib.request > Request.add_header("abcd", "efgh") fails with character ":" in first parameter string In-Reply-To: <1446842352.31.0.869437789925.issue25570@psf.upfronthosting.co.za> Message-ID: <1446851725.79.0.325343385277.issue25570@psf.upfronthosting.co.za> Martin Panter added the comment: This change is a result of parameter checking added in Issue 22928. The colon is not meant to be part of a field name. This is what the request being sent by your example looks like in the unpatched 3.4. (I changed to localhost.) Your attempt to override the default Content-Type is not working due to the colon: POST /xrbl82xr HTTP/1.1 Accept-Encoding: identity Content-Type: application/x-www-form-urlencoded Host: localhost User-Agent: Python-urllib/3.4 Content-Length: 21 Content-Type:: application/x-www-form-urlencoded;charset=utf-8 Connection: close spam=1&eggs=2&bacon=0 So I don?t think this is a valid bug or regression. What gave you the idea to include the colon? Does the documentation need clarifying? Also, I would recommend not trying to set a ?charset? attribute with the form-urlencoded content type in general. It is not standardized, and I proposed to remove the recommendation from the documentation in Issue 23360 (feedback welcome). If you really need to send non-ASCII data, you might be able to get away with UTF-8 by default. Also, HTML 5 mentions a _charset_ field, and there is the multipart/form-data content type. ---------- nosy: +martin.panter stage: needs patch -> type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 18:27:23 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 06 Nov 2015 23:27:23 +0000 Subject: [issue25570] urllib.request > Request.add_header("abcd", "efgh") fails with character ":" in first parameter string In-Reply-To: <1446842352.31.0.869437789925.issue25570@psf.upfronthosting.co.za> Message-ID: <1446852443.14.0.973226162387.issue25570@psf.upfronthosting.co.za> Martin Panter added the comment: Sorry, it seems I missed some updates to this bug. I think the docs have enough big red warning boxes. But an explanation or short example might be good. ---------- stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 18:43:49 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 06 Nov 2015 23:43:49 +0000 Subject: [issue25543] locale.atof keep '.' even if not part of the localeconv In-Reply-To: <1446557418.04.0.0373772163699.issue25543@psf.upfronthosting.co.za> Message-ID: <1446853429.23.0.0117479347727.issue25543@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I much prefer a new argument, 'strict=False', to a new, near-duplicate function. locale.atof('2.500,5') should raise. The only question is what should be displayed as the invalid literal: the original or the converted. It seems to me that delocalize should replace the local thousands separator, in this case '.', with ',' as it replaces the local decimal point with '.'. Then the invalid literal would be '1,234.5'. And locale.atof('1.5') would become float('1,5'), which would raise. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 18:45:29 2015 From: report at bugs.python.org (Christian Rickert) Date: Fri, 06 Nov 2015 23:45:29 +0000 Subject: [issue25570] urllib.request > Request.add_header("abcd", "efgh") fails with character ":" in first parameter string In-Reply-To: <1446842352.31.0.869437789925.issue25570@psf.upfronthosting.co.za> Message-ID: <1446853529.59.0.778263923755.issue25570@psf.upfronthosting.co.za> Christian Rickert added the comment: >>So I don?t think this is a valid bug or regression. What gave you the idea to include the colon? "We ask that if you are going to consume the API that you pass a custom User-Agent header along with your requests. The User-Agent should primarily include information on how we can contact you, but it is also a good idea to include your application name and version." [https://eveonline-third-party-documentation.readthedocs.org/en/latest/xmlapi/intro/#other-information] This is why I created custom User-Agent headers: .add_header("Contact: ","me") .add_header("Software: ","sw") .add_header("Version: ","0.1") I didn't really need the colons, it just worked. >>Does the documentation need clarifying? In the description for "headers" in the "class urllib.request.Request" section, Mozilla's string is given as an example: "Mozilla/5.0 (X11; U; Linux i686) Gecko/20071127 Firefox/2.0.0.11" Including slashes, semicolons, and braces, I didn't think I would run into problems with using a colon (in the first parameter string). >>Also, I would recommend not trying to set a ?charset? attribute with the form-urlencoded content type in general. It is not standardized, and I proposed to remove the recommendation from the documentation in Issue 23360 (feedback welcome). I agree. The examples provided should be good (standard-conform) examples. >>I think the docs have enough big red warning boxes. But an explanation or short example might be good. Maybe a comment line in the examples? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 18:46:00 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 06 Nov 2015 23:46:00 +0000 Subject: [issue25541] Wrong usage of sockaddr_un struct for abstract namespace unix sockets In-Reply-To: <1446549321.99.0.809607214975.issue25541@psf.upfronthosting.co.za> Message-ID: <1446853560.57.0.77630096917.issue25541@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 18:46:50 2015 From: report at bugs.python.org (G) Date: Fri, 06 Nov 2015 23:46:50 +0000 Subject: [issue25575] idle not working Message-ID: <1446853610.68.0.999917057538.issue25575@psf.upfronthosting.co.za> New submission from G: I'm teaching Python in a computer lab with 28, new this Sept., Mac Minis. One of the machines will run from the command line in Terminal but will not run using IDLE. I'm using the turtle module for graphics. I've attached a screen snap of the code and error message. The top part of the image shows error message using IDLE. The bottom part of the image shows the same code runs from the command line. I just updated the OS to OSX 11.11.1 and it still did not fix the issue. Any ideas on how to fix it? ---------- components: IDLE files: Python idle problem.png messages: 254242 nosy: ccgm priority: normal severity: normal status: open title: idle not working type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file40967/Python idle problem.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 19:08:09 2015 From: report at bugs.python.org (ppperry) Date: Sat, 07 Nov 2015 00:08:09 +0000 Subject: [issue25336] Segmentation fault on Mavericks consistent crashing of software In-Reply-To: <1444263912.5.0.0566907258707.issue25336@psf.upfronthosting.co.za> Message-ID: <1446854889.24.0.855929263215.issue25336@psf.upfronthosting.co.za> Changes by ppperry : ---------- title: Segmentation fault on Mavericks consistent crashing of software: Please HELP!!!!! -> Segmentation fault on Mavericks consistent crashing of software _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 19:24:38 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 07 Nov 2015 00:24:38 +0000 Subject: [issue25570] urllib.request > Request.add_header("abcd", "efgh") fails with character ":" in first parameter string In-Reply-To: <1446842352.31.0.869437789925.issue25570@psf.upfronthosting.co.za> Message-ID: <1446855878.45.0.459884928932.issue25570@psf.upfronthosting.co.za> Martin Panter added the comment: Ah, I think I see where you are coming from. I guess you aren?t intimately familiar with the HTTP protocol. There are various types of ?headers? aka header fields, not only User-Agent, but Content-Type and others. When they suggest passing a User-Agent header, that actually means a call like request.add_header("User-Agent", "custom text here") using the exact string "User-Agent" as the field name (key). If you can given a specific comment line to add to a specific example, that might be useful. Even if you aren?t 100% sure of the details :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 19:30:56 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 07 Nov 2015 00:30:56 +0000 Subject: [issue25538] Traceback from __exit__ method is misleading In-Reply-To: <1446505683.0.0.402181965789.issue25538@psf.upfronthosting.co.za> Message-ID: <1446856256.19.0.0804402854886.issue25538@psf.upfronthosting.co.za> Terry J. Reedy added the comment: In Martin's example, I would expect the first line of the traceback to be the file write that raised the exception, not the print that is never executed. If print were writing to a different device than the first line, the traceback would be positively misleading. In David's example, the print executed just fine, so it should not appear in the traceback either. The replacement, if any, might be the with statement itself. The 'pseudo-line' that triggers the __exit__ call is really the dedent on the next line, but printing the whole next line would be wrong too. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 19:42:47 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 07 Nov 2015 00:42:47 +0000 Subject: [issue25538] Traceback from __exit__ method is misleading In-Reply-To: <1446505683.0.0.402181965789.issue25538@psf.upfronthosting.co.za> Message-ID: <1446856967.88.0.991565609931.issue25538@psf.upfronthosting.co.za> Martin Panter added the comment: Explanation of my example because it is tricky: The print is actually executed. Then the context manager exits, and the built-in buffered file object tries to flush its buffer and fails. The earlier write() call succeeds, because it only writes to the Python buffer, not the OS file descriptor. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 19:50:52 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 07 Nov 2015 00:50:52 +0000 Subject: [issue25534] SimpleHTTPServer throwed an exception due to negtive st_mtime attr in file In-Reply-To: <1446478517.38.0.562445062137.issue25534@psf.upfronthosting.co.za> Message-ID: <1446857452.0.0.474388571588.issue25534@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Does this affect 3.x also? I would expect that it does. The question for this issue is whether the program should stop on a gmtime error and say "I will not serve this file until you fix the modification time." or whether it should catch and workaround the problem and merely warn about the mtime. For the latter, BaseHTTPServer could catch the gmtime error and use the current time instead. Or SimpleHTTPServer could catch the exception and omit the Last Modified: header, if that is allowed. I believe the purpose of this header is for caching, and the current time would say to replace any cached value. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 20:00:09 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 07 Nov 2015 01:00:09 +0000 Subject: [issue25064] Adjust tempfile documentation for bytes filename support In-Reply-To: <1441943216.0.0.731717269075.issue25064@psf.upfronthosting.co.za> Message-ID: <20151107010004.58393.49796@psf.io> Roundup Robot added the comment: New changeset de79e483565c by Martin Panter in branch '3.5': Issue #25064: Adjust documentation according to new mkstemp signature https://hg.python.org/cpython/rev/de79e483565c New changeset c495c9dd7726 by Martin Panter in branch 'default': Issue #25064: Merge tempfile doc from 3.5 https://hg.python.org/cpython/rev/c495c9dd7726 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 20:17:21 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 07 Nov 2015 01:17:21 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> Message-ID: <1446859041.27.0.28041396868.issue23496@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Ryan, please sign the PSF Contributor Agreement https://www.python.org/psf/contrib/ https://www.python.org/psf/contrib/contrib-form/ Also, when replying by email, please delete the previous message, except possibly for quoting a line or two. When listed on the web page, big quotations are useless noise. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 20:30:31 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 07 Nov 2015 01:30:31 +0000 Subject: [issue25064] Adjust tempfile documentation for bytes filename support In-Reply-To: <1441943216.0.0.731717269075.issue25064@psf.upfronthosting.co.za> Message-ID: <1446859831.02.0.139085941507.issue25064@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 20:41:26 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 07 Nov 2015 01:41:26 +0000 Subject: [issue25534] SimpleHTTPServer throwed an exception due to negtive st_mtime attr in file In-Reply-To: <1446478517.38.0.562445062137.issue25534@psf.upfronthosting.co.za> Message-ID: <1446860486.89.0.311259933204.issue25534@psf.upfronthosting.co.za> Martin Panter added the comment: I assume it affects Python 3, though I suspect the exception is OSError, not ValueError. But it would be good if someone with Windows (or other affected OS) could confirm. I think the server should serve the file, with just a best-effort attempt to serve the timestamp. Some other options: * Maybe using datetime rather than the OS?s gmtime() would be more reliable * Omit the Last-Modified header if the timestamp cannot be represented * Make time.gmtime() more platform-independent (probably against the original spirit of the module) I don?t think setting Last-Modified to the current time is a particularly good idea. I guess omitting the field would have a similar effect on caching, without actually serving a misleading value. ---------- versions: +Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 20:49:39 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 07 Nov 2015 01:49:39 +0000 Subject: [issue21224] BaseHTTPRequestHandler, update the protocol version to http 1.1 by default? In-Reply-To: <1397508232.09.0.0337317788686.issue21224@psf.upfronthosting.co.za> Message-ID: <1446860979.07.0.918184140085.issue21224@psf.upfronthosting.co.za> Martin Panter added the comment: There is already Issue 23794 discussing HTTP 2. IMO it would be interesting to implement, but I?m not sure how appropriate it would be in Python?s standard library at this stage. But working on it could drive other improvements in the existing HTTP stuff, as Demian hinted. What do you mean by supporting HTTP 1.1 in the future? The basic support is already there; you just have to manually enable it. Maybe there is scope for making 1.1 easier to use, perhaps with a BaseHTTP11RequestHandler (shorter: Http11Handler) class or something. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 20:50:53 2015 From: report at bugs.python.org (Alex Gaynor) Date: Sat, 07 Nov 2015 01:50:53 +0000 Subject: [issue25569] Memory leak in SSLSocket.getpeercert() In-Reply-To: <1446840481.06.0.811345685129.issue25569@psf.upfronthosting.co.za> Message-ID: <1446861053.56.0.329235165827.issue25569@psf.upfronthosting.co.za> Alex Gaynor added the comment: Tests pass and the original script runs without a leak using this patch. It could probably be shorter if we converted from local returns to `goto fail` or something, but I don't really have an opinion. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 21:28:26 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 07 Nov 2015 02:28:26 +0000 Subject: [issue25538] Traceback from __exit__ method is misleading In-Reply-To: <1446505683.0.0.402181965789.issue25538@psf.upfronthosting.co.za> Message-ID: <1446863306.85.0.610378828244.issue25538@psf.upfronthosting.co.za> R. David Murray added the comment: Yes, I think the line that should be in the traceback in my example is the 'with' line. I have no clue how hard that would be to achieve. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 22:29:56 2015 From: report at bugs.python.org (Zachary Ware) Date: Sat, 07 Nov 2015 03:29:56 +0000 Subject: [issue25575] idle not working In-Reply-To: <1446853610.68.0.999917057538.issue25575@psf.upfronthosting.co.za> Message-ID: <1446866996.72.0.537757485503.issue25575@psf.upfronthosting.co.za> Zachary Ware added the comment: Check the traceback carefully, it shows exactly where the problem is, though it's not immediately obvious until it's bitten you a time or two. You are running /Users/a5/Desktop/z.py which imports turtle, but you have a turtle.py in /Users/a5/Desktop which is found before the standard library turtle. Your command line test works because it is run from a different directory. Just remove or rename /Users/a5/Desktop/turtle.py and it will work. There have been other reports about this lately, and there are on-going discussions about what can be done to try to prevent this situation. ---------- nosy: +zach.ware resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 6 22:33:16 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 07 Nov 2015 03:33:16 +0000 Subject: [issue24802] int and float constructing from non NUL-terminated buffer In-Reply-To: <1438830920.07.0.863152787453.issue24802@psf.upfronthosting.co.za> Message-ID: <20151107033309.2126.49315@psf.io> Roundup Robot added the comment: New changeset a75336ac40e0 by Martin Panter in branch '3.4': Issue #24802: Copy bytes-like objects to null-terminated buffers if necessary https://hg.python.org/cpython/rev/a75336ac40e0 New changeset 95b9c07b27f7 by Martin Panter in branch '3.5': Issue #24802: Merge null termination fixes from 3.4 into 3.5 https://hg.python.org/cpython/rev/95b9c07b27f7 New changeset 4df1eaecb506 by Martin Panter in branch 'default': Issue #24802: Merge null termination fixes from 3.5 https://hg.python.org/cpython/rev/4df1eaecb506 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 00:35:35 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 07 Nov 2015 05:35:35 +0000 Subject: [issue24802] int and float constructing from non NUL-terminated buffer In-Reply-To: <1438830920.07.0.863152787453.issue24802@psf.upfronthosting.co.za> Message-ID: <1446874535.66.0.011996607623.issue24802@psf.upfronthosting.co.za> Martin Panter added the comment: I have committed changes to Python 3. The compile() test now exists as test_compile.TestSpecifics.test_null_terminated. Serhiy: You set these bugs for Python 2 as well. Is there a way to produce a non-null-terminated buffer in Python 2 to help verify this? Both John?s original array() tests and the memoryview() tests don?t seem to be supported by Python 2?s idea of buffer objects: >>> float(array.array("B",b"A"*0x10)) Traceback (most recent call last): File "", line 1, in TypeError: float() argument must be a string or a number >>> float(memoryview(b"1234")[1:-1]) Traceback (most recent call last): File "", line 1, in TypeError: float() argument must be a string or a number I have a half-ported patch for Python 2, but it would be nice to know (a) if it is actually needed, and (b) what to do about unit tests. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 00:59:03 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 07 Nov 2015 05:59:03 +0000 Subject: [issue25017] htmllib deprecated: Which library to use? Missing sane default in docs In-Reply-To: <1441616497.34.0.0999815194375.issue25017@psf.upfronthosting.co.za> Message-ID: <1446875943.55.0.742204337461.issue25017@psf.upfronthosting.co.za> Martin Panter added the comment: David: are you saying you like the first patch better (ignoring the markup mistakes)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 01:01:00 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 07 Nov 2015 06:01:00 +0000 Subject: [issue18010] pydoc search chokes on import errors In-Reply-To: <1368896719.35.0.915741072389.issue18010@psf.upfronthosting.co.za> Message-ID: <20151107060056.92480.55351@psf.io> Roundup Robot added the comment: New changeset 1ab20d3c9dc6 by Martin Panter in branch '2.7': Issue #18010: Fix pydoc GUI search to handle package exceptions https://hg.python.org/cpython/rev/1ab20d3c9dc6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 01:06:43 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 07 Nov 2015 06:06:43 +0000 Subject: [issue18010] pydoc search chokes on import errors In-Reply-To: <1368896719.35.0.915741072389.issue18010@psf.upfronthosting.co.za> Message-ID: <1446876403.44.0.833635077779.issue18010@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 02:01:44 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 07 Nov 2015 07:01:44 +0000 Subject: [issue23360] Content-Type when sending data with urlopen() In-Reply-To: <1422794612.5.0.505084736818.issue23360@psf.upfronthosting.co.za> Message-ID: <1446879704.71.0.0257331116577.issue23360@psf.upfronthosting.co.za> Martin Panter added the comment: Patch 4 is just updated to avoid conflicts with the current code. Changes are the same. ---------- versions: +Python 3.6 Added file: http://bugs.python.org/file40968/non-urlencoded.4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 02:32:31 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 07 Nov 2015 07:32:31 +0000 Subject: [issue23360] Content-Type when sending data with urlopen() In-Reply-To: <1422794612.5.0.505084736818.issue23360@psf.upfronthosting.co.za> Message-ID: <1446881551.0.0.370915013932.issue23360@psf.upfronthosting.co.za> Martin Panter added the comment: Spotted a docstring that needed updating ---------- Added file: http://bugs.python.org/file40969/non-urlencoded.5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 02:33:43 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 07 Nov 2015 07:33:43 +0000 Subject: [issue24802] int and float constructing from non NUL-terminated buffer In-Reply-To: <1438830920.07.0.863152787453.issue24802@psf.upfronthosting.co.za> Message-ID: <1446881623.08.0.774316917241.issue24802@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yes, looks as this issue is not related to 2.7. ---------- assignee: serhiy.storchaka -> martin.panter versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 02:52:41 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 07 Nov 2015 07:52:41 +0000 Subject: [issue25550] RecursionError in re with '(' * 500 In-Reply-To: <1446627776.2.0.048563717292.issue25550@psf.upfronthosting.co.za> Message-ID: <1446882761.17.0.698805417454.issue25550@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think it is possible to make the parser non-recursive, but without reports about such real-world problems it looks premature and just will complicate the code. For years before 3.5 there was a limitation on only 100 capturing groups. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 03:24:40 2015 From: report at bugs.python.org (Christian Tanzer) Date: Sat, 07 Nov 2015 08:24:40 +0000 Subject: [issue25545] email parsing docs: clarify that only ASCII strings are supported In-Reply-To: Your message of "Fri, 06 Nov 2015 22:49:57 +0000" <1446850197.89.0.42252299458.issue25545@psf.upfronthosting.co.za> Message-ID: Christian Tanzer added the comment: Terry J. Reedy wrote at Fri, 06 Nov 2015 22:49:57 +0000: > email parsing docs: clarify that only ASCII strings are supported If that is the decision, `message_from_string` should raise an exception if it gets a non-ASCII argument! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 03:43:41 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 07 Nov 2015 08:43:41 +0000 Subject: =?utf-8?q?=5Bissue25576=5D_Remove_=E2=80=9CContent-Type=3A_application/x-?= =?utf-8?q?www-form-urlencoded=3B_charset=E2=80=9D_advice?= Message-ID: <1446885820.73.0.0514095635951.issue25576@psf.upfronthosting.co.za> New submission from Martin Panter: I understand using a ?charset? parameter with ?Content-Type: application/x-www-form-urlencoded? is not standardized. Since Issue 11082, the documentation advises to use it, but I propose to remove this advice. HTML 5 mentions setting a _charset_ parameter, and mentions decoding with a default of UTF-8 (not Latin-1!), but does not mention any Content-Type parameters. There seems to be confusion about what encoding it actually represents. According to , Mozilla briefly set this ?charset? parameter a long time ago, but it would have corresponded to the urlencode(encoding=...) argument. The Python documentation currently suggests calling data.encode("utf-8"), which is misleading, because the urlencode() output is already guaranteed to be ASCII text. Any non-ASCII characters and bytes will already be character-encoded and percent-encoded by urlencode(). So I also propose to change the examples to data.encode("ascii"). ---------- assignee: docs at python components: Documentation files: urlencoded-charset.patch keywords: patch messages: 254263 nosy: docs at python, martin.panter, orsenthil priority: normal severity: normal stage: patch review status: open title: Remove ?Content-Type: application/x-www-form-urlencoded; charset? advice versions: Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file40970/urlencoded-charset.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 04:17:41 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 07 Nov 2015 09:17:41 +0000 Subject: [issue892902] problem with pickling newstyle class instances Message-ID: <20151107091736.24932.79739@psf.io> Roundup Robot added the comment: New changeset 9ad1fd251ddf by Serhiy Storchaka in branch '2.7': Issue #892902: Fixed pickling recursive objects. https://hg.python.org/cpython/rev/9ad1fd251ddf New changeset 2071d16ed5e6 by Serhiy Storchaka in branch '3.4': Issue #892902: Added new tests for pickling recursive collections. https://hg.python.org/cpython/rev/2071d16ed5e6 New changeset f33ce913220b by Serhiy Storchaka in branch '3.5': Issue #892902: Added new tests for pickling recursive collections. https://hg.python.org/cpython/rev/f33ce913220b New changeset 2c81a883d8ca by Serhiy Storchaka in branch 'default': Issue #892902: Added new tests for pickling recursive collections. https://hg.python.org/cpython/rev/2c81a883d8ca ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 04:22:53 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 07 Nov 2015 09:22:53 +0000 Subject: [issue892902] problem with pickling newstyle class instances Message-ID: <1446888173.25.0.312793868703.issue892902@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your review Alexandre. In 3.x old tests test_recursive_set and test_recursive_frozenset now are implemented in test_recursive_set_and_inst and test_recursive_frozenset_and_inst. Instead new test_recursive_set now tests protocol 4 ability of pickling recursive sets itself. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 04:50:56 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 07 Nov 2015 09:50:56 +0000 Subject: [issue24802] int and float constructing from non NUL-terminated buffer In-Reply-To: <1438830920.07.0.863152787453.issue24802@psf.upfronthosting.co.za> Message-ID: <1446889856.33.0.888659839728.issue24802@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: One post-commit comment: I would use ValueError instead of Exceptions in tests for 3.5+. This will help to avoid regression and can catch incompatibilities in other implementations. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 07:29:22 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 07 Nov 2015 12:29:22 +0000 Subject: [issue25455] Some repr implementations don't check for self-referential structures In-Reply-To: <1445455038.6.0.824380060049.issue25455@psf.upfronthosting.co.za> Message-ID: <1446899362.32.0.617026025153.issue25455@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here are patches for io classes and for ElementTree. ---------- stage: needs patch -> patch review versions: +Python 2.7, Python 3.4 Added file: http://bugs.python.org/file40971/io_recursive_repr.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 07:29:41 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 07 Nov 2015 12:29:41 +0000 Subject: [issue25455] Some repr implementations don't check for self-referential structures In-Reply-To: <1445455038.6.0.824380060049.issue25455@psf.upfronthosting.co.za> Message-ID: <1446899381.56.0.530710165935.issue25455@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file40972/etree_recursive_repr.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 07:50:58 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 07 Nov 2015 12:50:58 +0000 Subject: [issue25455] Some repr implementations don't check for self-referential structures In-Reply-To: <1445455038.6.0.824380060049.issue25455@psf.upfronthosting.co.za> Message-ID: <1446900658.13.0.739458815177.issue25455@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: There is also a crash with Python implementation of TextIOWrapper. >>> import _pyio as io >>> t = io.TextIOWrapper(io.BytesIO()) >>> t.mode = t >>> t Fatal Python error: Cannot recover from stack overflow. Current thread 0xb74a9700 (most recent call first): File "/home/serhiy/py/cpython/Lib/_pyio.py", line 1982 in __repr__ File "/home/serhiy/py/cpython/Lib/_pyio.py", line 1992 in __repr__ [...] File "/home/serhiy/py/cpython/Lib/_pyio.py", line 1992 in __repr__ File "/home/serhiy/py/cpython/Lib/_pyio.py", line 1992 in __repr__ ... Aborted (core dumped) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 08:43:07 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 07 Nov 2015 13:43:07 +0000 Subject: [issue25558] Use static asserts in C code In-Reply-To: <1446742000.61.0.314081889142.issue25558@psf.upfronthosting.co.za> Message-ID: <20151107134304.58393.20512@psf.io> Roundup Robot added the comment: New changeset 45a404d33c2d by Serhiy Storchaka in branch 'default': Issue #25558: Use compile-time asserts. https://hg.python.org/cpython/rev/45a404d33c2d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 09:18:53 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 07 Nov 2015 14:18:53 +0000 Subject: [issue25558] Use static asserts in C code In-Reply-To: <1446742000.61.0.314081889142.issue25558@psf.upfronthosting.co.za> Message-ID: <1446905933.39.0.936910162683.issue25558@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > By the way, I don't know what happens if you pass a variable to Py_BUILD_ASSERT_EXPR() rather than a constant. If the compiler can't calculate it at compile time (e.g. int_var <= INT_MAX), your are out of luck. > Maybe we could use __builtin_constant_p() on GCC? Don't know if it will help. ---------- stage: patch review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 09:35:42 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Sat, 07 Nov 2015 14:35:42 +0000 Subject: [issue25569] Memory leak in SSLSocket.getpeercert() In-Reply-To: <1446840481.06.0.811345685129.issue25569@psf.upfronthosting.co.za> Message-ID: <1446906942.22.0.0183738286388.issue25569@psf.upfronthosting.co.za> St?phane Wirtel added the comment: Hi alex, Thank you for your feeback, I will propose an other patch with your remarks. Stephane ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 09:56:03 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 07 Nov 2015 14:56:03 +0000 Subject: [issue22643] Integer overflow in case_operation In-Reply-To: <1413384630.17.0.213972312804.issue22643@psf.upfronthosting.co.za> Message-ID: <20151107145600.2122.51973@psf.io> Roundup Robot added the comment: New changeset 5fae49ef94fd by Serhiy Storchaka in branch '3.4': Issue #22643: Skip test_case_operation_overflow on computers with low memory. https://hg.python.org/cpython/rev/5fae49ef94fd New changeset 6b00bee218ff by Serhiy Storchaka in branch '3.5': Issue #22643: Skip test_case_operation_overflow on computers with low memory. https://hg.python.org/cpython/rev/6b00bee218ff New changeset b1c5949a3af4 by Serhiy Storchaka in branch 'default': Issue #22643: Skip test_case_operation_overflow on computers with low memory. https://hg.python.org/cpython/rev/b1c5949a3af4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 10:02:51 2015 From: report at bugs.python.org (Raffaele Mancuso) Date: Sat, 07 Nov 2015 15:02:51 +0000 Subject: [issue25577] os.path.dirname leave left quote and remove right one Message-ID: <1446908571.56.0.283810738924.issue25577@psf.upfronthosting.co.za> New submission from Raffaele Mancuso: Python 3.4.3 (default, Jun 29 2015, 12:16:01) [GCC 5.1.1 20150618 (Red Hat 5.1.1-4)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> dir = "\"ciao/come/stai/ciao.pdf\"" >>> dir '"ciao/come/stai/ciao.pdf"' >>> os.path.dirname(dir) '"ciao/come/stai' As you can see, dirname has removed the right quote, but not the left one. The correct behaviour should be 'ciao/come/stai' (no quotes) OR '"ciao/come/stai"' (both quotes) but never '"ciao/come/stai' (only one quote) This breaks other bash tools ---------- components: Library (Lib) messages: 254273 nosy: Raffaele Mancuso priority: normal severity: normal status: open title: os.path.dirname leave left quote and remove right one versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 10:10:51 2015 From: report at bugs.python.org (Zachary Ware) Date: Sat, 07 Nov 2015 15:10:51 +0000 Subject: [issue25577] os.path.dirname leave left quote and remove right one In-Reply-To: <1446908571.56.0.283810738924.issue25577@psf.upfronthosting.co.za> Message-ID: <1446909051.66.0.00731668781802.issue25577@psf.upfronthosting.co.za> Zachary Ware added the comment: As far as os.path.dirname is concerned, you have a file named 'ciao.pdf"' in a directory called '"ciao/come/stai', which is what you're seeing. Since those are legal names, there's no way for os.path.dirname to know what you actually want. The solution is to handle the quotes yourself however you want. ---------- nosy: +zach.ware resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 10:28:36 2015 From: report at bugs.python.org (Alex Gaynor) Date: Sat, 07 Nov 2015 15:28:36 +0000 Subject: [issue25578] Memory leak in SSLSocket.getpeercert() with 0-length AIA extension Message-ID: <1446910116.69.0.509897683055.issue25578@psf.upfronthosting.co.za> New submission from Alex Gaynor: Test. Put this certificate in a file: -----BEGIN CERTIFICATE----- MIICjTCCAXWgAwIBAgIBADANBgkqhkiG9w0BAQsFADAAMB4XDTE1MTEwNzE1MTAw NVoXDTE1MTEwNzE1MTAwNVowADCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAKiZ3rzOM1m6toThRtkwgZzjuVVdapwU63yoXmp91f14pfO1z5XIkVAP1Sz/ nK5Ti95LRmgPOzbIQHyNv2k2IOIbHL52y4AwWTa2G1EF3NvD9Tp6Zs85GFf7T5/N WnlqHHPZhAHpgHL2xjBWnnhVojDm6fgxE6OI0aFarLlO0FBs3PLgIoxY4RRPVYaz toP9G8ezbdGWGhaCqKO+ZjrCoQ2JNIdk4WsuGrZbCnGvGzFm+uhvs68IbJM4Mfm6 mAO85UfjdHsyacs5MYYsb7GyzrkGnLwWNcK5NdZiJwzwxBYpbchj5hYIsYjIVAL6 0BE4qG7wnJcHq1rvBeNgp7fP06kCAwEAAaMSMBAwDgYIKwYBBQUHAQEEAjAAMA0G CSqGSIb3DQEBCwUAA4IBAQBS+2YG56erPLavJ3PvP+DekHOuIakT3l6GCiDGsufO owdPxqsUZcCHlYjn6E50dLoKN0N6ECoKB0bIsA2EuwY08MSgtD4dA93jTXsdvWcX 2QMIM11LIGLyJIZRgUeMdHAbsb9qdpWFXX6smDGLBBKHCIFwu/4qSXU+Gf5d2DMl edMDMkbgv3B8Q+7pCi7AgUOaZXPTbpHCdYnT2t+z3gNgyiXBH5wJNkrkK5tmawNb 88+Kxa00mbYoSEPaz7E/zBB/W1NpoZCOgEq4t9Uuk7hm10htbKoyM7FxVpBEJkPE XpUdSNdClrHN36j1iB1NeFuOlxNVbD5FtMXx/wgX0B28 -----END CERTIFICATE----- And run this script: import _ssl def main(): while True: _ssl._test_decode_cert("/path/to/cert.pem") main() Patch is attached ---------- files: aia.diff keywords: needs review, patch messages: 254275 nosy: alex, christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou priority: normal severity: normal status: open title: Memory leak in SSLSocket.getpeercert() with 0-length AIA extension versions: Python 2.7, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file40973/aia.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 10:36:32 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 07 Nov 2015 15:36:32 +0000 Subject: [issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC In-Reply-To: <1441362190.45.0.409936717424.issue24999@psf.upfronthosting.co.za> Message-ID: <1446910592.59.0.911535775025.issue24999@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It looks to me that all issues are related to floating points. ====================================================================== FAIL: test_add (test.test_audioop.TestAudioop) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\test\test_audioop.py", line 138, in test_add datas[w]) AssertionError: b'\x00\x00\x00\x00\x80V4\x12\x80\x89gE\x80v\x98\xba\x00\x00[36 chars]\xff' != b'\x00\x00\x00\x00xV4\x12\xab\x89gEUv\x98\xba\xff\xff\xff\x[30 chars]\xff' ====================================================================== FAIL: test_tostereo (test.test_audioop.TestAudioop) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\test\test_audioop.py", line 438, in test_tostereo self.assertEqual(audioop.tostereo(data1, w, 1, 0), data2) AssertionError: b'\x00\x00\x00\x00\x00\x00\x00\x00\x80V4\x[165 chars]\x00' != bytearray(b'\x00\x00\x00\x00\x00\x00\x00\x[170 chars]x00') ---------------------------------------------------------------------- audioop uses double for addition of 32-bit samples and converting to stereo. On this platforms it uses only highest 25 bits (including sign) and clears lowest 7 bit. Other tests also expose the lost of precision. ====================================================================== FAIL: test_from_hex (test.test_float.HexFloatTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\test\test_float.py", line 1228, in test_from_hex self.identical(fromHex('0x0.ffffffffffffd6p-1022'), MIN-3*TINY) File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\test\test_float.py", line 939, in identical self.fail('%r not identical to %r' % (x, y)) AssertionError: 0.0 not identical to 2.2250738585072014e-308 ---------------------------------------------------------------------- ====================================================================== ERROR: test_specific_values (test.test_cmath.CMathTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\test\test_cmath.py", line 355, in test_specific_values actual = function(arg) ValueError: math domain error ---------------------------------------------------------------------- ====================================================================== FAIL: fromhex (builtins.float) Doctest: builtins.float.fromhex ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\doctest.py", line 2189, in runTest raise self.failureException(self.format_failure(new.getvalue())) AssertionError: Failed doctest test for builtins.float.fromhex File "builtins", line unknown line number, in fromhex ---------------------------------------------------------------------- File "builtins", line ?, in builtins.float.fromhex Failed example: float.fromhex('-0x1p-1074') Expected: -5e-324 Got: -0.0 ---------------------------------------------------------------------- ====================================================================== FAIL: test_bigcomp (test.test_strtod.StrtodTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\test\test_strtod.py", line 213, in test_bigcomp self.check_strtod(s) File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\test\test_strtod.py", line 104, in check_strtod "expected {}, got {}".format(s, expected, got)) AssertionError: '0x0.000000be3528cp-1022' != '0x0.0p+0' - 0x0.000000be3528cp-1022 + 0x0.0p+0 : Incorrectly rounded str->float conversion for 9854e-319: expected 0x0.000000be3528cp-1022, got 0x0.0p+0 ====================================================================== FAIL: test_boundaries (test.test_strtod.StrtodTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\test\test_strtod.py", line 190, in test_boundaries self.check_strtod(s) File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\test\test_strtod.py", line 104, in check_strtod "expected {}, got {}".format(s, expected, got)) AssertionError: '0x0.ffffffffffffep-1022' != '0x0.0p+0' - 0x0.ffffffffffffep-1022 + 0x0.0p+0 : Incorrectly rounded str->float conversion for 22250738585072001874e-327: expected 0x0.ffffffffffffep-1022, got 0x0.0p+0 ====================================================================== FAIL: test_halfway_cases (test.test_strtod.StrtodTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\test\test_strtod.py", line 173, in test_halfway_cases self.check_strtod(s) File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\test\test_strtod.py", line 104, in check_strtod "expected {}, got {}".format(s, expected, got)) AssertionError: '0x0.947c9545804f2p-1022' != '0x0.0p+0' - 0x0.947c9545804f2p-1022 + 0x0.0p+0 : Incorrectly rounded str->float conversion for 129060066119072381453846425881820124322370272229648099639268127314770620842265843984812683156331055738253536699704952360196529596150749604030149685393298799013053728016749774464387976212748813933724362621076615872019961325756325929196058581813002404840643046271691621507677546403671954282010806041423157797170973546486726628115569923156124808066762413905989591757681932845143198849395016368313182575947314742890387780447526367065850529573409545360732184792283544657335122046047938965404774992571149865789698314241729748146943023334319000113011540774216310530508268016107235272154735009835852892749842299060764311119823575528980820809948907316616122165346751308650318747818556153406881003087722986592333293849130494158948959993772620524765670779743231832981109619140625e-1075: expected 0x0.947c9545804f2p-1022, got 0x0.0p+0 ====================================================================== FAIL: test_parsing (test.test_strtod.StrtodTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\test\test_strtod.py", line 242, in test_parsing self.check_strtod(s) File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\test\test_strtod.py", line 104, in check_strtod "expected {}, got {}".format(s, expected, got)) AssertionError: '0x0.ebdb7a968507cp-1022' != '0x0.0p+0' - 0x0.ebdb7a968507cp-1022 + 0x0.0p+0 : Incorrectly rounded str->float conversion for 20.50e-309: expected 0x0.ebdb7a968507cp-1022, got 0x0.0p+0 ====================================================================== FAIL: test_particular (test.test_strtod.StrtodTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\test\test_strtod.py", line 430, in test_particular self.check_strtod(s) File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\test\test_strtod.py", line 104, in check_strtod "expected {}, got {}".format(s, expected, got)) AssertionError: '0x0.90bbd7412d19fp-1022' != '0x0.0p+0' - 0x0.90bbd7412d19fp-1022 + 0x0.0p+0 : Incorrectly rounded str->float conversion for 12579816049008305546974391768996369464963024663104e-357: expected 0x0.90bbd7412d19fp-1022, got 0x0.0p+0 ====================================================================== FAIL: test_underflow_boundary (test.test_strtod.StrtodTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\test\test_strtod.py", line 204, in test_underflow_boundary self.check_strtod(s) File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\test\test_strtod.py", line 104, in check_strtod "expected {}, got {}".format(s, expected, got)) AssertionError: '0x0.0000000000001p-1022' != '0x0.0p+0' - 0x0.0000000000001p-1022 + 0x0.0p+0 : Incorrectly rounded str->float conversion for 24703282292062327208828439643411068618252990130716238221279284125033775364371e-400: expected 0x0.0000000000001p-1022, got 0x0.0p+0 ---------------------------------------------------------------------- May be compiler uses float instead of double? Or some FPU flag is set to handle doubles as floats? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 10:36:37 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Sat, 07 Nov 2015 15:36:37 +0000 Subject: [issue25579] def is not a keyword with tokenize.py Message-ID: <1446910597.11.0.443064601672.issue25579@psf.upfronthosting.co.za> New submission from St?phane Wirtel: For tokenize.py, 'def' is not a keyword but just a simple identifier. >>> tokens = tokenize.generate_tokens(io.StringIO('async def foo(): pass').readline) >>> pprint.pprint(list(tokens)) [TokenInfo(type=55 (ASYNC), string='async', start=(1, 0), end=(1, 5), line='async def foo(): pass'), TokenInfo(type=1 (NAME), string='def', start=(1, 6), end=(1, 9), line='async def foo(): pass'), TokenInfo(type=1 (NAME), string='foo', start=(1, 10), end=(1, 13), line='async def foo(): pass'), TokenInfo(type=53 (OP), string='(', start=(1, 13), end=(1, 14), line='async def foo(): pass'), TokenInfo(type=53 (OP), string=')', start=(1, 14), end=(1, 15), line='async def foo(): pass'), TokenInfo(type=53 (OP), string=':', start=(1, 15), end=(1, 16), line='async def foo(): pass'), TokenInfo(type=1 (NAME), string='pass', start=(1, 17), end=(1, 21), line='async def foo(): pass'), TokenInfo(type=0 (ENDMARKER), string='', start=(2, 0), end=(2, 0), line='')] >>> 'def' in keyword.kwlist True >>> tokens = tokenize.generate_tokens(io.StringIO('def foo(): pass').readline) >>> pprint.pprint(list(tokens)) [TokenInfo(type=1 (NAME), string='def', start=(1, 0), end=(1, 3), line='def foo(): pass'), TokenInfo(type=1 (NAME), string='foo', start=(1, 4), end=(1, 7), line='def foo(): pass'), TokenInfo(type=53 (OP), string='(', start=(1, 7), end=(1, 8), line='def foo(): pass'), TokenInfo(type=53 (OP), string=')', start=(1, 8), end=(1, 9), line='def foo(): pass'), TokenInfo(type=53 (OP), string=':', start=(1, 9), end=(1, 10), line='def foo(): pass'), TokenInfo(type=1 (NAME), string='pass', start=(1, 11), end=(1, 15), line='def foo(): pass'), TokenInfo(type=0 (ENDMARKER), string='', start=(2, 0), end=(2, 0), line='')] >>> Is it normal ? ---------- messages: 254277 nosy: matrixise priority: normal severity: normal status: open title: def is not a keyword with tokenize.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 10:45:45 2015 From: report at bugs.python.org (Tim Peters) Date: Sat, 07 Nov 2015 15:45:45 +0000 Subject: [issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC In-Reply-To: <1441362190.45.0.409936717424.issue24999@psf.upfronthosting.co.za> Message-ID: <1446911145.85.0.861196769998.issue24999@psf.upfronthosting.co.za> Tim Peters added the comment: If it were treating doubles as floats, you'd get a lot more failures than this. Many of these look like clear cases of treating _denormal_ doubles as 0.0, though. I have no experience with ICC, but a quick Google search suggests ICC flushes denormals to 0.0 by default, and the compiler flag "no-ftz" (no flush-to-zero) is needed to stop that; e.g., see https://software.intel.com/sites/default/files/article/326703/fp-control-2012-08.pdf ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 10:52:28 2015 From: report at bugs.python.org (SilentGhost) Date: Sat, 07 Nov 2015 15:52:28 +0000 Subject: [issue25579] def is not a keyword with tokenize.py In-Reply-To: <1446910597.11.0.443064601672.issue25579@psf.upfronthosting.co.za> Message-ID: <1446911548.49.0.399354383809.issue25579@psf.upfronthosting.co.za> SilentGhost added the comment: >>> keyword.iskeyword('pass') True There doesn't seem anything particular about def, none of the keywords have "keyword" type, because there doesn't seem to be one: https://docs.python.org/3.6/library/token.html ---------- nosy: +SilentGhost resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 10:59:11 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Sat, 07 Nov 2015 15:59:11 +0000 Subject: [issue25579] def is not a keyword with tokenize.py In-Reply-To: <1446910597.11.0.443064601672.issue25579@psf.upfronthosting.co.za> Message-ID: <1446911951.34.0.440851166226.issue25579@psf.upfronthosting.co.za> St?phane Wirtel added the comment: why do you close it ? def is not a keyword and it's a problem, how do you define a function is def is not a keyword. async is not a keyword but if you used it before 'def', async will become a keyword. have you checked the output from the tokenizer ? in the output, def is a NAME and not DEF. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 11:02:19 2015 From: report at bugs.python.org (SilentGhost) Date: Sat, 07 Nov 2015 16:02:19 +0000 Subject: [issue25580] async and await missing from token list Message-ID: <1446912139.74.0.381744244104.issue25580@psf.upfronthosting.co.za> New submission from SilentGhost: With introduction of async and await tokens in 3.5 the token documentation needs updating. ---------- assignee: docs at python components: Documentation files: token.diff keywords: patch messages: 254281 nosy: SilentGhost, docs at python priority: normal severity: normal stage: patch review status: open title: async and await missing from token list versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file40974/token.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 11:06:22 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Sat, 07 Nov 2015 16:06:22 +0000 Subject: [issue25580] async and await missing from token list In-Reply-To: <1446912139.74.0.381744244104.issue25580@psf.upfronthosting.co.za> Message-ID: <1446912382.87.0.15872083051.issue25580@psf.upfronthosting.co.za> St?phane Wirtel added the comment: With python 3.5, async is a token with the ASYNC type. >>> tokens = tokenize.generate_tokens(io.StringIO('async def foo').readline) >>> pprint.pprint(list(tokens)) [TokenInfo(type=55 (ASYNC), string='async', start=(1, 0), end=(1, 5), line='async def foo'), TokenInfo(type=1 (NAME), string='def', start=(1, 6), end=(1, 9), line='async def foo'), TokenInfo(type=1 (NAME), string='foo', start=(1, 10), end=(1, 13), line='async def foo'), TokenInfo(type=0 (ENDMARKER), string='', start=(2, 0), end=(2, 0), line='')] ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 11:06:56 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 07 Nov 2015 16:06:56 +0000 Subject: [issue25263] test_tkinter fails randomly on the buildbots "AMD64 Windows10" (3.4, 3.5, 3.x) In-Reply-To: <1443513254.01.0.657938826089.issue25263@psf.upfronthosting.co.za> Message-ID: <20151107160653.19520.25271@psf.io> Roundup Robot added the comment: New changeset d70026504feb by Serhiy Storchaka in branch 'default': Issue #25263: Trying to fix test_use on Windows. https://hg.python.org/cpython/rev/d70026504feb ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 11:07:18 2015 From: report at bugs.python.org (SilentGhost) Date: Sat, 07 Nov 2015 16:07:18 +0000 Subject: [issue25579] def is not a keyword with tokenize.py In-Reply-To: <1446910597.11.0.443064601672.issue25579@psf.upfronthosting.co.za> Message-ID: <1446912438.39.0.753727476718.issue25579@psf.upfronthosting.co.za> SilentGhost added the comment: Perhaps, my example wasn't as self-explanatory as I hoped. def is not DEF in the token list, because there isn't such a token DEF, as there isn't a token PASS or a token for any other keyword. The fact that there is an ASYNC and AWAIT tokens is something completely different and is not related to keywords as such. The link I provided lists all the tokens in the token module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 11:15:03 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 07 Nov 2015 16:15:03 +0000 Subject: [issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC In-Reply-To: <1441362190.45.0.409936717424.issue24999@psf.upfronthosting.co.za> Message-ID: <1446912903.25.0.275318311359.issue24999@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: test_audioop fails because (int)((double)0x12345678+0.0) is truncated to 0x12345680 and (int)((double)-0x456789ab+0.0) to -0x45678980. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 11:17:22 2015 From: report at bugs.python.org (Gowtham N.M) Date: Sat, 07 Nov 2015 16:17:22 +0000 Subject: [issue25345] Unable to install Python 3.5 on Windows 10 In-Reply-To: <1444326068.92.0.817766252718.issue25345@psf.upfronthosting.co.za> Message-ID: <1446913042.66.0.546347837978.issue25345@psf.upfronthosting.co.za> Gowtham N.M added the comment: Hi Eryksun, I have attached the appropriate log as requested by you. I still get the same installation error even after following the workaround suggested by you. ---------- nosy: +Gowtham N.M Added file: http://bugs.python.org/file40975/Python 3.5.0 (32-bit)_20151107214149_000_core_JustForMe.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 12:19:35 2015 From: report at bugs.python.org (Ronald Oussoren) Date: Sat, 07 Nov 2015 17:19:35 +0000 Subject: [issue25572] _ssl doesn't build on OSX 10.11 In-Reply-To: <1446845506.45.0.565617557805.issue25572@psf.upfronthosting.co.za> Message-ID: Ronald Oussoren added the comment: If I read the issue correctly the OSX 10.11 SDK doesn't include OpenSSL headers. There's not a lot we can do about that beyond documenting this in the build instructions. It might be interesting to look into using Apple's crypto APIs instead of OpenSSL but that is a significant amount of work with limited pay-off (and a risk of introducing subtle differences between the OS X port and other ports) ---------- title: _ssl doesn't build on OS X 10.11 without third-party ssl headers -> _ssl doesn't build on OSX 10.11 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 12:48:48 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 07 Nov 2015 17:48:48 +0000 Subject: [issue25345] Unable to install Python 3.5 on Windows 10 In-Reply-To: <1444326068.92.0.817766252718.issue25345@psf.upfronthosting.co.za> Message-ID: <1446918528.02.0.240300023143.issue25345@psf.upfronthosting.co.za> Steve Dower added the comment: It sounds like something went wrong during a previous installation (probably not Python 3.5) and your system is stuck in an "installing" state (hence system restore being disabled and the install mutex being held). Those two logs are a month apart but the error remains. I assume you've installed Windows updates and rebooted during that time? That should have cleared up the state, but maybe you haven't been getting updates either? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 13:01:02 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 07 Nov 2015 18:01:02 +0000 Subject: [issue24805] Python installer having problem in installing Python for all users in Windows In-Reply-To: <1438838140.75.0.258560462687.issue24805@psf.upfronthosting.co.za> Message-ID: <1446919262.72.0.0417360373319.issue24805@psf.upfronthosting.co.za> Steve Dower added the comment: I use /i, ADDLOCAL=ALL and ALLUSERS=1 with success all the time (/a does not do a real install - avoid it unless you know you'll be deploying the reduced size MSI to the rest of your network, and *especially* avoid it if you don't know why you'd want to do that). The quotes are not necessary and neither is MSIINSTALLPERUSER. I generally use /quiet or /passive rather than /qb, so that may be part of the issue. Also, your log output indicates that it was already installed when you ran that installation. Without the existing install it should be fine, but there's no way to change from a per-user install to a per-machine install with the 3.4 installer. (The 3.5 installer, except for one bug that's probably not fixable before 3.5.2, should let a user install per-user and then per-machine if they want.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 13:03:39 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 07 Nov 2015 18:03:39 +0000 Subject: [issue24805] Python installer having problem in installing Python for all users in Windows In-Reply-To: <1438838140.75.0.258560462687.issue24805@psf.upfronthosting.co.za> Message-ID: <1446919419.03.0.893159406788.issue24805@psf.upfronthosting.co.za> Steve Dower added the comment: Also, this is not a bug (and even if it was, wouldn't be fixed for 3.4), but feel free to keep discussing how to do these installs. ---------- resolution: -> not a bug stage: test needed -> status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 13:05:43 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 07 Nov 2015 18:05:43 +0000 Subject: [issue892902] problem with pickling newstyle class instances Message-ID: <20151107180540.10012.88789@psf.io> Roundup Robot added the comment: New changeset 77184a429dae by Serhiy Storchaka in branch '2.7': Issue #892902: Disable newly added tests in test_xpickle. https://hg.python.org/cpython/rev/77184a429dae ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 13:09:35 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 07 Nov 2015 18:09:35 +0000 Subject: [issue24306] Backport py.exe to 3.4 In-Reply-To: <1432771856.97.0.606443218974.issue24306@psf.upfronthosting.co.za> Message-ID: <20151107180932.115886.71823@psf.io> Roundup Robot added the comment: New changeset 6181476b5534 by Steve Dower in branch '3.4': Issue #24306: Sets component ID for launcher to match 3.5 and later to avoid downgrading. https://hg.python.org/cpython/rev/6181476b5534 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 13:09:57 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 07 Nov 2015 18:09:57 +0000 Subject: [issue24306] Backport py.exe to 3.4 In-Reply-To: <1432771856.97.0.606443218974.issue24306@psf.upfronthosting.co.za> Message-ID: <1446919797.32.0.62075727414.issue24306@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- assignee: -> steve.dower resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 13:53:50 2015 From: report at bugs.python.org (ppperry) Date: Sat, 07 Nov 2015 18:53:50 +0000 Subject: [issue25581] Python -U fails with traceback Message-ID: <1446922430.63.0.817750535883.issue25581@psf.upfronthosting.co.za> New submission from ppperry: C:\Documents and Settings\Perry>python -U Traceback (most recent call last): File "C:\Python27\lib\site.py", line 548, in main() File "C:\Python27\lib\site.py", line 537, in main aliasmbcs() File "C:\Python27\lib\site.py", line 465, in aliasmbcs import locale, codecs File "C:\Python27\lib\locale.py", line 182, in _percent_re = re.compile(r'%(?:\((?P.*?)\))?' File "C:\Python27\lib\re.py", line 194, in compile return _compile(pattern, flags) File "C:\Python27\lib\re.py", line 249, in _compile p = sre_compile.compile(pattern, flags) File "C:\Python27\lib\sre_compile.py", line 576, in compile code = _code(p, flags) File "C:\Python27\lib\sre_compile.py", line 561, in _code _compile(code, p.data, flags) File "C:\Python27\lib\sre_compile.py", line 151, in _compile _compile(code, av[1], flags) File "C:\Python27\lib\sre_compile.py", line 132, in _compile _compile(code, av[2], flags) File "C:\Python27\lib\sre_compile.py", line 107, in _compile _compile_charset(av, flags, code, fixup, fixes) File "C:\Python27\lib\sre_compile.py", line 232, in _compile_charset flags & SRE_FLAG_UNICODE): File "C:\Python27\lib\sre_compile.py", line 316, in _optimize_charset p = charmap.find(b'\1', q) TypeError: Type unicode doesn't support the buffer API ---------- messages: 254293 nosy: ppperry priority: normal severity: normal status: open title: Python -U fails with traceback _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 13:55:19 2015 From: report at bugs.python.org (ppperry) Date: Sat, 07 Nov 2015 18:55:19 +0000 Subject: [issue25581] Python -U raises error during site import In-Reply-To: <1446922430.63.0.817750535883.issue25581@psf.upfronthosting.co.za> Message-ID: <1446922519.79.0.84117341821.issue25581@psf.upfronthosting.co.za> Changes by ppperry : ---------- components: +Interpreter Core, Library (Lib), Regular Expressions nosy: +ezio.melotti, mrabarnett title: Python -U fails with traceback -> Python -U raises error during site import type: -> behavior versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 13:59:15 2015 From: report at bugs.python.org (SilentGhost) Date: Sat, 07 Nov 2015 18:59:15 +0000 Subject: [issue25581] Python -U raises error during site import In-Reply-To: <1446922430.63.0.817750535883.issue25581@psf.upfronthosting.co.za> Message-ID: <1446922755.09.0.239974532084.issue25581@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- components: +Windows -Interpreter Core, Regular Expressions nosy: +paul.moore, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 14:04:50 2015 From: report at bugs.python.org (SilentGhost) Date: Sat, 07 Nov 2015 19:04:50 +0000 Subject: [issue25581] Python -U raises error during site import In-Reply-To: <1446922430.63.0.817750535883.issue25581@psf.upfronthosting.co.za> Message-ID: <1446923090.51.0.372622205638.issue25581@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- components: +Unicode nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 15:07:46 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 07 Nov 2015 20:07:46 +0000 Subject: [issue25462] Avoid repeated hash calculation in C implementation of OrderedDict In-Reply-To: <1445537707.4.0.965290035462.issue25462@psf.upfronthosting.co.za> Message-ID: <1446926866.32.0.642034415679.issue25462@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The patch looks correct, and it improves the integrity of the C implementation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 15:18:20 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 07 Nov 2015 20:18:20 +0000 Subject: [issue25582] Fixed memory leaks in test_ctypes Message-ID: <1446927500.57.0.889992318056.issue25582@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: POINTER() saves its result in internal cache. test_pointer_type_name and test_pointer_type_str_name use large names and resulting types consume much memory. This can be one of the causes of tests failure on the AIX buildbot with very limited memory. If run tests repeatedly, the cache grows and can consume all memory even on the machine with enough memory. Proposed patch fixes leaks. ---------- components: Tests, ctypes messages: 254295 nosy: serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Fixed memory leaks in test_ctypes type: behavior versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 15:18:51 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 07 Nov 2015 20:18:51 +0000 Subject: [issue25582] Fixed memory leaks in test_ctypes In-Reply-To: <1446927500.57.0.889992318056.issue25582@psf.upfronthosting.co.za> Message-ID: <1446927531.51.0.814280067182.issue25582@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +amaury.forgeotdarc, belopolsky, meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 15:22:10 2015 From: report at bugs.python.org (Eric Snow) Date: Sat, 07 Nov 2015 20:22:10 +0000 Subject: [issue25462] Avoid repeated hash calculation in C implementation of OrderedDict In-Reply-To: <1445537707.4.0.965290035462.issue25462@psf.upfronthosting.co.za> Message-ID: <1446927730.47.0.120490872304.issue25462@psf.upfronthosting.co.za> Eric Snow added the comment: I agree with Raymond. ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 15:44:23 2015 From: report at bugs.python.org (G) Date: Sat, 07 Nov 2015 20:44:23 +0000 Subject: [issue25575] idle not working In-Reply-To: <1446866996.72.0.537757485503.issue25575@psf.upfronthosting.co.za> Message-ID: G added the comment: Hi, Thanks for getting back to me,. I will try this first thing Monday when I'm back at work. George > On Nov 6, 2015, at 8:29 PM, Zachary Ware wrote: > > > Zachary Ware added the comment: > > Check the traceback carefully, it shows exactly where the problem is, though it's not immediately obvious until it's bitten you a time or two. You are running /Users/a5/Desktop/z.py which imports turtle, but you have a turtle.py in /Users/a5/Desktop which is found before the standard library turtle. Your command line test works because it is run from a different directory. Just remove or rename /Users/a5/Desktop/turtle.py and it will work. > > There have been other reports about this lately, and there are on-going discussions about what can be done to try to prevent this situation. > > ---------- > nosy: +zach.ware > resolution: -> not a bug > stage: -> resolved > status: open -> closed > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 16:12:25 2015 From: report at bugs.python.org (ppperry) Date: Sat, 07 Nov 2015 21:12:25 +0000 Subject: [issue3559] IDLE does not handles pasted multiline statements In-Reply-To: <1218778489.95.0.525643042727.issue3559@psf.upfronthosting.co.za> Message-ID: <1446930745.83.0.133272751654.issue3559@psf.upfronthosting.co.za> Changes by ppperry : ---------- title: Pasted \n not same as typed \n -> IDLE does not handles pasted multiline statements _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 16:37:08 2015 From: report at bugs.python.org (John Mark Vandenberg) Date: Sat, 07 Nov 2015 21:37:08 +0000 Subject: [issue25179] PEP 498 f-strings need to be documented In-Reply-To: <1442688918.61.0.173837832796.issue25179@psf.upfronthosting.co.za> Message-ID: <1446932228.8.0.493960237521.issue25179@psf.upfronthosting.co.za> John Mark Vandenberg added the comment: Might be useful to add a note to PEP 257 that f-strings are not valid as docstrings . Or should f-strings be valid docstrings and raise an error if any variables present in the f-string do not exist in the outer scope? ---------- nosy: +John.Mark.Vandenberg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 16:58:21 2015 From: report at bugs.python.org (Emanuel Barry) Date: Sat, 07 Nov 2015 21:58:21 +0000 Subject: [issue25179] PEP 498 f-strings need to be documented In-Reply-To: <1442688918.61.0.173837832796.issue25179@psf.upfronthosting.co.za> Message-ID: <1446933501.13.0.157275932237.issue25179@psf.upfronthosting.co.za> Emanuel Barry added the comment: I think f-strings should be valid as docstrings. I don't know the exact details, but I think it would be harder to prevent rather than allow them. It would be exactly the same as doing func.__doc__ = func.__doc__.format(foo=foo, bar=bar) It probably wouldn't be useful in most cases, but I don't see why we should restrict the use of f-strings to non-docstrings (not counting users trying to do that and stumbling across this error). ---------- nosy: +ebarry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 17:00:50 2015 From: report at bugs.python.org (Eric V. Smith) Date: Sat, 07 Nov 2015 22:00:50 +0000 Subject: [issue25179] PEP 498 f-strings need to be documented In-Reply-To: <1442688918.61.0.173837832796.issue25179@psf.upfronthosting.co.za> Message-ID: <1446933650.54.0.0954817497948.issue25179@psf.upfronthosting.co.za> Eric V. Smith added the comment: Since f-strings are not constant strings, they cannot be used as docstrings without some modifications to the compiler. I'm not sure it's worth evaluating a docstring f-string at compile time to make them become docstrings: I can't think of a use case where this would be worthwhile. But maybe I'm not thinking hard enough. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 17:01:52 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Sat, 07 Nov 2015 22:01:52 +0000 Subject: [issue25569] Memory leak in SSLSocket.getpeercert() In-Reply-To: <1446840481.06.0.811345685129.issue25569@psf.upfronthosting.co.za> Message-ID: <1446933712.92.0.0263997930294.issue25569@psf.upfronthosting.co.za> St?phane Wirtel added the comment: sorry for the delay. here is a new version of my patch, if I can have feedback about this patch, I will really appreciate. thank you ---------- Added file: http://bugs.python.org/file40976/issue25569-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 17:04:15 2015 From: report at bugs.python.org (Eric V. Smith) Date: Sat, 07 Nov 2015 22:04:15 +0000 Subject: [issue25579] def is not a keyword with tokenize.py In-Reply-To: <1446910597.11.0.443064601672.issue25579@psf.upfronthosting.co.za> Message-ID: <1446933855.62.0.956934679818.issue25579@psf.upfronthosting.co.za> Eric V. Smith added the comment: I think the error here is that tokenize returns type=ASYNC for 'async', instead of type=NAME. ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 17:04:26 2015 From: report at bugs.python.org (Emanuel Barry) Date: Sat, 07 Nov 2015 22:04:26 +0000 Subject: [issue25179] PEP 498 f-strings need to be documented In-Reply-To: <1442688918.61.0.173837832796.issue25179@psf.upfronthosting.co.za> Message-ID: <1446933866.12.0.471415008286.issue25179@psf.upfronthosting.co.za> Emanuel Barry added the comment: I was under the impression that they would work without any additional work (as they'd have access to the outer scope). Of course, trying to access a local variable would be an error as it's not yet defined. My point is more that we shouldn't have to account for such a small case - if they can be used, then let them be used, and if they can't, then don't (unless the modification is straightforward, which it might not be). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 17:06:36 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Sat, 07 Nov 2015 22:06:36 +0000 Subject: [issue25579] def is not a keyword with tokenize.py In-Reply-To: <1446910597.11.0.443064601672.issue25579@psf.upfronthosting.co.za> Message-ID: <1446933996.36.0.761735549159.issue25579@psf.upfronthosting.co.za> St?phane Wirtel added the comment: how to know if it's an issue or not? we can ask to Yury ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 17:07:43 2015 From: report at bugs.python.org (Eric V. Smith) Date: Sat, 07 Nov 2015 22:07:43 +0000 Subject: [issue25579] def is not a keyword with tokenize.py In-Reply-To: <1446910597.11.0.443064601672.issue25579@psf.upfronthosting.co.za> Message-ID: <1446934063.7.0.183730258572.issue25579@psf.upfronthosting.co.za> Eric V. Smith added the comment: It does not currently work, because the docstring logic looks for a string, not an expression. And an f-string is an expression. It would require changing the compiler to evaluate the f-string expression. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 17:08:42 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Sat, 07 Nov 2015 22:08:42 +0000 Subject: [issue25579] def is not a keyword with tokenize.py In-Reply-To: <1446910597.11.0.443064601672.issue25579@psf.upfronthosting.co.za> Message-ID: <1446934122.37.0.244395412644.issue25579@psf.upfronthosting.co.za> St?phane Wirtel added the comment: ?? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 17:09:22 2015 From: report at bugs.python.org (Emanuel Barry) Date: Sat, 07 Nov 2015 22:09:22 +0000 Subject: [issue25579] def is not a keyword with tokenize.py In-Reply-To: <1446910597.11.0.443064601672.issue25579@psf.upfronthosting.co.za> Message-ID: <1446934162.83.0.554810285451.issue25579@psf.upfronthosting.co.za> Emanuel Barry added the comment: He probably mistook this for #25179 ---------- nosy: +ebarry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 17:10:16 2015 From: report at bugs.python.org (Eric V. Smith) Date: Sat, 07 Nov 2015 22:10:16 +0000 Subject: [issue25579] def is not a keyword with tokenize.py In-Reply-To: <1446910597.11.0.443064601672.issue25579@psf.upfronthosting.co.za> Message-ID: <1446934216.25.0.714097075692.issue25579@psf.upfronthosting.co.za> Eric V. Smith added the comment: Oops, wrong issue. Ignore my last comment. I shouldn't do two things at once. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 17:12:03 2015 From: report at bugs.python.org (Eric V. Smith) Date: Sat, 07 Nov 2015 22:12:03 +0000 Subject: [issue25179] PEP 498 f-strings need to be documented In-Reply-To: <1442688918.61.0.173837832796.issue25179@psf.upfronthosting.co.za> Message-ID: <1446934323.06.0.868829417101.issue25179@psf.upfronthosting.co.za> Eric V. Smith added the comment: It does not currently work, because the docstring logic looks for a string, not an expression. And an f-string is an expression. It would require changing the compiler to evaluate the f-string expression. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 17:13:04 2015 From: report at bugs.python.org (Emanuel Barry) Date: Sat, 07 Nov 2015 22:13:04 +0000 Subject: [issue25179] PEP 498 f-strings need to be documented In-Reply-To: <1442688918.61.0.173837832796.issue25179@psf.upfronthosting.co.za> Message-ID: <1446934384.07.0.41228406653.issue25179@psf.upfronthosting.co.za> Emanuel Barry added the comment: Well, then my bad. Pretend I didn't say anything :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 17:15:24 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 07 Nov 2015 22:15:24 +0000 Subject: [issue3559] IDLE: Pasted \n doesn't trigger execution when typed \n would In-Reply-To: <1218778489.95.0.525643042727.issue3559@psf.upfronthosting.co.za> Message-ID: <1446934524.29.0.906174050802.issue3559@psf.upfronthosting.co.za> Terry J. Reedy added the comment: ppperry, your title revision was wrong. Multiple line statements are pasted just fine, like single line statements. My original title was correct and the new one better exposes the essential point of this issue by elaborating 'not same as'. ---------- nosy: +ppperry title: IDLE does not handles pasted multiline statements -> IDLE: Pasted \n doesn't trigger execution when typed \n would _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 17:32:36 2015 From: report at bugs.python.org (ppperry) Date: Sat, 07 Nov 2015 22:32:36 +0000 Subject: [issue3559] IDLE: Pasted newline doesn't trigger execution when typed newline would In-Reply-To: <1218778489.95.0.525643042727.issue3559@psf.upfronthosting.co.za> Message-ID: <1446935556.28.0.60146039575.issue3559@psf.upfronthosting.co.za> Changes by ppperry : ---------- title: IDLE: Pasted \n doesn't trigger execution when typed \n would -> IDLE: Pasted newline doesn't trigger execution when typed newline would _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 17:48:01 2015 From: report at bugs.python.org (Bar Harel) Date: Sat, 07 Nov 2015 22:48:01 +0000 Subject: [issue25177] OverflowError in statistics.mean when summing large floats In-Reply-To: <1442662840.23.0.781753910755.issue25177@psf.upfronthosting.co.za> Message-ID: <1446936481.48.0.121506497464.issue25177@psf.upfronthosting.co.za> Bar Harel added the comment: Anyway, yes, it should be quite the same. I can provide some benchmarks tomorrow if you wish. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 18:21:51 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 07 Nov 2015 23:21:51 +0000 Subject: [issue25017] htmllib deprecated: Which library to use? Missing sane default in docs In-Reply-To: <1441616497.34.0.0999815194375.issue25017@psf.upfronthosting.co.za> Message-ID: <1446938511.04.0.895468936246.issue25017@psf.upfronthosting.co.za> R. David Murray added the comment: Yes, though I hadn't looked at it before this :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 18:38:57 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 07 Nov 2015 23:38:57 +0000 Subject: [issue19065] sqlite3 timestamp adapter chokes on timezones In-Reply-To: <1379808201.46.0.645672081963.issue19065@psf.upfronthosting.co.za> Message-ID: <1446939537.78.0.0909275444244.issue19065@psf.upfronthosting.co.za> R. David Murray added the comment: Just open an issue to propose the deprecation, if they aren't part of the DBAPI. We wouldn't actually remove them, though, until after 2.7 goes out of maintenance (if then...we still haven't quite decided what we're going to do about removals post 2.7). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 19:56:08 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 08 Nov 2015 00:56:08 +0000 Subject: [issue25545] email parsing docs: clarify that only ASCII strings are supported In-Reply-To: <1446561810.16.0.921085816129.issue25545@psf.upfronthosting.co.za> Message-ID: <1446944168.58.0.903606494132.issue25545@psf.upfronthosting.co.za> R. David Murray added the comment: Except that that might break code that is currently working, so I can't do that, even though I'd like to. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 20:16:54 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 08 Nov 2015 01:16:54 +0000 Subject: =?utf-8?q?=5Bissue25576=5D_Remove_=E2=80=9CContent-Type=3A_application/x-?= =?utf-8?q?www-form-urlencoded=3B_charset=E2=80=9D_advice?= In-Reply-To: <1446885820.73.0.0514095635951.issue25576@psf.upfronthosting.co.za> Message-ID: <1446945414.88.0.355866737647.issue25576@psf.upfronthosting.co.za> R. David Murray added the comment: Although I didn't read through the whole thing, the mozilla bug discussion indicates this is the correct way to specify the charset, it's just that there was lots of buggy software that didn't handle setting it to latin-1. Is the same true for setting it to utf-8? Agreed about the encode call. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 20:31:20 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 08 Nov 2015 01:31:20 +0000 Subject: [issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC In-Reply-To: <1441362190.45.0.409936717424.issue24999@psf.upfronthosting.co.za> Message-ID: <1446946280.79.0.0347787782649.issue24999@psf.upfronthosting.co.za> R. David Murray added the comment: FYI Intel provided us with a workaround that disables a compiler optimization for re and allows the test to not crash. Zach, can you test no-ftz? Maybe we need to apply that to the entire python compile. Also, can you make sure the appropriate person from Intel is nosy on this issue, assuming they have already registered? Tim: any idea why would this only show up on Windows? Also, if you want a copy of ICC to play with, we can arrange that. I wonder if this issue has any effect on Intel's numpy support. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 20:39:04 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 08 Nov 2015 01:39:04 +0000 Subject: [issue25572] _ssl doesn't build on OSX 10.11 In-Reply-To: <1446845399.36.0.0648529481801.issue25572@psf.upfronthosting.co.za> Message-ID: <1446946744.36.0.765677912454.issue25572@psf.upfronthosting.co.za> R. David Murray added the comment: My understanding is that when we build an osx release, we bundle openssl. So I think the appropriate solution here from our point of view is to include a pointer in the devguide about downloading and installing openssl-with-headers however it is we do that for a release build. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 21:10:23 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 08 Nov 2015 02:10:23 +0000 Subject: [issue25581] Python -U raises error during site import In-Reply-To: <1446922430.63.0.817750535883.issue25581@psf.upfronthosting.co.za> Message-ID: <1446948623.06.0.438220229768.issue25581@psf.upfronthosting.co.za> R. David Murray added the comment: Interesting, I didn't even know (remember?) about the -U flag, and it isn't documented. I guess we don't test it, and I suppose that it is effectively deprecated. (So others who don't remember don't need to repeat my research: it turns all string literals into unicode literals, which function was added as an experimental tool by Marc Andre in 2000. I believe it was later superseded by 'from __future__ import unicode_literals', but I didn't research that part.) This works fine on linux, and the traceback looks like it involves some windows-specific code. I'm not sure if this is worth bothering to fix. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 21:53:41 2015 From: report at bugs.python.org (Matthew Barnett) Date: Sun, 08 Nov 2015 02:53:41 +0000 Subject: [issue25581] Python -U raises error during site import In-Reply-To: <1446922430.63.0.817750535883.issue25581@psf.upfronthosting.co.za> Message-ID: <1446951221.84.0.953898214361.issue25581@psf.upfronthosting.co.za> Matthew Barnett added the comment: So, you write a string literal without a 'u' (or 'b') prefix, and there's no 'from __future__ import unicode_literals' in the module, so you expect it to be a bytestring, but it's not, it's a Unicode string. I'm not surprised that something breaks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 7 22:52:14 2015 From: report at bugs.python.org (Ned Deily) Date: Sun, 08 Nov 2015 03:52:14 +0000 Subject: [issue25572] _ssl doesn't build on OSX 10.11 In-Reply-To: <1446845399.36.0.0648529481801.issue25572@psf.upfronthosting.co.za> Message-ID: <1446954734.28.0.205592248529.issue25572@psf.upfronthosting.co.za> Ned Deily added the comment: "My understanding is that when we build an osx release, we bundle openssl." Well, no, we don't exactly do that today. We have recently been doing that for the 10.5 installer because the 10.5 system version of OpenSSL is so old as to be unusable for PyPI downloads (and pretty much everything else). But the much more commonly used 10.6+ installer dynamically links with the latest (but deprecated) system OpenSSL libs shipped with OS X, libs that are old but usable and still receiving Apple security fixes on current systems. The main reason for doing that is that this solution uses the Apple-provided system and user keychains for certificate management. There are other drawbacks, though, and we have an open issue to deal with that. (The python.org Pythons are not affected by the lack of headers since the libs are still shipped in OS X 10.11.) What I think this issue should address is making it easier to build Python on 10.11 (and earlier systems) with newer versions of OpenSSL. It should be easier to use OpenSSL libs supplied by popular third-party distributors like Homebrew and MacPorts. Without having thought through all the details, I'm thinking it might be best to provide a configure-time check and option, possibly with standard options for the system, Homebrew (default path), MacPorts (default path), and user-built SSL headers/libs. It would also be good to provide something which will build the handful of important missing and/or newer third-party libs needed on OS X by the interpreter and standard library, like SSL libs, liblzma, and Tk. But that's a separate issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 8 00:20:31 2015 From: report at bugs.python.org (John Mark Vandenberg) Date: Sun, 08 Nov 2015 05:20:31 +0000 Subject: [issue25545] email parsing docs: clarify that only ASCII strings are supported In-Reply-To: <1446561810.16.0.921085816129.issue25545@psf.upfronthosting.co.za> Message-ID: <1446960031.94.0.528285542578.issue25545@psf.upfronthosting.co.za> John Mark Vandenberg added the comment: Could it issue a UnicodeWarning? ---------- nosy: +John.Mark.Vandenberg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 8 00:50:09 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 08 Nov 2015 05:50:09 +0000 Subject: [issue25581] Python -U raises error during site import In-Reply-To: <1446922430.63.0.817750535883.issue25581@psf.upfronthosting.co.za> Message-ID: <1446961809.77.0.984552806764.issue25581@psf.upfronthosting.co.za> R. David Murray added the comment: Well, in this case *he* didn't write the string, it is embedded somewhere in the stdlib. 'python -U' gets you to the python prompt on unix, but apparently not on windows. But this isn't a feature we support any more, so I'm closing this as won't fix. ---------- resolution: -> wont fix stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 8 00:53:46 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 08 Nov 2015 05:53:46 +0000 Subject: [issue25581] Python -U raises error during site import In-Reply-To: <1446922430.63.0.817750535883.issue25581@psf.upfronthosting.co.za> Message-ID: <1446962026.65.0.404645314065.issue25581@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What is worse, you write a string literal with a 'b' prefix, and you get a Unicode string. >>> b'' u'' I tried to use Python with -U (it could be good way to test compatibility with Python 3), but it is totally broken, and there is no hope to fix it. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 8 00:55:37 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 08 Nov 2015 05:55:37 +0000 Subject: [issue25545] email parsing docs: clarify that only ASCII strings are supported In-Reply-To: <1446561810.16.0.921085816129.issue25545@psf.upfronthosting.co.za> Message-ID: <1446962137.19.0.876058990122.issue25545@psf.upfronthosting.co.za> R. David Murray added the comment: Issuing a warning is an interesting idea. Basically, deprecate using a non-ASCII string with message_from_string etc formally by issuing a deprecation warning as well as the doc note. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 8 01:06:04 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 08 Nov 2015 06:06:04 +0000 Subject: [issue21935] Implement AUTH command in smtpd. In-Reply-To: <1404766823.82.0.391401675174.issue21935@psf.upfronthosting.co.za> Message-ID: <20151108060601.33530.67582@psf.io> Roundup Robot added the comment: New changeset d13263ecf0c6 by R David Murray in branch '3.5': #25446: Fix regression in smtplib's AUTH LOGIN support. https://hg.python.org/cpython/rev/d13263ecf0c6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 8 01:06:05 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 08 Nov 2015 06:06:05 +0000 Subject: [issue25446] smtplib.py AUTH LOGIN code messed up sending login and password data since 3.5 In-Reply-To: <1445355692.4.0.944252984253.issue25446@psf.upfronthosting.co.za> Message-ID: <20151108060600.33530.71816@psf.io> Roundup Robot added the comment: New changeset d13263ecf0c6 by R David Murray in branch '3.5': #25446: Fix regression in smtplib's AUTH LOGIN support. https://hg.python.org/cpython/rev/d13263ecf0c6 New changeset 7368b86432c6 by R David Murray in branch 'default': Merge: #25446: Fix regression in smtplib's AUTH LOGIN support. https://hg.python.org/cpython/rev/7368b86432c6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 8 01:17:29 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 08 Nov 2015 06:17:29 +0000 Subject: [issue21935] Implement AUTH command in smtpd. In-Reply-To: <1404766823.82.0.391401675174.issue21935@psf.upfronthosting.co.za> Message-ID: <1446963449.28.0.928193029827.issue21935@psf.upfronthosting.co.za> R. David Murray added the comment: I used some of this code in writing tests for the auth_login failure in issue 25446 (thanks, Milan, you saved me a bunch of work :) Now that we have asyncio and asynchat is deprecated, we've decided that the only real purpose of smtpd going forward is the smtplib tests. Any other smtpd use should be converted to aiosmtpd instead. Perhaps that library will eventually make its way into the stdlib and test_smtplib can use it as well. So, I'm going to close this issue, but we may want to consider if and how auth fits into aiosmtpd (maybe as part of a 'testing server'). ---------- resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 8 01:19:42 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 08 Nov 2015 06:19:42 +0000 Subject: [issue25446] smtplib.py AUTH LOGIN code messed up sending login and password data since 3.5 In-Reply-To: <1445355692.4.0.944252984253.issue25446@psf.upfronthosting.co.za> Message-ID: <1446963582.53.0.126351821303.issue25446@psf.upfronthosting.co.za> R. David Murray added the comment: Fixed. I figured it was better not to wait for a review in this case...the fix is straightforward, but writing the test took quite a bit of work. The auth tests in smtplib are now much more robust, thanks in large part to Milan's code in issue 21935. ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 8 01:22:59 2015 From: report at bugs.python.org (John Mark Vandenberg) Date: Sun, 08 Nov 2015 06:22:59 +0000 Subject: [issue1650090] doctest doesn't find nested functions Message-ID: <1446963779.77.0.448149794826.issue1650090@psf.upfronthosting.co.za> Changes by John Mark Vandenberg : ---------- versions: +Python 3.4, Python 3.5, Python 3.6 -Python 3.1, Python 3.2 Added file: http://bugs.python.org/file40977/doctest_nested_functions-py3.6.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 8 02:58:46 2015 From: report at bugs.python.org (John Mark Vandenberg) Date: Sun, 08 Nov 2015 07:58:46 +0000 Subject: [issue1650090] doctest doesn't find nested functions Message-ID: <1446969526.16.0.268939236294.issue1650090@psf.upfronthosting.co.za> Changes by John Mark Vandenberg : Added file: http://bugs.python.org/file40978/doctest_nested_functions-py3.6.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 8 03:59:56 2015 From: report at bugs.python.org (STINNER Victor) Date: Sun, 08 Nov 2015 08:59:56 +0000 Subject: [issue25581] Python -U raises error during site import In-Reply-To: <1446962026.65.0.404645314065.issue25581@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Reminder: use Python 3 to get an excellent Unicode support everywhere. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 8 04:13:08 2015 From: report at bugs.python.org (SilentGhost) Date: Sun, 08 Nov 2015 09:13:08 +0000 Subject: [issue25581] Python -U raises error during site import In-Reply-To: <1446922430.63.0.817750535883.issue25581@psf.upfronthosting.co.za> Message-ID: <1446973988.74.0.170742038833.issue25581@psf.upfronthosting.co.za> SilentGhost added the comment: > Interesting, I didn't even know (remember?) about the -U flag, and it isn't documented. https://docs.python.org/2/using/cmdline.html#cmdoption-U It isn't clear when this broken or why, but I think existing documentation could be adjusted to have a bigger warning around this option. ---------- nosy: +SilentGhost _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 8 05:56:36 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 08 Nov 2015 10:56:36 +0000 Subject: =?utf-8?q?=5Bissue25576=5D_Remove_=E2=80=9CContent-Type=3A_application/x-?= =?utf-8?q?www-form-urlencoded=3B_charset=E2=80=9D_advice?= In-Reply-To: <1446885820.73.0.0514095635951.issue25576@psf.upfronthosting.co.za> Message-ID: <1446980196.52.0.665789638883.issue25576@psf.upfronthosting.co.za> Martin Panter added the comment: I think the server bugs referenced by the Mozilla bug are mainly about servers that do not recognize the content type at all, due the the presence of any charset parameter. They probably do something like ?if headers['Content-Type'] == 'application/x-www-form-urlencoded' ? without checking for parameters first. So it wouldn?t matter if it was charset=latin-1 or charset=utf-8. A couple comments in the Mozilla bug say that including ?charset? is specified by a HTTP standard, but I suspect this may be a mistake. Perhaps this is the best evidence for my argument, from : ''' Parameters on the ?application/x-www-form-urlencoded? MIME type are ignored. In particular, this MIME type does not support the ?charset? parameter. ''' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 8 06:21:00 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 08 Nov 2015 11:21:00 +0000 Subject: [issue25582] Fixed memory leaks in test_ctypes In-Reply-To: <1446927500.57.0.889992318056.issue25582@psf.upfronthosting.co.za> Message-ID: <1446981660.46.0.736259268256.issue25582@psf.upfronthosting.co.za> Martin Panter added the comment: Seems to be missing your patch ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 8 06:29:29 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 08 Nov 2015 11:29:29 +0000 Subject: [issue25580] async and await missing from token list In-Reply-To: <1446912139.74.0.381744244104.issue25580@psf.upfronthosting.co.za> Message-ID: <1446982169.65.0.824500854959.issue25580@psf.upfronthosting.co.za> Martin Panter added the comment: I wonder if the new tokens need a ?versionadded? notice. They were added in revision eeeb666a5365 for 3.5. ---------- nosy: +martin.panter, yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 8 06:30:45 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 08 Nov 2015 11:30:45 +0000 Subject: [issue24802] int and float constructing from non NUL-terminated buffer In-Reply-To: <1438830920.07.0.863152787453.issue24802@psf.upfronthosting.co.za> Message-ID: <20151108113042.10010.88749@psf.io> Roundup Robot added the comment: New changeset a13d9656f954 by Martin Panter in branch '3.5': Issue #24802: Update test case for ValueError in 3.5 https://hg.python.org/cpython/rev/a13d9656f954 New changeset 96cdd2532034 by Martin Panter in branch 'default': Issue #24802: Merge ValueError test case from 3.5 https://hg.python.org/cpython/rev/96cdd2532034 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 8 06:34:47 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 08 Nov 2015 11:34:47 +0000 Subject: [issue24802] int and float constructing from non NUL-terminated buffer In-Reply-To: <1438830920.07.0.863152787453.issue24802@psf.upfronthosting.co.za> Message-ID: <1446982487.97.0.768796623818.issue24802@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks for picking that up Serhiy ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 8 07:04:45 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 08 Nov 2015 12:04:45 +0000 Subject: [issue25582] Fixed memory leaks in test_ctypes In-Reply-To: <1446927500.57.0.889992318056.issue25582@psf.upfronthosting.co.za> Message-ID: <1446984285.3.0.0957478071506.issue25582@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Oh, sorry. Here is a patch. ---------- keywords: +patch Added file: http://bugs.python.org/file40979/ctypes_test_leak.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 8 07:28:19 2015 From: report at bugs.python.org (irdb) Date: Sun, 08 Nov 2015 12:28:19 +0000 Subject: [issue2636] Adding a new regex module (compatible with re) In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za> Message-ID: <1446985699.22.0.885971881695.issue2636@psf.upfronthosting.co.za> Changes by irdb : ---------- nosy: +irdb _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 8 07:40:21 2015 From: report at bugs.python.org (Christian Rickert) Date: Sun, 08 Nov 2015 12:40:21 +0000 Subject: [issue25570] urllib.request > Request.add_header("abcd", "efgh") fails with character ":" in first parameter string In-Reply-To: <1446842352.31.0.869437789925.issue25570@psf.upfronthosting.co.za> Message-ID: <1446986421.47.0.848395597214.issue25570@psf.upfronthosting.co.za> Christian Rickert added the comment: >>Ah, I think I see where you are coming from. I guess you aren?t intimately familiar with the HTTP protocol. Exactly. :) >>If you can given a specific comment line to add to a specific example, that might be useful. Even if you aren?t 100% sure of the details :) [OpenerDirector example] import urllib.request opener = urllib.request.build_opener() # adding custom header value to the 'User-agent' key opener.addheaders = [('User-agent', 'Mozilla/5.0')] opener.open('http://www.example.com/') "This is often used to ?spoof? the User-Agent header VALUE, which is used by a browser to identify itself ..." ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 8 09:34:33 2015 From: report at bugs.python.org (Daniel Plachotich) Date: Sun, 08 Nov 2015 14:34:33 +0000 Subject: [issue25583] os.makedirs with exist_ok=True raises PermissionError on Windows 7^ Message-ID: <1446993273.85.0.222873165522.issue25583@psf.upfronthosting.co.za> New submission from Daniel Plachotich: Since Windows 7 (or even Vista), Windows gives permission error(5, ERROR_ACCESS_DENIED if you try to create a directory in a drive root with the same name as a drive itself, even if you have administrative permissions. This behavior is not mentioned in Microsoft docs. Here is an example session (Windows 7, admin): d:\>IF EXIST . echo True True d:\>mkdir . Access is denied. d:\>mkdir dir d:\>cd dir d:\dir>mkdir . A subdirectory or file . already exists. d:\dir>cd .. d:\> d:\>py -3 Python 3.4.3 (v3.4.3:9b73f1c3e601, Feb 24 2015, 22:43:06) [MSC v.1600 32 bit (In tel)] on win32 >>> import os >>> os.path.isdir('.') True >>> os.makedirs('.', exist_ok=True) Traceback (most recent call last): File "", line 1, in File "C:\Python34\lib\os.py", line 237, in makedirs mkdir(name, mode) PermissionError: [WinError 5] ... >>> try: ... os.mkdir('.') ... except OSError as e: ... print(e.errno) ... 13 This means that if you want to write portable code, you still need to write like in Python 2: if not os.path.isdir(path): os.makedirs(path) Which makes exist_ok useless. The actual problem is in this line (Lib/os.py#l243): if not exist_ok or e.errno != errno.EEXIST or not path.isdir(name): Due the reasons described above, makedirs shouldn't rely on e.errno, so the right code will be: if not (exist_ok and path.isdir(name)): I think the issue is pretty serious to be backported. ---------- components: Library (Lib) messages: 254339 nosy: Daniel Plachotich priority: normal severity: normal status: open title: os.makedirs with exist_ok=True raises PermissionError on Windows 7^ type: behavior versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 8 10:23:43 2015 From: report at bugs.python.org (Stefan Krah) Date: Sun, 08 Nov 2015 15:23:43 +0000 Subject: [issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC In-Reply-To: <1441362190.45.0.409936717424.issue24999@psf.upfronthosting.co.za> Message-ID: <1446996223.98.0.342514239077.issue24999@psf.upfronthosting.co.za> Stefan Krah added the comment: > It looks to me that all issues are related to floating points. You need to compile with "-fp-model strict" or the Windows equivalent (I think "-fp-model precise"). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 8 10:28:19 2015 From: report at bugs.python.org (Daniel Plachotich) Date: Sun, 08 Nov 2015 15:28:19 +0000 Subject: [issue25583] os.makedirs with exist_ok=True raises PermissionError on Windows 7^ In-Reply-To: <1446993273.85.0.222873165522.issue25583@psf.upfronthosting.co.za> Message-ID: <1446996499.77.0.832739947861.issue25583@psf.upfronthosting.co.za> Daniel Plachotich added the comment: Probably better solution: if not (exist_ok and path.isdir(name) and e.errno in (errno.EEXIST, errno.EACCES)): ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 8 10:34:46 2015 From: report at bugs.python.org (Stefan Krah) Date: Sun, 08 Nov 2015 15:34:46 +0000 Subject: [issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC In-Reply-To: <1441362190.45.0.409936717424.issue24999@psf.upfronthosting.co.za> Message-ID: <1446996886.65.0.44503616741.issue24999@psf.upfronthosting.co.za> Stefan Krah added the comment: If anyone worries that "-fp-model strict" will slow things down: In the Python context these settings have no measurable impact: A while ago I tested setting/restoring the control word *for every operation*, and even that did not have any impact. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 8 10:39:41 2015 From: report at bugs.python.org (Nikolaus Rath) Date: Sun, 08 Nov 2015 15:39:41 +0000 Subject: [issue22499] [SSL: BAD_WRITE_RETRY] bad write retry in _ssl.c:1636 In-Reply-To: <1411694670.5.0.645076106925.issue22499@psf.upfronthosting.co.za> Message-ID: <1446997181.95.0.286574097876.issue22499@psf.upfronthosting.co.za> Nikolaus Rath added the comment: This just happened again to someone else, also using Python 3.4: https://bitbucket.org/nikratio/s3ql/issues/87 Is there anything the affected people can do to help debugging this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 8 10:54:35 2015 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 08 Nov 2015 15:54:35 +0000 Subject: [issue25584] a recursive glob pattern fails to list files in the current directory Message-ID: <1446998075.89.0.744136833143.issue25584@psf.upfronthosting.co.za> New submission from Xavier de Gaye: On archlinux during an upgrade, the package manager backups some files in /etc with a .pacnew extension. On my system there are 20 such files, 9 .pacnew files located in /etc and 11 .pacnew files in subdirectories of /etc. The following commands are run from /etc: $ shopt -s globstar $ ls **/*.pacnew | wc -w 20 $ ls *.pacnew | wc -w 9 With python: $ python Python 3.6.0a0 (default:72cca30f4707, Nov 2 2015, 14:17:31) [GCC 5.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import glob >>> len(glob.glob('./**/*.pacnew', recursive=True)) 20 >>> len(glob.glob('*.pacnew')) 9 >>> len(glob.glob('**/*.pacnew', recursive=True)) 11 The '**/*.pacnew' pattern does not list the files in /etc, only those located in the subdirectories of /etc. ---------- components: Library (Lib) messages: 254344 nosy: serhiy.storchaka, xdegaye priority: normal severity: normal status: open title: a recursive glob pattern fails to list files in the current directory type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 8 11:40:31 2015 From: report at bugs.python.org (anon) Date: Sun, 08 Nov 2015 16:40:31 +0000 Subject: [issue24203] Depreciate threading.Thread.isDaemon etc In-Reply-To: <1431707934.14.0.173246279453.issue24203@psf.upfronthosting.co.za> Message-ID: <1447000831.97.0.239661952239.issue24203@psf.upfronthosting.co.za> anon added the comment: Any consensus? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 8 11:41:49 2015 From: report at bugs.python.org (anon) Date: Sun, 08 Nov 2015 16:41:49 +0000 Subject: [issue19915] int.bit_at(n) - Accessing a single bit in O(1) In-Reply-To: <1386376026.32.0.661343465084.issue19915@psf.upfronthosting.co.za> Message-ID: <1447000909.51.0.625425772447.issue19915@psf.upfronthosting.co.za> anon added the comment: Any update on this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 8 12:25:27 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 08 Nov 2015 17:25:27 +0000 Subject: =?utf-8?q?=5Bissue25576=5D_Remove_=E2=80=9CContent-Type=3A_application/x-?= =?utf-8?q?www-form-urlencoded=3B_charset=E2=80=9D_advice?= In-Reply-To: <1446885820.73.0.0514095635951.issue25576@psf.upfronthosting.co.za> Message-ID: <1447003527.8.0.973248061327.issue25576@psf.upfronthosting.co.za> R. David Murray added the comment: OK, I'll accept that as authoritative :) One very minor comment in the review, otherwise looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 8 12:27:52 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 08 Nov 2015 17:27:52 +0000 Subject: [issue19883] Integer overflow in zipimport.c In-Reply-To: <1386149645.66.0.0361978088367.issue19883@psf.upfronthosting.co.za> Message-ID: <1447003672.85.0.47289988219.issue19883@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is revised patch. It addresses Gregory's comments, uses properly integer types and converters for all values, and adds additional checks for integer overflows and ZIP file validity. As a side effect the performance can be increased due to less memory allocations and IO operations. ---------- Added file: http://bugs.python.org/file40980/zipimport_int_overflow_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 8 12:36:01 2015 From: report at bugs.python.org (Laura Creighton) Date: Sun, 08 Nov 2015 17:36:01 +0000 Subject: [issue25585] Bad path leads to: ImportError: DLL load failed: %1 is not a valid Win32 application. Message-ID: <1447004161.31.0.19011460804.issue25585@psf.upfronthosting.co.za> New submission from Laura Creighton: Somebody reported this today: File "C:/Python27/kivyhello.py", line 4, in from kivy.app import App File "C:/Python27\kivy\app.py", line 316, in from kivy.base import runTouchApp, stopTouchApp File "C:/Python27\kivy\base.py", line 30, in from kivy.event import EventDispatcher File "C:/Python27\kivy\event.py", line 8, in import kivy._event ImportError: DLL load failed: %1 is not a valid Win32 application. ---------------- The problem was that they needed to set their PATH properly so kivy could be found. Couldn't we generate a more informative error message here? Is the %1 even correct? ---------- messages: 254349 nosy: lac priority: normal severity: normal status: open title: Bad path leads to: ImportError: DLL load failed: %1 is not a valid Win32 application. versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 8 12:37:42 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 08 Nov 2015 17:37:42 +0000 Subject: [issue25583] os.makedirs with exist_ok=True raises PermissionError on Windows 7^ In-Reply-To: <1446993273.85.0.222873165522.issue25583@psf.upfronthosting.co.za> Message-ID: <1447004262.91.0.908724680381.issue25583@psf.upfronthosting.co.za> R. David Murray added the comment: If you are trying to create a directory named '.' your code will not do anything useful, you might as well skip the call. What's the use case? That said, the fix looks reasonable. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 8 12:40:23 2015 From: report at bugs.python.org (SilentGhost) Date: Sun, 08 Nov 2015 17:40:23 +0000 Subject: [issue25585] Bad path leads to: ImportError: DLL load failed: %1 is not a valid Win32 application. In-Reply-To: <1447004161.31.0.19011460804.issue25585@psf.upfronthosting.co.za> Message-ID: <1447004423.36.0.361210894146.issue25585@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 8 12:42:22 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 08 Nov 2015 17:42:22 +0000 Subject: [issue19883] Integer overflow in zipimport.c In-Reply-To: <1386149645.66.0.0361978088367.issue19883@psf.upfronthosting.co.za> Message-ID: <1447004542.34.0.424834642258.issue19883@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file40980/zipimport_int_overflow_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 8 12:42:55 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 08 Nov 2015 17:42:55 +0000 Subject: [issue19883] Integer overflow in zipimport.c In-Reply-To: <1386149645.66.0.0361978088367.issue19883@psf.upfronthosting.co.za> Message-ID: <1447004575.02.0.125430988113.issue19883@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file40981/zipimport_int_overflow_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 8 12:44:20 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 08 Nov 2015 17:44:20 +0000 Subject: [issue19883] Integer overflow in zipimport.c In-Reply-To: <1386149645.66.0.0361978088367.issue19883@psf.upfronthosting.co.za> Message-ID: <1447004660.76.0.418934012748.issue19883@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file40981/zipimport_int_overflow_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 8 12:45:44 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 08 Nov 2015 17:45:44 +0000 Subject: [issue19883] Integer overflow in zipimport.c In-Reply-To: <1386149645.66.0.0361978088367.issue19883@psf.upfronthosting.co.za> Message-ID: <1447004744.45.0.693200440346.issue19883@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Sorry, the patch contained parts of the advanced patch that will be submitted in separate issue. ---------- Added file: http://bugs.python.org/file40982/zipimport_int_overflow_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 8 12:46:12 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 08 Nov 2015 17:46:12 +0000 Subject: [issue25584] a recursive glob pattern fails to list files in the current directory In-Reply-To: <1446998075.89.0.744136833143.issue25584@psf.upfronthosting.co.za> Message-ID: <1447004772.49.0.477566148602.issue25584@psf.upfronthosting.co.za> R. David Murray added the comment: I believe this behavior matches the documentation: "If the pattern is followed by an os.sep, only directories and subdirectories match." ('the pattern' being '**') I wonder if '***.pacnew' would work. ---------- nosy: +pitrou, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 8 12:50:21 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 08 Nov 2015 17:50:21 +0000 Subject: [issue25585] Bad path leads to: ImportError: DLL load failed: %1 is not a valid Win32 application. In-Reply-To: <1447004161.31.0.19011460804.issue25585@psf.upfronthosting.co.za> Message-ID: <1447005021.27.0.138954883606.issue25585@psf.upfronthosting.co.za> R. David Murray added the comment: I'm guessing that's the error we got from the OS. Maybe there's additional info we could add, though, I don't know. It would be interesting to know if it does the same thing in python3...and unfortunately it isn't as easy to change things in the python2 import system as it is in python3. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 8 13:30:59 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 08 Nov 2015 18:30:59 +0000 Subject: [issue25584] a recursive glob pattern fails to list files in the current directory In-Reply-To: <1446998075.89.0.744136833143.issue25584@psf.upfronthosting.co.za> Message-ID: <1447007459.06.0.154317697287.issue25584@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I already don't remember if it was a deliberate design, or just implementation detail. In any case it is not documented. > I believe this behavior matches the documentation: No, it is not related. It is that './**/' will list only directories, not regular files. > I wonder if '***.pacnew' would work. No, only ** as a whole path component works. ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 8 15:16:39 2015 From: report at bugs.python.org (Daniel Plachotich) Date: Sun, 08 Nov 2015 20:16:39 +0000 Subject: [issue25583] os.makedirs with exist_ok=True raises PermissionError on Windows 7^ In-Reply-To: <1446993273.85.0.222873165522.issue25583@psf.upfronthosting.co.za> Message-ID: <1447013799.69.0.951431577672.issue25583@psf.upfronthosting.co.za> Daniel Plachotich added the comment: Of course in examples I create '.' by hand, but in real code such things are mostly automatic. Assume, for example, that you have a function for downloading files: def download_file(url, save_as): ... # Before saving, you must ensure that path exists: os.makedirs(os.path.dirname(save_as), exist_ok=True) ... os.path.abspath is not a solution, because, as it was mentioned, mkdir with adrive name gives the same result: d:\>mkdir d:\\ Access is denied. Anyway, skipping the calls must be a job of exist_ok=True, otherwise it has any sense. By the way, do not pay attention to my second message(msg254341): as I said at first, mkdirs shouldn't use e.errno at all. Because, as said in docstring, makedirs must first check whether a folder exists, and only then call mkdir. But currently it works in reverse order, which, in essence, is the source of the problem. I don't know why it was done that way, because if you try "timeit" "try->mkdir->except" vs "if not isdir->mkdir", you will see that the second is much faster (x3 (!) times on Windows, x0.7 times on Linux (on ext4 partition) on my machine). So the best solution is the most straightforward - to replace try-except block with: if not path.isdir(name): mkdir(name, mode) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 8 15:35:15 2015 From: report at bugs.python.org (Daniel Plachotich) Date: Sun, 08 Nov 2015 20:35:15 +0000 Subject: [issue25583] os.makedirs with exist_ok=True raises PermissionError on Windows 7^ In-Reply-To: <1446993273.85.0.222873165522.issue25583@psf.upfronthosting.co.za> Message-ID: <1447014915.02.0.32987065794.issue25583@psf.upfronthosting.co.za> Daniel Plachotich added the comment: I meant x1.3 times faster on Linux :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 8 16:47:35 2015 From: report at bugs.python.org (Jakub Stasiak) Date: Sun, 08 Nov 2015 21:47:35 +0000 Subject: [issue25586] socket.sendall broken when a socket has a timeout Message-ID: <1447019255.89.0.976606710887.issue25586@psf.upfronthosting.co.za> New submission from Jakub Stasiak: It is my understanding that socket.sendall effectively calls the underlying socket.send's implementation in a retry loop, possibly multiple times. It is also my understanding that each one of those low level send calls can timeout on its own if a socket timeout is set. Considering the above I believe it's undesired to ever call socket.sendall with a socket that has a timeout set because if: 1. At least one send call succeeds 2. A send call after that times out then a socket timeout error will be raised and the information about the sent data will be lost. Granted, the documentation says that "On error, an exception is raised, and there is no way to determine how much data, if any, was successfully sent". I believe, however, that such API is very easy to misuse (I've seen it used with sockets with timeout set, because of small payload sizes and other circumstances it would appear to work fine most of the time and only fail every N hours or days). Possible improvements I see: 1. Explicitly mention interaction between socket's timeout and sendall's behavior in the documentation 2. Make sendall raise an error when the socket it's called with has a timeout set (I can see the backwards compatibility being a concern here but I can't think of any reason to remain compatible with behavior I believe to be broken anyway) 3. Both of the above I'm happy to procure an appropriate patch for any of the above. Please correct me if my understanding of this is off. ---------- assignee: docs at python components: Documentation, IO, Library (Lib) messages: 254357 nosy: docs at python, jstasiak priority: normal severity: normal status: open title: socket.sendall broken when a socket has a timeout type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 8 17:05:05 2015 From: report at bugs.python.org (Daniel Plachotich) Date: Sun, 08 Nov 2015 22:05:05 +0000 Subject: [issue25583] os.makedirs with exist_ok=True raises PermissionError on Windows 7^ In-Reply-To: <1446993273.85.0.222873165522.issue25583@psf.upfronthosting.co.za> Message-ID: <1447020305.83.0.978682658317.issue25583@psf.upfronthosting.co.za> Daniel Plachotich added the comment: Of course, exist_ok must be taken into account: if not (exist_ok and path.isdir(name)): mkdir(name, mode) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 8 17:06:37 2015 From: report at bugs.python.org (STINNER Victor) Date: Sun, 08 Nov 2015 22:06:37 +0000 Subject: [issue25586] socket.sendall broken when a socket has a timeout In-Reply-To: <1447019255.89.0.976606710887.issue25586@psf.upfronthosting.co.za> Message-ID: <1447020397.01.0.0690924646307.issue25586@psf.upfronthosting.co.za> STINNER Victor added the comment: FYI the behaviour of socket.socket.sendall() regarding timeout has been modified in Python 3.5: https://docs.python.org/dev/library/socket.html#socket.socket.sendall "Changed in version 3.5: The socket timeout is no more reset each time data is sent successfuly. The socket timeout is now the maximum total duration to send all data." ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 8 17:33:20 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 08 Nov 2015 22:33:20 +0000 Subject: [issue25586] socket.sendall broken when a socket has a timeout In-Reply-To: <1447019255.89.0.976606710887.issue25586@psf.upfronthosting.co.za> Message-ID: <1447022000.48.0.159838780829.issue25586@psf.upfronthosting.co.za> Martin Panter added the comment: I don?t like the sound of improvement 2. I think it would break existing use cases, e.g. HTTPConnection(timeout=...), urlopen(timeout=...). If you want a HTTP request to abort if it takes a long time, how is that behaviour broken? Regarding improvement 1, I think Victor?s 3.5 documentation explains how the timeout works fairly well. Perhaps you meant for this bug to be about pre-3.5 versions? Also, see Issue 7322 for discussion of how to handle exceptions when reading from sockets and other streams. E.g. what should readline() do when it has read half a line and then gets an exception, and should you be allowed to read again after handling an exception? In my mind the readline() and sendall() cases are somewhat complementary. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 8 18:25:05 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 08 Nov 2015 23:25:05 +0000 Subject: =?utf-8?q?=5Bissue25576=5D_Remove_=E2=80=9CContent-Type=3A_application/x-?= =?utf-8?q?www-form-urlencoded=3B_charset=E2=80=9D_advice?= In-Reply-To: <1446885820.73.0.0514095635951.issue25576@psf.upfronthosting.co.za> Message-ID: <1447025105.83.0.404865998371.issue25576@psf.upfronthosting.co.za> Martin Panter added the comment: The second version of the patch changes some more examples in the how-to to data.encode("ascii"). I?ll leave this open for a bit in case Senthil is around and wants to comment (seeing as he added the text I am removing). ---------- Added file: http://bugs.python.org/file40983/urlencoded-charset.2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 8 20:04:16 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 09 Nov 2015 01:04:16 +0000 Subject: [issue25570] urllib.request > Request.add_header("abcd", "efgh") fails with character ":" in first parameter string In-Reply-To: <1446842352.31.0.869437789925.issue25570@psf.upfronthosting.co.za> Message-ID: <1447031056.27.0.145124424012.issue25570@psf.upfronthosting.co.za> Martin Panter added the comment: Hmm, I wonder if that OpenerDirector example is a bit obscure. Normally you would use the default urlopen() to set User-Agent, without resorting to a custom OpenerDirector. In my patch: * Included ?User-Agent header _value_? in the ?headers? parameter description * Linked to from examples section * Added add_header("User-Agent", ...) example with made-up custom value Let me know what you think (if anything is unnecessary, other suggestions?) ---------- assignee: -> docs at python components: +Documentation -Library (Lib) keywords: +patch nosy: +docs at python stage: needs patch -> patch review type: behavior -> enhancement versions: +Python 2.7, Python 3.4, Python 3.6 Added file: http://bugs.python.org/file40984/add_header.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 8 20:19:16 2015 From: report at bugs.python.org (Jakub Stasiak) Date: Mon, 09 Nov 2015 01:19:16 +0000 Subject: [issue25586] socket.sendall broken when a socket has a timeout In-Reply-To: <1447019255.89.0.976606710887.issue25586@psf.upfronthosting.co.za> Message-ID: <1447031955.98.0.42419160088.issue25586@psf.upfronthosting.co.za> Jakub Stasiak added the comment: Martin: While I'd consider timeout in HTTPConnection(timeout=...) or urlopen(timeout=...) to be the timeout for the entire operation, just just for the data sending part and HTTPConnection/urlopen can achieve the timeout behavior using just send I concede there may be valid use cases for "either sendall succeeds or we don't care about what we've sent anyway" and in this light my second suggestion is problematic. Victor: The behavior change in 3.5 does't affect my concern from what I see. The concern is sendall timing out after some data has already been sent which can create some subtle issues. I've seen code like this: def x(data, sock): while True: # some code here try: sock.sendall(data) return except timeout: pass Now I'll agree the code is at fault for ever attempting to retry sendall but I also think the API is easy to misuse like this. And it many cases it'll just work most of the time because sendall won't timeout. Maybe explicitly mentioning sendall's behavior concerning sockets with timeouts could improve this? I'm honestly not sure anymore, technically "On error, an exception is raised, and there is no way to determine how much data, if any, was successfully sent." should be enough. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 8 20:45:25 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 09 Nov 2015 01:45:25 +0000 Subject: [issue25586] socket.sendall broken when a socket has a timeout In-Reply-To: <1447019255.89.0.976606710887.issue25586@psf.upfronthosting.co.za> Message-ID: <1447033525.97.0.817889389157.issue25586@psf.upfronthosting.co.za> Martin Panter added the comment: Maybe it would be reasonable to expand on that ?On error? sentence. I imagine the main errors that would cause this situation are a timeout as you say, and also a blocking exception. Also, you could point out that if you have lost record of how much has already been sent, it may not make sense to send any more data with the same socket. ---------- versions: -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 8 23:05:48 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 09 Nov 2015 04:05:48 +0000 Subject: [issue25583] os.makedirs with exist_ok=True raises PermissionError on Windows 7^ In-Reply-To: <1446993273.85.0.222873165522.issue25583@psf.upfronthosting.co.za> Message-ID: <1447041948.95.0.16566901989.issue25583@psf.upfronthosting.co.za> Martin Panter added the comment: Daniel: your latest suggestions look like they introduce a race condition. What happens if another thread or process, perhaps also calling makedirs(), creates the directory just after isdir() says it doesn?t exist? Similar to Issue 1608579. Perhaps the existing code comment needs to clarify that the exception handling is for a real race condition, not just an excuse to ?be happy? :) ---------- components: +Windows nosy: +martin.panter, paul.moore, steve.dower, tim.golden, zach.ware stage: -> needs patch versions: -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 8 23:39:57 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 09 Nov 2015 04:39:57 +0000 Subject: [issue25584] a recursive glob pattern fails to list files in the current directory In-Reply-To: <1446998075.89.0.744136833143.issue25584@psf.upfronthosting.co.za> Message-ID: <1447043997.5.0.126488989221.issue25584@psf.upfronthosting.co.za> R. David Murray added the comment: Ah, I see, 'pattern' there means the whole pattern. That certainly isn't clear. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 00:44:35 2015 From: report at bugs.python.org (Jim Nasby) Date: Mon, 09 Nov 2015 05:44:35 +0000 Subject: [issue25587] Useless addition in PyTuple_New Message-ID: <1447047875.1.0.253447135487.issue25587@psf.upfronthosting.co.za> New submission from Jim Nasby: In PyTuple_New, if the new tuple won't go on the free_list: /* Check for overflow */ if (nbytes / sizeof(PyObject *) != (size_t)size || (nbytes > PY_SSIZE_T_MAX - sizeof(PyTupleObject) - sizeof(PyObject *))) { return PyErr_NoMemory(); } nbytes += sizeof(PyTupleObject) - sizeof(PyObject *); nbytes is never used after the overflow check, so the last addition is a waste. ---------- messages: 254367 nosy: Jim Nasby priority: normal severity: normal status: open title: Useless addition in PyTuple_New type: performance versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 01:02:01 2015 From: report at bugs.python.org (eryksun) Date: Mon, 09 Nov 2015 06:02:01 +0000 Subject: [issue25585] Bad path leads to: ImportError: DLL load failed: %1 is not a valid Win32 application. In-Reply-To: <1447004161.31.0.19011460804.issue25585@psf.upfronthosting.co.za> Message-ID: <1447048921.05.0.547011219008.issue25585@psf.upfronthosting.co.za> eryksun added the comment: The "DLL load failed" message is from Python, but the rest is the text for the Windows error code, ERROR_BAD_EXE_FORMAT (0x00c1) [1]. The "%1" in the string can be expanded as the first element of the Arguments array parameter of FormatMessage [2]. But currently the code in Python/dynload_win.c uses FORMAT_MESSAGE_IGNORE_INSERTS and does no post-processing to replace the "%1". I don't know why the Windows loader reported ERROR_BAD_EXE_FORMAT instead of ERROR_MOD_NOT_FOUND. Possibly it found another version of a dependent DLL that was corrupt or for a different architecture. Note that the setup in this case is odd in that the package is installed in C:\Python27 instead of in the site-packages directory. [1]: https://msdn.microsoft.com/en-us/library/ms681382#ERROR_BAD_EXE_FORMAT [2]: https://msdn.microsoft.com/en-us/library/ms679351 ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 01:07:10 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 09 Nov 2015 06:07:10 +0000 Subject: [issue2275] Make urllib.request.Request.has_header() etc case-insensitive In-Reply-To: <1205270540.47.0.336665756101.issue2275@psf.upfronthosting.co.za> Message-ID: <1447049230.62.0.974787714209.issue2275@psf.upfronthosting.co.za> Martin Panter added the comment: Please review insensitive-lookup.patch: * Adapt John?s patch to current code * Apply similar changes to Request.remove_header() * Expanded on case-insensitivity, previous capitalize() requirements, and header_items() casing in the documentation * Dropped testing of unredirected_hdrs and of headers being case-sensitive. I think these are implementation details, and are not part of the implicit API from before the has_header() etc methods. * Reverted unnecessary test removal in test case * Added What?s New entry ---------- stage: needs patch -> patch review versions: +Python 3.6 -Python 3.3 Added file: http://bugs.python.org/file40985/insensitive-lookup.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 02:14:45 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 09 Nov 2015 07:14:45 +0000 Subject: [issue25584] a recursive glob pattern fails to list files in the current directory In-Reply-To: <1446998075.89.0.744136833143.issue25584@psf.upfronthosting.co.za> Message-ID: <1447053285.34.0.844997607795.issue25584@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Likely it was implementation artifact. Current implementation is simpler butter fitted existing glob design. The problem was that '**/a' should list 'a' and 'd/a', but '**/' should list only 'd/', and not ''. Here is a patch that makes '**' to match also zero directories. Old tests were passed, new tests are added to cover this case. ---------- keywords: +patch stage: -> patch review versions: +Python 3.5 Added file: http://bugs.python.org/file40986/rglob_zero_dirs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 03:04:43 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 09 Nov 2015 08:04:43 +0000 Subject: [issue25588] Run test suite from IDLE idlelib.run subprocess Message-ID: <1447056283.03.0.330229894782.issue25588@psf.upfronthosting.co.za> New submission from Terry J. Reedy: This issue proposes stress testing idlelib.run by running code that already reports whether results are as expected or not -- the test_suite. Since this one test will take at least as long as the test suite, and will probably need human intervention anyway, it would not be part of test_idle, but would be run separately manually, like htest. IDLE runs user code in a user process started with subprocess.POpen(executable + 'path/to/idlelib/run.py' + args + user_code_path) (with user_code_path omitted for shell restarts). When run from the editor, the intent is to imitate 'python -i user_code_path'. On python list, someone reported that running a program using pyqt5 (and qt5) hung on exit while running with python3 (on Ubuntu, no -i) worked. I have asked for more details, including whether it works with -i included. In the meanwhile, I wondered ... While the run module might not be able to run programs with certain 3rd party imports, can it at least run programs restricted to stdlib imports and well enough behaved to run with python -i. (A programs that, for instance, disables standard i/o streams would fail both in IDLE and with python.) A test would be to at least run all stdlib tests, with the same result, as run otherwise on the same system. The tests should be run in the user process itself and not in additional processes. They could be run either all in one process or each in a new run process. If successful, I will put code and instructions in a new idlelib/idle_test/rtest.py/txt. ---------- assignee: terry.reedy components: IDLE, Tests messages: 254371 nosy: terry.reedy priority: normal severity: normal stage: needs patch status: open title: Run test suite from IDLE idlelib.run subprocess type: enhancement versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 03:45:36 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 09 Nov 2015 08:45:36 +0000 Subject: [issue25584] a recursive glob pattern fails to list files in the current directory In-Reply-To: <1446998075.89.0.744136833143.issue25584@psf.upfronthosting.co.za> Message-ID: <1447058736.33.0.0176705227507.issue25584@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file40987/rglob_zero_dirs_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 03:51:12 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 09 Nov 2015 08:51:12 +0000 Subject: [issue25587] Useless addition in PyTuple_New In-Reply-To: <1447047875.1.0.253447135487.issue25587@psf.upfronthosting.co.za> Message-ID: <1447059072.28.0.909818276915.issue25587@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: There is no such code in current sources. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 03:59:00 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 09 Nov 2015 08:59:00 +0000 Subject: [issue7267] format method: c presentation type broken in 2.7 In-Reply-To: <1257438168.68.0.774312526176.issue7267@psf.upfronthosting.co.za> Message-ID: <1447059540.92.0.500732442996.issue7267@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 04:02:43 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 09 Nov 2015 09:02:43 +0000 Subject: [issue21818] cookielib documentation references Cookie module, not cookielib.Cookie class In-Reply-To: <1403306887.99.0.626699628104.issue21818@psf.upfronthosting.co.za> Message-ID: <1447059763.17.0.685210108314.issue21818@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Georg, is it possible to tune Sphinx rules? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 04:17:11 2015 From: report at bugs.python.org (Jakub Stasiak) Date: Mon, 09 Nov 2015 09:17:11 +0000 Subject: [issue25586] socket.sendall broken when a socket has a timeout In-Reply-To: <1447019255.89.0.976606710887.issue25586@psf.upfronthosting.co.za> Message-ID: <1447060631.88.0.0468313256052.issue25586@psf.upfronthosting.co.za> Jakub Stasiak added the comment: This is exactly what I'm thinking. Do you think it's sensible to move that sentence + some additional information (following your suggestion) into a "Warning" block? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 05:14:57 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 09 Nov 2015 10:14:57 +0000 Subject: [issue7267] format method: c presentation type broken in 2.7 In-Reply-To: <1257438168.68.0.774312526176.issue7267@psf.upfronthosting.co.za> Message-ID: <1447064097.57.0.7582748763.issue7267@psf.upfronthosting.co.za> STINNER Victor added the comment: > Both ways, with OverflowError and Py3k DeprecationWarning, are good to me. What would you say about this Benjamin? I prefer an OverflowError. I don't like having to enable a flag to fix a bug :-( According to the issue title, it's really a bug: "format method: c presentation type *broken* in 2.7". Note: The unit test may check the error message, currently the error message is irrevelant (it mentions unicode whereas bytes (str type) are used). >>> format(-1, "c") OverflowError: %c arg not in range(0x110000) (wide Python build) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 05:20:48 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 09 Nov 2015 10:20:48 +0000 Subject: [issue22643] Integer overflow in case_operation In-Reply-To: <1413384630.17.0.213972312804.issue22643@psf.upfronthosting.co.za> Message-ID: <1447064448.3.0.25367403651.issue22643@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 05:43:43 2015 From: report at bugs.python.org (Daniel Plachotich) Date: Mon, 09 Nov 2015 10:43:43 +0000 Subject: [issue25583] os.makedirs with exist_ok=True raises PermissionError on Windows 7^ In-Reply-To: <1446993273.85.0.222873165522.issue25583@psf.upfronthosting.co.za> Message-ID: <1447065823.49.0.931702942151.issue25583@psf.upfronthosting.co.za> Daniel Plachotich added the comment: Maybe the solution is to leave OSError catching after the conditional (probably with some additional comments): if not (exist_ok and path.isdir(name)): try: mkdir(name, mode) except OSError as e: if not exist_ok or e.errno != errno.EEXIST or not path.isdir(name): raise This should solve the problem. It also gives more or less guarantee that errno will be EEXIST, while the current code will also raise an exception on EROFS (read-only FS), ENOSPC (no space left) in addition to EACCES on Windows (and possibly some other values on various systems - who knows?). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 05:51:06 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 09 Nov 2015 10:51:06 +0000 Subject: [issue7267] format method: c presentation type broken in 2.7 In-Reply-To: <1257438168.68.0.774312526176.issue7267@psf.upfronthosting.co.za> Message-ID: <1447066266.92.0.433685194783.issue7267@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Then feel free to commit your patch please. It LGTM. ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 06:22:22 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 09 Nov 2015 11:22:22 +0000 Subject: [issue7267] format method: c presentation type broken in 2.7 In-Reply-To: <1257438168.68.0.774312526176.issue7267@psf.upfronthosting.co.za> Message-ID: <20151109112219.58407.66943@psf.io> Roundup Robot added the comment: New changeset 2f2c52c9ff38 by Victor Stinner in branch '2.7': Issue #7267: format(int, 'c') now raises OverflowError when the argument is not https://hg.python.org/cpython/rev/2f2c52c9ff38 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 06:23:06 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 09 Nov 2015 11:23:06 +0000 Subject: [issue7267] format method: c presentation type broken in 2.7 In-Reply-To: <1257438168.68.0.774312526176.issue7267@psf.upfronthosting.co.za> Message-ID: <1447068186.52.0.361409829124.issue7267@psf.upfronthosting.co.za> STINNER Victor added the comment: > Then feel free to commit your patch please. It LGTM. Thanks for the review ;-) @Walter: Sorry for the late fix (6 years later!). ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 06:56:49 2015 From: report at bugs.python.org (Herbert) Date: Mon, 09 Nov 2015 11:56:49 +0000 Subject: [issue25465] Pickle uses O(n) memory overhead In-Reply-To: <1445593043.5.0.334623277706.issue25465@psf.upfronthosting.co.za> Message-ID: <1447070209.66.0.828620324862.issue25465@psf.upfronthosting.co.za> Herbert added the comment: It may be fair to note that I have no swap installed on one of the machines, just 16GB of RAM, on which the 'crash' happens. Hence I'm not sure how this affects paging, I would think there is no paging if there is no swap. I can verify that the machine is 'stuck' for more than just several minutes (at least 30 minutes), nevertheless cannot confirm if this is due to the desktop environment or actually the kernel. I would agree to verify this first when I have access to the specific machines again. Thank you for your input so far! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 07:26:15 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 09 Nov 2015 12:26:15 +0000 Subject: [issue25263] test_tkinter fails randomly on the buildbots "AMD64 Windows10" (3.4, 3.5, 3.x) In-Reply-To: <1443513254.01.0.657938826089.issue25263@psf.upfronthosting.co.za> Message-ID: <1447071975.12.0.0455253040534.issue25263@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Didn't help. http://buildbot.python.org/all/builders/AMD64%20Windows8%203.x/builds/1494/steps/test/logs/stdio ====================================================================== ERROR: test_use (tkinter.test.test_tkinter.test_widgets.ToplevelTest) (wid='0xffffffffbf300038') ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\buildarea\3.x.bolen-windows8\build\lib\tkinter\test\test_tkinter\test_widgets.py", line 96, in test_use widget2 = self.create(use=wid) File "D:\buildarea\3.x.bolen-windows8\build\lib\tkinter\test\test_tkinter\test_widgets.py", line 70, in create return tkinter.Toplevel(self.root, **kwargs) File "D:\buildarea\3.x.bolen-windows8\build\lib\tkinter\__init__.py", line 2181, in __init__ BaseWidget.__init__(self, master, 'toplevel', cnf, {}, extra) File "D:\buildarea\3.x.bolen-windows8\build\lib\tkinter\__init__.py", line 2138, in __init__ (widgetName, self._w) + extra + self._options(cnf)) _tkinter.TclError: integer value too large to represent ---------------------------------------------------------------------- ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 07:38:45 2015 From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=) Date: Mon, 09 Nov 2015 12:38:45 +0000 Subject: [issue7267] format method: c presentation type broken in 2.7 In-Reply-To: <1257438168.68.0.774312526176.issue7267@psf.upfronthosting.co.za> Message-ID: <1447072725.91.0.108326523613.issue7267@psf.upfronthosting.co.za> Walter D?rwald added the comment: Don't worry, I've switched to using Python 3 in 2012, where this isn't a problem. ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 07:44:04 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 09 Nov 2015 12:44:04 +0000 Subject: [issue25263] test_tkinter fails randomly on the buildbots "AMD64 Windows10" (3.4, 3.5, 3.x) In-Reply-To: <1443513254.01.0.657938826089.issue25263@psf.upfronthosting.co.za> Message-ID: <20151109124401.24926.95179@psf.io> Roundup Robot added the comment: New changeset 3f8998c2fbf9 by Serhiy Storchaka in branch 'default': Issue #25263: Trying to fix test_use on Windows. https://hg.python.org/cpython/rev/3f8998c2fbf9 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 07:44:33 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 09 Nov 2015 12:44:33 +0000 Subject: [issue25587] Useless addition in PyTuple_New In-Reply-To: <1447047875.1.0.253447135487.issue25587@psf.upfronthosting.co.za> Message-ID: <1447073073.65.0.825275028394.issue25587@psf.upfronthosting.co.za> STINNER Victor added the comment: The line "nbytes += " was removed 5 years ago by the changeset 7be8129ee0fd. It's maybe time to update your Python version? :-) Only Python < 2.7 has the line, it was removed before Python 2.7.0 was tagged. ---------- nosy: +haypo resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 08:03:51 2015 From: report at bugs.python.org (Xavier de Gaye) Date: Mon, 09 Nov 2015 13:03:51 +0000 Subject: [issue25584] a recursive glob pattern fails to list files in the current directory In-Reply-To: <1446998075.89.0.744136833143.issue25584@psf.upfronthosting.co.za> Message-ID: <1447074231.32.0.544471315026.issue25584@psf.upfronthosting.co.za> Xavier de Gaye added the comment: FWIW the patch looks good to me. I find the code in glob.py difficult to read as it happily joins regular filenames together with os.path.join() or attempts to list the files contained into a regular file (sic). The attached diff makes the code more correct and easier to understand. It is meant to be applied on top of Serhiy's patch. ---------- Added file: http://bugs.python.org/file40988/rglob_isdir.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 08:16:51 2015 From: report at bugs.python.org (Stefan Krah) Date: Mon, 09 Nov 2015 13:16:51 +0000 Subject: [issue25465] Pickle uses O(n) memory overhead In-Reply-To: <1445593043.5.0.334623277706.issue25465@psf.upfronthosting.co.za> Message-ID: <1447075011.93.0.413012657331.issue25465@psf.upfronthosting.co.za> Stefan Krah added the comment: It's a Linux issue. Disable overcommitting of memory (at your own peril) or set user limits (for example with djb's softlimit), then the process will be killed instead of freezing the machine. ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 08:51:20 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 09 Nov 2015 13:51:20 +0000 Subject: [issue25263] test_tkinter fails randomly on the buildbots "AMD64 Windows10" (3.4, 3.5, 3.x) In-Reply-To: <1443513254.01.0.657938826089.issue25263@psf.upfronthosting.co.za> Message-ID: <1447077080.43.0.0597259483724.issue25263@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Looks as there is also Tk bug. Perhaps on Windows (and Unix?) "winfo id" can return 64-bit integer, but the -use option works only with 32-bit integers. Opened Tk ticket: http://core.tcl.tk/tk/tktview?name=5ee8af61e5 . ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 09:28:20 2015 From: report at bugs.python.org (Stefan Krah) Date: Mon, 09 Nov 2015 14:28:20 +0000 Subject: [issue22499] [SSL: BAD_WRITE_RETRY] bad write retry in _ssl.c:1636 In-Reply-To: <1411694670.5.0.645076106925.issue22499@psf.upfronthosting.co.za> Message-ID: <1447079300.54.0.791775602833.issue22499@psf.upfronthosting.co.za> Stefan Krah added the comment: I had a similar issue with ucspi-ssl that was fixed by following the O'Reilly book's recommendations w.r.t WANT_READ/WANT_WRITE with non-blocking sockets to the letter. The recommendations are quite complex since apparently WANT_READ/WANT_WRITE mean different things depending on whether they occur *during a read* or *during a write*. I haven't used Python's SSL module much: Since those flags are exposed on the Python level, are users supposed to take care of the above issues themselves for non-blocking sockets? ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 09:37:24 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 09 Nov 2015 14:37:24 +0000 Subject: [issue25465] Pickle uses O(n) memory overhead In-Reply-To: <1445593043.5.0.334623277706.issue25465@psf.upfronthosting.co.za> Message-ID: <1447079844.4.0.863132392655.issue25465@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: There is a workaround for memory consumption, and Linux freezing is not Python issue. ---------- resolution: -> wont fix stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 10:29:28 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 09 Nov 2015 15:29:28 +0000 Subject: [issue7267] format method: c presentation type broken in 2.7 In-Reply-To: <1447072725.91.0.108326523613.issue7267@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Walter D?rwald added the comment: > Don't worry, I've switched to using Python 3 in 2012, where this isn't a problem. ;) Wow, cool! We still have 1 or 2 customers stuck with Python 2, haha. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 11:07:38 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 09 Nov 2015 16:07:38 +0000 Subject: [issue25585] Bad path leads to: ImportError: DLL load failed: %1 is not a valid Win32 application. In-Reply-To: <1447004161.31.0.19011460804.issue25585@psf.upfronthosting.co.za> Message-ID: <1447085258.55.0.0377075472527.issue25585@psf.upfronthosting.co.za> R. David Murray added the comment: OK, so it sounds like there are improvements we could make here if someone wants to work on it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 11:16:35 2015 From: report at bugs.python.org (Zachary Ware) Date: Mon, 09 Nov 2015 16:16:35 +0000 Subject: [issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC In-Reply-To: <1441362190.45.0.409936717424.issue24999@psf.upfronthosting.co.za> Message-ID: <1447085794.99.0.770086675877.issue24999@psf.upfronthosting.co.za> Zachary Ware added the comment: Stefan Krah wrote: > If anyone worries that "-fp-model strict" will slow > things down: In the Python context these settings have > no measurable impact: A while ago I tested setting/restoring > the control word *for every operation*, and even that did > not have any impact. If that's the case, would anyone (in particular, Steve, Tim or Tim) mind if we just made the default (for MSVC as well as ICC) /fp:strict? It would be much easier to just change the global default than to try to either make it settable or to change it just when ICC is used. As far as the segfault that this issue is actually about, compiling _sre.c with /Os seems to clear it up. I believe Intel is looking into it deeper to determine whether it's an ICC bug or if there's something we should change in _sre.c. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 11:19:10 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 09 Nov 2015 16:19:10 +0000 Subject: [issue25585] Bad path leads to: ImportError: DLL load failed: %1 is not a valid Win32 application. In-Reply-To: <1447004161.31.0.19011460804.issue25585@psf.upfronthosting.co.za> Message-ID: <1447085950.07.0.936135478453.issue25585@psf.upfronthosting.co.za> STINNER Victor added the comment: Does Windows provide a function to format a string using %1, %2, etc.? Note: Python 3.6 uses the same code than Python 2.7. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 12:12:09 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 09 Nov 2015 17:12:09 +0000 Subject: [issue25585] Bad path leads to: ImportError: DLL load failed: %1 is not a valid Win32 application. In-Reply-To: <1447004161.31.0.19011460804.issue25585@psf.upfronthosting.co.za> Message-ID: <1447089129.71.0.638828476977.issue25585@psf.upfronthosting.co.za> Steve Dower added the comment: It does, but you need to identify the error code precisely and use that to provide the parameters when obtaining the message. It's more about localization than a general way of obtaining error text. Better off just using our own message in this case (which is probably a breaking change for 2.7...) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 12:37:54 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 09 Nov 2015 17:37:54 +0000 Subject: [issue24999] ICC compiler: ICC treats denormal floating point numbers as 0.0 In-Reply-To: <1441362190.45.0.409936717424.issue24999@psf.upfronthosting.co.za> Message-ID: <1447090674.25.0.586802575434.issue24999@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC -> ICC compiler: ICC treats denormal floating point numbers as 0.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 12:59:50 2015 From: report at bugs.python.org (Georg Brandl) Date: Mon, 09 Nov 2015 17:59:50 +0000 Subject: [issue21818] cookielib documentation references Cookie module, not cookielib.Cookie class In-Reply-To: <1403306887.99.0.626699628104.issue21818@psf.upfronthosting.co.za> Message-ID: <1447091990.45.0.211834322685.issue21818@psf.upfronthosting.co.za> Georg Brandl added the comment: The rules are as they are mostly for backwards compatibility. But it is rarely a problem since there is only one object with a given name. :class:`Cookie` within the docs for cookielib would not be able to link to Cookie.Cookie since it is not found in its scope. :class:`Cookie.Cookie` works, as does :class:`~Cookie.Cookie`. When you use the "find-in-any-namespace" syntax, i.e. :class:`.Cookie` the type *will* be taken into account. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 13:02:23 2015 From: report at bugs.python.org (Xavier de Gaye) Date: Mon, 09 Nov 2015 18:02:23 +0000 Subject: [issue25584] a recursive glob pattern fails to list files in the current directory In-Reply-To: <1446998075.89.0.744136833143.issue25584@psf.upfronthosting.co.za> Message-ID: <1447092143.63.0.810696806037.issue25584@psf.upfronthosting.co.za> Xavier de Gaye added the comment: glob('invalid_dir/**', recursive=True) triggers the assert that was added by my patch in _rlistdir(). This new patch fixes this: when there is no magic character in the dirname part of a split(), and dirname is not an existing directory, then there is nothing to yield and the processing of pathname must stop (and thus in this case, no call is made to glob2() when basename is '**'). ---------- Added file: http://bugs.python.org/file40989/rglob_isdir_2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 13:30:53 2015 From: report at bugs.python.org (Chris Hogan) Date: Mon, 09 Nov 2015 18:30:53 +0000 Subject: [issue25589] test_ascii_formatd fails on Mac when built with Intel compiler Message-ID: <1447093853.5.0.154282338345.issue25589@psf.upfronthosting.co.za> New submission from Chris Hogan: I successfully built Python on OS X 10.10 with the Intel compiler v15. However, running the regression tests gives me a "segmentation fault: 11" on test_ascii_formated. I think this has to do with libffi, because when I build with the --use-system-ffi flag (using a libffi that I built) all the regression tests pass, but I get a seg fault when I try to import ctypes. Using python's libffi I can import ctypes, but I get seg faults in the tests. Looking at libffi's homepage, it looks like x86-64 Mac OS X isn't on the list of officially supported platforms. I tried contacting the libffi-discuss mailing list about this but have received no response in a month. Please let me know what other information I can provide. ---------- components: Macintosh, Tests messages: 254398 nosy: christopher.hogan, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: test_ascii_formatd fails on Mac when built with Intel compiler type: crash versions: Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 14:16:53 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 09 Nov 2015 19:16:53 +0000 Subject: [issue7267] format method: c presentation type broken in 2.7 In-Reply-To: <1257438168.68.0.774312526176.issue7267@psf.upfronthosting.co.za> Message-ID: <1447096613.12.0.257056123254.issue7267@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: commit review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 15:15:20 2015 From: report at bugs.python.org (Zachary Ware) Date: Mon, 09 Nov 2015 20:15:20 +0000 Subject: [issue25589] test_ascii_formatd fails on Mac when built with Intel compiler In-Reply-To: <1447093853.5.0.154282338345.issue25589@psf.upfronthosting.co.za> Message-ID: <1447100120.87.0.307747651612.issue25589@psf.upfronthosting.co.za> Zachary Ware added the comment: This doesn't seem to be a problem on the ICC buildbot; David, did you do anything special for libffi/ctypes? ---------- nosy: +r.david.murray, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 15:15:45 2015 From: report at bugs.python.org (Zachary Ware) Date: Mon, 09 Nov 2015 20:15:45 +0000 Subject: [issue25589] test_ascii_formatd fails on Mac when built with Intel compiler In-Reply-To: <1447093853.5.0.154282338345.issue25589@psf.upfronthosting.co.za> Message-ID: <1447100145.94.0.581402525282.issue25589@psf.upfronthosting.co.za> Zachary Ware added the comment: Also, I haven't had an issue with this on my own machine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 15:34:25 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 09 Nov 2015 20:34:25 +0000 Subject: [issue25582] Fixed memory leaks in test_ctypes In-Reply-To: <1446927500.57.0.889992318056.issue25582@psf.upfronthosting.co.za> Message-ID: <20151109203421.103690.40758@psf.io> Roundup Robot added the comment: New changeset e5d7cf9d6469 by Serhiy Storchaka in branch '3.4': Issue #25582: Fixed 100 MB memory leak in test_ctypes. https://hg.python.org/cpython/rev/e5d7cf9d6469 New changeset f14f6bce3321 by Serhiy Storchaka in branch '2.7': Issue #25582: Fixed 100 MB memory leak in test_ctypes. https://hg.python.org/cpython/rev/f14f6bce3321 New changeset ad4c6f4af909 by Serhiy Storchaka in branch '3.5': Issue #25582: Fixed 100 MB memory leak in test_ctypes. https://hg.python.org/cpython/rev/ad4c6f4af909 New changeset a6f6d8a6152f by Serhiy Storchaka in branch 'default': Issue #25582: Fixed 100 MB memory leak in test_ctypes. https://hg.python.org/cpython/rev/a6f6d8a6152f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 15:36:32 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 09 Nov 2015 20:36:32 +0000 Subject: [issue25582] Fixed memory leaks in test_ctypes In-Reply-To: <1446927500.57.0.889992318056.issue25582@psf.upfronthosting.co.za> Message-ID: <1447101392.7.0.86316531527.issue25582@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: There is still 32 MB leak in PointersTestCase.test_pointer_type_str_name in test_pointers.py in 2.7. ---------- stage: patch review -> needs patch type: behavior -> resource usage versions: -Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 15:56:15 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 09 Nov 2015 20:56:15 +0000 Subject: [issue25555] Fix parser and AST: fill lineno and col_offset when compiling AST from Python objects In-Reply-To: <1446716524.88.0.975797398415.issue25555@psf.upfronthosting.co.za> Message-ID: <20151109205609.115882.48996@psf.io> Roundup Robot added the comment: New changeset 2d8988f64cea by Victor Stinner in branch '3.5': Issue #25555: Fix parser and AST: fill lineno and col_offset of "arg" node when https://hg.python.org/cpython/rev/2d8988f64cea ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 15:56:42 2015 From: report at bugs.python.org (Ned Deily) Date: Mon, 09 Nov 2015 20:56:42 +0000 Subject: [issue25589] test_ascii_formatd fails on Mac when built with Intel compiler In-Reply-To: <1447093853.5.0.154282338345.issue25589@psf.upfronthosting.co.za> Message-ID: <1447102602.1.0.73302980018.issue25589@psf.upfronthosting.co.za> Ned Deily added the comment: Chris, how exactly are you running this test that fails and where does the test come from? I may be overlooking something but I do not see any spelling of a test_ascii_formatted in the Python 3.5 source including its embedded ctypes. The ctypes shipped with Python certainly is supported on 64-bit OS X. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 15:56:51 2015 From: report at bugs.python.org (dead1ne) Date: Mon, 09 Nov 2015 20:56:51 +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: <1447102611.38.0.529220646166.issue1602@psf.upfronthosting.co.za> dead1ne added the comment: I've tried addressing the output problem by subclassing TextIOWrapper to use the windows functions GetConsoleOutputCP and WideCharToMultiByte. I've tested this as well as I can without figuring out how to install a better font for the windows console. It appears to work on both python 3.4 and 2.7 although there may be an issue with 2.7 and CJK Extension B and higher codepoints. Hopefully this is useful in finally resolving the issue. Also I think some maintenance patch for 2.7 is in order as currently it fails utterly if you set the console to 65001 since it doesn't recognize it. Had to wrap all print statements in try/except so it wouldn't fail before testing the wrapper. ---------- nosy: +dead1ne Added file: http://bugs.python.org/file40990/wincontest.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 16:04:45 2015 From: report at bugs.python.org (Chris Hogan) Date: Mon, 09 Nov 2015 21:04:45 +0000 Subject: [issue25589] test_ascii_formatd fails on Mac when built with Intel compiler In-Reply-To: <1447093853.5.0.154282338345.issue25589@psf.upfronthosting.co.za> Message-ID: <1447103085.87.0.464497060795.issue25589@psf.upfronthosting.co.za> Chris Hogan added the comment: Ned, the test is in Lib/test/test_ascii_formatd.py. Sorry, I spelled it wrong originally. Also, I guess it's only in 2.7. My mistake. ---------- versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 16:11:32 2015 From: report at bugs.python.org (=?utf-8?q?Adam_Barto=C5=A1?=) Date: Mon, 09 Nov 2015 21:11:32 +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: <1447103492.69.0.536823357904.issue1602@psf.upfronthosting.co.za> Adam Barto? added the comment: dead1ne: Hello, I'm maintaining a package that tries to solve this issue: https://github.com/Drekin/win-unicode-console . There are actually many related problems. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 16:12:15 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 09 Nov 2015 21:12:15 +0000 Subject: [issue25589] test_ascii_formatd fails on Mac when built with Intel compiler In-Reply-To: <1447093853.5.0.154282338345.issue25589@psf.upfronthosting.co.za> Message-ID: <1447103535.35.0.360392015242.issue25589@psf.upfronthosting.co.za> STINNER Victor added the comment: See also issue #24999 about ICC compiler. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 16:14:10 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 09 Nov 2015 21:14:10 +0000 Subject: [issue25555] Fix parser and AST: fill lineno and col_offset when compiling AST from Python objects In-Reply-To: <1446716524.88.0.975797398415.issue25555@psf.upfronthosting.co.za> Message-ID: <1447103650.2.0.782778777224.issue25555@psf.upfronthosting.co.za> STINNER Victor added the comment: I backported the fix to Python 3.5. Since I'm not convinced that the bug can be triggered without modifying CPython (the bug only impacts FAT Python which installs a hook on the AST compiler), I don't want to backport it to Python 2.7 to avoid the risk of regression. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 16:15:08 2015 From: report at bugs.python.org (eryksun) Date: Mon, 09 Nov 2015 21:15:08 +0000 Subject: [issue25585] Bad path leads to: ImportError: DLL load failed: %1 is not a valid Win32 application. In-Reply-To: <1447004161.31.0.19011460804.issue25585@psf.upfronthosting.co.za> Message-ID: <1447103708.5.0.277442056769.issue25585@psf.upfronthosting.co.za> eryksun added the comment: Steve, do you think it's OK to abandon localization for exception messages? If so, should we be using English for all FormatMessage calls? It's a bit ugly that Python's exceptions and the CRT error messages are in English, but then whenever we call FormatMessage with LANG_NEUTRAL/SUBLANG_DEFAULT we're getting localized error text. For example, the import error in the following case has a mix or Russian and English: import io, sys, ctypes kernel32 = ctypes.WinDLL('kernel32') MUI_LANGUAGE_NAME = 8 kernel32.SetThreadPreferredUILanguages(MUI_LANGUAGE_NAME, u'ru-RU\0', None) kernel32.SetConsoleOutputCP(1251) sys.stderr = io.TextIOWrapper(open(r'\\.\con', 'wb'), encoding='1251') open('blah.pyd', 'w').close() >>> import blah Traceback (most recent call last): File "", line 1, in ImportError: DLL load failed: %1 ?? ???????? ??????????? Win32. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 16:16:44 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 09 Nov 2015 21:16:44 +0000 Subject: [issue25586] socket.sendall broken when a socket has a timeout In-Reply-To: <1447019255.89.0.976606710887.issue25586@psf.upfronthosting.co.za> Message-ID: <1447103804.48.0.952308286102.issue25586@psf.upfronthosting.co.za> Martin Panter added the comment: Personally I would avoid big red warning boxes in 90% of the cases people suggest them, including this one. But maybe we can see what others think. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 16:19:30 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 09 Nov 2015 21:19:30 +0000 Subject: [issue25584] a recursive glob pattern fails to list files in the current directory In-Reply-To: <1446998075.89.0.744136833143.issue25584@psf.upfronthosting.co.za> Message-ID: <20151109211927.19473.43757@psf.io> Roundup Robot added the comment: New changeset 4532c4f37429 by Serhiy Storchaka in branch '3.5': Issue #25584: Fixed recursive glob() with patterns starting with '**'. https://hg.python.org/cpython/rev/4532c4f37429 New changeset 175cd763de57 by Serhiy Storchaka in branch 'default': Issue #25584: Fixed recursive glob() with patterns starting with '**'. https://hg.python.org/cpython/rev/175cd763de57 New changeset fefc10de2775 by Serhiy Storchaka in branch '3.5': Issue #25584: Added "escape" to the __all__ list in the glob module. https://hg.python.org/cpython/rev/fefc10de2775 New changeset 128e61cb3de2 by Serhiy Storchaka in branch 'default': Issue #25584: Added "escape" to the __all__ list in the glob module. https://hg.python.org/cpython/rev/128e61cb3de2 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 16:24:08 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 09 Nov 2015 21:24:08 +0000 Subject: [issue25586] socket.sendall broken when a socket has a timeout In-Reply-To: <1447019255.89.0.976606710887.issue25586@psf.upfronthosting.co.za> Message-ID: <1447104248.35.0.6420081494.issue25586@psf.upfronthosting.co.za> STINNER Victor added the comment: I don't really understand why do even you consider the behaviour has a bug or a trap. On timeout, the most common behaviour is to give up on the whole client. I don't know code trying to resend the same data in case of timeout. Describing the behaviour on the documentation helps, but no warning is need. When you *read* data, it's different. It can be interesting to get the partial read. -- For example, the asyncio.StreamReader.readexactly() coroutine raises an asyncio.IncompleteReadError exception which contains the partial data: https://docs.python.org/dev/library/asyncio-stream.html#asyncio.StreamReader.readexactly The HTTP client has a similar exception. I proposed to add similar method to socket.socket which also raises a similar exception to return partial data: issue #1103213. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 16:58:34 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 09 Nov 2015 21:58:34 +0000 Subject: [issue25584] a recursive glob pattern fails to list files in the current directory In-Reply-To: <1446998075.89.0.744136833143.issue25584@psf.upfronthosting.co.za> Message-ID: <1447106314.7.0.0764049272716.issue25584@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Please open new issue for glob() optimization Xavier. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 17:15:43 2015 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 09 Nov 2015 22:15:43 +0000 Subject: [issue25590] tab-completition on instances repeatedly accesses attribute/descriptors values Message-ID: <1447107343.63.0.0427300203207.issue25590@psf.upfronthosting.co.za> New submission from Ezio Melotti: Pressing to invoke autocompletition on instances repeatedly accesses attributes/descriptors values: >>> # is used to indicate when/where I press >>> class Foo: ... @property ... def bar(self): print('Foo.bar called') ... >>> f = Foo() >>> f.Foo.bar called Foo.bar called Foo.bar called Foo.bar called Foo.bar called Foo.bar called Foo.bar called Foo.bar called f.__class__( f.__doc__ f.__getattribute__( f.__le__( f.__new__( f.__setattr__( f.__weakref__ f.__delattr__( f.__eq__( f.__gt__( f.__lt__( f.__reduce__( f.__sizeof__( f.bar f.__dict__ f.__format__( f.__hash__( f.__module__ f.__reduce_ex__( f.__str__( f.__dir__( f.__ge__( f.__init__( f.__ne__( f.__repr__( f.__subclasshook__( >>> f.bFoo.bar called Foo.bar called Foo.bar called Foo.bar called ar Foo.bar called Each time I press , the property is called 4 times. I'm not sure why the value is accessed at all, but even if there was a valid reason to do so, doing it once should be enough. ---------- messages: 254415 nosy: ezio.melotti priority: normal severity: normal stage: test needed status: open title: tab-completition on instances repeatedly accesses attribute/descriptors values type: behavior versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 17:16:15 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 09 Nov 2015 22:16:15 +0000 Subject: [issue25583] os.makedirs with exist_ok=True raises PermissionError on Windows 7^ In-Reply-To: <1446993273.85.0.222873165522.issue25583@psf.upfronthosting.co.za> Message-ID: <1447107375.74.0.323578215247.issue25583@psf.upfronthosting.co.za> Martin Panter added the comment: Yes that looks like an improvement, though I wonder what?s wrong with your original proposal (performance maybe?). In any case, it definitely needs a comment explaining the first isdir() avoids competing failures that mask EEXIST, and the exception handling avoids the race to create the directory. A test case for the test suite would also be good. I understand it should be easy to do for Windows, just make a directory with an absolute path including a drive root like d:\. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 17:16:47 2015 From: report at bugs.python.org (Maciej Szulik) Date: Mon, 09 Nov 2015 22:16:47 +0000 Subject: [issue25591] improve test coverage for the imaplib Message-ID: <1447107407.81.0.130095933409.issue25591@psf.upfronthosting.co.za> New submission from Maciej Szulik: Our current imaplib implementation lacks quite a few of tests and the ones present are written in different styles. I'd like to propose rewriting the test case with this new style I've developed during PyCon sprints along with David. Once we'll have the entire test suite in place it'll be safer to introduce any changes I'd like to cover, including updating the implementation to newest RFC 3501 version. ---------- components: email files: new_imap_tests.diff hgrepos: 322 keywords: patch messages: 254417 nosy: barry, maciej.szulik, r.david.murray priority: normal severity: normal status: open title: improve test coverage for the imaplib type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file40991/new_imap_tests.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 17:35:30 2015 From: report at bugs.python.org (Maciej Szulik) Date: Mon, 09 Nov 2015 22:35:30 +0000 Subject: [issue13940] imaplib: Mailbox names are not quoted In-Reply-To: <1328357098.01.0.78801274991.issue13940@psf.upfronthosting.co.za> Message-ID: <1447108530.09.0.0284701087942.issue13940@psf.upfronthosting.co.za> Maciej Szulik added the comment: Currently working on a patch for this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 18:11:56 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 09 Nov 2015 23:11:56 +0000 Subject: [issue25590] tab-completition on instances repeatedly accesses attribute/descriptors values In-Reply-To: <1447107343.63.0.0427300203207.issue25590@psf.upfronthosting.co.za> Message-ID: <1447110716.34.0.929288589913.issue25590@psf.upfronthosting.co.za> Martin Panter added the comment: Long story short: it is accessed due to the callable suffix check (Issue 449227), and this check is less than optimal, meaning the attribute gets accessed up to four times per Tab press. In 3.6, there are only two calls, one for the hasattr() call, and one for the getattr() call: Foo.bar called File "/home/proj/python/cpython/Lib/rlcompleter.py", line 85, in complete self.matches = self.attr_matches(text) File "/home/proj/python/cpython/Lib/rlcompleter.py", line 164, in attr_matches hasattr(thisobject, word)): File "", line 3, in bar Foo.bar called File "/home/proj/python/cpython/Lib/rlcompleter.py", line 85, in complete self.matches = self.attr_matches(text) File "/home/proj/python/cpython/Lib/rlcompleter.py", line 165, in attr_matches val = getattr(thisobject, word) File "", line 3, in bar Before revision 4dbb315fe667 (Issue 25011), ?words? was a list rather than a set. It gets two ?bar? entries, one from dir(f) and one from dir(f.__class__). Maybe it is worth backporting set(), I dunno. The hasattr() call was added in r65168 (Issue 3396) as a look-before-you-leap check to avoid the completer from dying from getattr() exceptions. IMO in this case it is better to ?ask for forgiveness? by catching Exception from getattr(). This would be more robust to quirky and buggy attributes anyway. Finally (or really, initially), getattr() was added in r64664 (Issue 449227). I think even if getattr() fails, the attribute name could still be output, just not with the callable suffix (which I partly disagree with anyway). It would have been like that previously. But I guess this is debatable, and a separate issue. ---------- components: +Library (Lib) nosy: +martin.panter, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 18:13:14 2015 From: report at bugs.python.org (Daniel Plachotich) Date: Mon, 09 Nov 2015 23:13:14 +0000 Subject: [issue25583] os.makedirs with exist_ok=True raises PermissionError on Windows 7^ In-Reply-To: <1446993273.85.0.222873165522.issue25583@psf.upfronthosting.co.za> Message-ID: <1447110794.49.0.129515334399.issue25583@psf.upfronthosting.co.za> Daniel Plachotich added the comment: You mean msg254341? As I mentioned recently, it still will raise an exception in case of EROFS, ENOSPC and possibly other values, which, as in the case with Windows, can be quite unexpected depending on platform and circumstances. Of course there is no practical sense to continue when, for example, FS is read-only (EROFS), but I think makedirs must be predictable: it should first check and only then try to create, as it stated in the docstring. When exist_ok=True and directory really exists, a user doesn't expect any exceptions from the internally used mkdir, because it simply shouldn't be called in this case. By the way, why 3.2 and 3.3 were removed from the list? exist_ok was introduced in 3.2. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 18:28:17 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 09 Nov 2015 23:28:17 +0000 Subject: [issue25528] Attempt to further increase test coverage of calendar module In-Reply-To: <1446371863.84.0.773420016182.issue25528@psf.upfronthosting.co.za> Message-ID: <1447111697.14.0.795442638441.issue25528@psf.upfronthosting.co.za> Martin Panter added the comment: Rohit, it looks like your patch is reversed. The lines with a + sign already exist; are the - lines your proposed additions? Equivalently, revision f7db966c9fee already exists; is fb9d4ccbadf0 your new proposed revision? Assuming the patch is reversed, I suggest keeping the locale=None case, perhaps as a separate test case or loop iteration. Otherwise you are throwing out one test case to add another. ---------- nosy: +martin.panter stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 18:35:50 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 09 Nov 2015 23:35:50 +0000 Subject: [issue25590] tab-completition on instances repeatedly accesses attribute/descriptors values In-Reply-To: <1447107343.63.0.0427300203207.issue25590@psf.upfronthosting.co.za> Message-ID: <1447112150.3.0.906220128629.issue25590@psf.upfronthosting.co.za> Martin Panter added the comment: Illustration of why I think removing the attribute on errors is bad: >>> class Foo: ... @property ... def bar(self): return self._bar ... @bar.setter ... def bar(self, value): self._bar = value ... >>> f = Foo() >>> f.bar = ... # Tab completion fails in this case ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 19:08:15 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 10 Nov 2015 00:08:15 +0000 Subject: [issue25583] os.makedirs with exist_ok=True raises PermissionError on Windows 7^ In-Reply-To: <1446993273.85.0.222873165522.issue25583@psf.upfronthosting.co.za> Message-ID: <1447114095.82.0.17495048934.issue25583@psf.upfronthosting.co.za> Martin Panter added the comment: I don?t think we patch 3.2 or 3.3 any more unless it is a security concern. That is why I removed them. I understand 3.4 is due for its last non-security release in a couple weeks. I was actually referring to your original suggestion in , dressed up below: except OSError: # Cannot rely on checking for EEXIST, since the operating system could give priority to other errors like EACCES or EROFS if not (exist_ok and path.isdir(name)): raise There may be practical reasons to continue if a parent directory exists on a read-only FS. Some OSes can mount writable FSes inside read-only FSes. See involving Cygwin, and involving a Linux regression. Anyway, I think I am happy with either your last fix or the first, with an appropriate comment, and hopefully also a test case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 19:33:14 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 10 Nov 2015 00:33:14 +0000 Subject: [issue25465] Pickle uses O(n) memory overhead In-Reply-To: <1445593043.5.0.334623277706.issue25465@psf.upfronthosting.co.za> Message-ID: <1447115594.34.0.205150218384.issue25465@psf.upfronthosting.co.za> Martin Panter added the comment: FWIW my usual workaround is to enable Linux?s SysRq handler, then press Ctrl+Alt+(SysRq, F) to manually invoke the OOM killer. It beats waiting between 30 and infinity minutes for it to manually kick in :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 19:50:27 2015 From: report at bugs.python.org (Ned Deily) Date: Tue, 10 Nov 2015 00:50:27 +0000 Subject: [issue25589] test_ascii_formatd fails on Mac when built with Intel compiler In-Reply-To: <1447093853.5.0.154282338345.issue25589@psf.upfronthosting.co.za> Message-ID: <1447116627.19.0.25720008189.issue25589@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks for the updates. Since it's not at all clear what the issue is or that it is Mac-specific, I'm going to bow out of this and remove the Mac tag for now. ---------- components: -Macintosh, Tests nosy: -ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 19:50:45 2015 From: report at bugs.python.org (Ned Deily) Date: Tue, 10 Nov 2015 00:50:45 +0000 Subject: [issue25589] test_ascii_formatd fails on Mac when built with Intel compiler In-Reply-To: <1447093853.5.0.154282338345.issue25589@psf.upfronthosting.co.za> Message-ID: <1447116645.71.0.402963232766.issue25589@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: -ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 20:22:44 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 10 Nov 2015 01:22:44 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <1447118564.25.0.715769301523.issue23883@psf.upfronthosting.co.za> Martin Panter added the comment: Berker (or anyone else), do you have a preference on how we move forward? I am inclined to use Jacek?s function as it is. I think it is certainly an improvement over the current state. People can propose an alternative version of the function later if they want, though in my opinion the underlying problem is in the architecture of unittest?s assertion methods; see Issue 19645. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 21:38:20 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 10 Nov 2015 02:38:20 +0000 Subject: [issue19645] decouple unittest assertions from the TestCase class In-Reply-To: <1384785494.56.0.149196031493.issue19645@psf.upfronthosting.co.za> Message-ID: <1447123100.84.0.182016068564.issue19645@psf.upfronthosting.co.za> Martin Panter added the comment: Looking at Gregory and Robert?s ?matchers? link, which also covers ?assertThat?, it seems to provide a library of matcher assertion objects. E.g. instead of this TestCase-coupled code: self.assertEquals(something, "expected value") you would write from testtools.matchers import Equals self.assertThat(something, Equals("expected value")) Implementing a custom matcher (say HasAttr for Serhiy?s first use case) seems to involve creating the HasAttr class with a match() method, and maybe another HasAttrMismatch class (though maybe you could get away with just a shared generic mismatch class?). It seems to me that if you ignore the vaguely-documented TestCase.failureException attribute, you can fairly easily decouple the existing methods from a TestCase instance: def assert_equal(first, second, msg=None): # Implementation could be copied independently of any test state TestCase().assertEqual(first, second, msg) The matcher scheme would be more flexible though, because you can compose matcher objects. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 21:44:21 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 10 Nov 2015 02:44:21 +0000 Subject: [issue1103213] Adding a recvexactly() to socket.socket: receive exactly n bytes Message-ID: <1447123461.18.0.273940764641.issue1103213@psf.upfronthosting.co.za> Martin Panter added the comment: I can?t say I?ve often wanted this kind of method for socket objects. I guess this would treat a zero-length message (e.g. UDP datagram) as end-of-stream. Maybe it would be more useful as a general function or method for RawIOBase (maybe also BufferedIOBase) streams. As for the exception, I have used the existing EOFError in the past for similar purposes. After all, an unexpected EOF error at a low level often means an incomplete or truncated data error at a higher level. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 22:27:55 2015 From: report at bugs.python.org (Nan Wu) Date: Tue, 10 Nov 2015 03:27:55 +0000 Subject: [issue25567] shlex.quote doesn't work on bytestrings In-Reply-To: <1446814343.82.0.823951892686.issue25567@psf.upfronthosting.co.za> Message-ID: <1447126075.94.0.261791446817.issue25567@psf.upfronthosting.co.za> Nan Wu added the comment: Added a patch for support this in `quote` method. What is a good example or a group of examples to demonstrate the usage in the document? ---------- keywords: +patch nosy: +Nan Wu Added file: http://bugs.python.org/file40992/shlex_quote_bytes_support.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 23:29:11 2015 From: report at bugs.python.org (Steve Dower) Date: Tue, 10 Nov 2015 04:29:11 +0000 Subject: [issue25585] Bad path leads to: ImportError: DLL load failed: %1 is not a valid Win32 application. In-Reply-To: <1447004161.31.0.19011460804.issue25585@psf.upfronthosting.co.za> Message-ID: <1447129751.8.0.85956479948.issue25585@psf.upfronthosting.co.za> Steve Dower added the comment: For 3.6 I think it's fine, but people are almost certainly relying on the current message on their system and changing it at all for any existing release is unnecessary pain (3.5.1 *might* be okay, but only because it's so recent). It would be nice to invest in some better diagnostics here, though with the ABI tag in 3.5 you're now unlikely to get an incompatible binary. File not found will be the most common message. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 9 23:30:15 2015 From: report at bugs.python.org (Steve Dower) Date: Tue, 10 Nov 2015 04:30:15 +0000 Subject: [issue25585] Bad path leads to: ImportError: DLL load failed: %1 is not a valid Win32 application. In-Reply-To: <1447004161.31.0.19011460804.issue25585@psf.upfronthosting.co.za> Message-ID: <1447129815.24.0.388706146083.issue25585@psf.upfronthosting.co.za> Steve Dower added the comment: Correction, *import* not found, and the only way to resolve it is to do a second scan of sys.path for the sole purpose of diagnostics. Probably more harmful than helpful. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 10 01:06:12 2015 From: report at bugs.python.org (Jeroen Demeyer) Date: Tue, 10 Nov 2015 06:06:12 +0000 Subject: [issue25592] distutils docs: data_files always uses sys.prefix Message-ID: <1447135572.7.0.138478279434.issue25592@psf.upfronthosting.co.za> New submission from Jeroen Demeyer: The documentation for distutils claims that sys.exec_prefix is used in certain cases to install data_files, but this is simply not true (maybe it was true in the past or this sentence was copy/pasted from somewhere else?) ---------- assignee: docs at python components: Documentation files: data_files_doc.patch keywords: patch messages: 254432 nosy: docs at python, jdemeyer priority: normal severity: normal status: open title: distutils docs: data_files always uses sys.prefix versions: Python 2.7 Added file: http://bugs.python.org/file40993/data_files_doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 10 02:16:34 2015 From: report at bugs.python.org (Alexander Mohr) Date: Tue, 10 Nov 2015 07:16:34 +0000 Subject: [issue25593] _sock_connect_cb can be called twice resulting in InvalidStateError Message-ID: <1447139794.12.0.288748898255.issue25593@psf.upfronthosting.co.za> New submission from Alexander Mohr: asyncio.selector_events.BaseSelectorEventLoop._sock_connect_cb is a callback based on the selector for a socket. There are certain situations when the selector triggers twice calling this callback twice, resulting in an InvalidStateError when it sets the Future to None. The way I triggered this was by having several parallel connections to the same host in a multiprocessing script. I suggest analyzing why this callback can be called twice and figuring out what the correct fix is. I monkey patched it by adding a fut.done() check at the top. If this information is not enough I can try to provide a sample script. Its currently reproducing in a fairly involved multiprocessing script. ---------- components: asyncio messages: 254433 nosy: gvanrossum, haypo, thehesiod, yselivanov priority: normal severity: normal status: open title: _sock_connect_cb can be called twice resulting in InvalidStateError type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 10 02:20:03 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 10 Nov 2015 07:20:03 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <1447140003.21.0.6572988823.issue23883@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I have added comments on Rietveld. Besides few stylistic nitpicks Issue23883_support_check__all__.v5.patch LGTM. > But passing "self" to it feels a bit weird. This is not new. There are other testing helpers in test.support that needs passing "self". If the helper is used many times in one test class, I prefer to make a method: class SomeTest(TestCase): check_something = test.support.check_something def test_foo(): self.check_something('foo') def test_bar(): self.check_something('bar') But in this case I'm happy with the current API. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 10 02:27:13 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 10 Nov 2015 07:27:13 +0000 Subject: [issue11822] Improve disassembly to show embedded code objects In-Reply-To: <1302467152.39.0.854888976189.issue11822@psf.upfronthosting.co.za> Message-ID: <1447140433.44.0.912365769031.issue11822@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: rhettinger -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 10 02:32:02 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 10 Nov 2015 07:32:02 +0000 Subject: [issue25590] tab-completition on instances repeatedly accesses attribute/descriptors values In-Reply-To: <1447107343.63.0.0427300203207.issue25590@psf.upfronthosting.co.za> Message-ID: <1447140722.61.0.911212283536.issue25590@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Agreed with all your suggestions Martin. Do you want to write a patch? ---------- stage: test needed -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 10 03:27:47 2015 From: report at bugs.python.org (SilentGhost) Date: Tue, 10 Nov 2015 08:27:47 +0000 Subject: [issue25594] enum docs outdated re attribute access Message-ID: <1447144067.5.0.526378354242.issue25594@psf.upfronthosting.co.za> New submission from SilentGhost: In enum docs[0], there is a suggestion that the attribute access on members should raise an AttributeError: >>> Color.red.blue Traceback (most recent call last): ... AttributeError: 'Color' object has no attribute 'blue' which is demonstrably wrong in either 3.5 or 3.6. I presume that's a doc issue and I'd be glad to propose the patch as soon as someone more familiar with the module could confirm that. [0] https://docs.python.org/3.6/library/enum.html#finer-points ---------- assignee: docs at python components: Documentation, Library (Lib) messages: 254436 nosy: SilentGhost, barry, docs at python, eli.bendersky, ethan.furman priority: normal severity: normal status: open title: enum docs outdated re attribute access versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 10 04:25:53 2015 From: report at bugs.python.org (Jakub Stasiak) Date: Tue, 10 Nov 2015 09:25:53 +0000 Subject: [issue25586] socket.sendall broken when a socket has a timeout In-Reply-To: <1447019255.89.0.976606710887.issue25586@psf.upfronthosting.co.za> Message-ID: <1447147553.19.0.401689806697.issue25586@psf.upfronthosting.co.za> Jakub Stasiak added the comment: That's fair and thanks for the links. Please find a quick patch attached, feel free to use that or any modification of it. While I believe the documentation is technically correct right now it won't hurt to clarify this I think. ---------- keywords: +patch Added file: http://bugs.python.org/file40994/socket-docs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 10 06:03:12 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 10 Nov 2015 11:03:12 +0000 Subject: [issue25595] test_deleted_cwd in test_importlib is failed on AIX Message-ID: <1447153392.75.0.692094551582.issue25595@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: test_deleted_cwd in test_importlib is failed on AIX. http://buildbot.python.org/all/builders/PPC64%20AIX%203.x/builds/4318/steps/test/logs/stdio ====================================================================== ERROR: test_deleted_cwd (test.test_importlib.import_.test_path.Source_FinderTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_importlib/import_/test_path.py", line 169, in test_deleted_cwd os.chdir(path) File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/tempfile.py", line 807, in __exit__ self.cleanup() File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/tempfile.py", line 811, in cleanup _shutil.rmtree(self.name) File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/shutil.py", line 478, in rmtree onerror(os.rmdir, path, sys.exc_info()) File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/shutil.py", line 476, in rmtree os.rmdir(path) OSError: [Errno 16] Device busy: '/tmp/tmp2xdxtq6x' ---------------------------------------------------------------------- Proposed patch fixes the test. It also uses more verbose wording to create and remove temporary directory to be sure that caught exception was written by removing the directory, not by creating or changing CWD. See also issue22834. ---------- components: Tests files: test_deleted_cwd_aix.patch keywords: patch messages: 254438 nosy: David.Edelsohn, brett.cannon, martin.panter, serhiy.storchaka, zach.ware priority: normal severity: normal stage: patch review status: open title: test_deleted_cwd in test_importlib is failed on AIX type: behavior versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file40995/test_deleted_cwd_aix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 10 06:15:21 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 10 Nov 2015 11:15:21 +0000 Subject: [issue25595] test_deleted_cwd in test_importlib is failed on AIX In-Reply-To: <1447153392.75.0.692094551582.issue25595@psf.upfronthosting.co.za> Message-ID: <1447154121.78.0.400975714679.issue25595@psf.upfronthosting.co.za> STINNER Victor added the comment: -1, review on Rietveld. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 10 06:18:07 2015 From: report at bugs.python.org (Xavier de Gaye) Date: Tue, 10 Nov 2015 11:18:07 +0000 Subject: [issue25596] regular files handled as directories in the glob module Message-ID: <1447154287.89.0.207791672282.issue25596@psf.upfronthosting.co.za> New submission from Xavier de Gaye: The glob module happily joins names of regular files together with os.path.join() or attempts to list the files contained into a regular file (sic). The same 'except os.error' statement is used to handle both these cases and the case of a non readable directory. The attached patch makes the code more correct and easier to understand. ---------- components: Library (Lib) files: glob_isdir.patch keywords: patch messages: 254440 nosy: xdegaye priority: normal severity: normal status: open title: regular files handled as directories in the glob module type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file40996/glob_isdir.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 10 06:21:41 2015 From: report at bugs.python.org (Xavier de Gaye) Date: Tue, 10 Nov 2015 11:21:41 +0000 Subject: [issue25584] a recursive glob pattern fails to list files in the current directory In-Reply-To: <1446998075.89.0.744136833143.issue25584@psf.upfronthosting.co.za> Message-ID: <1447154501.92.0.152147778373.issue25584@psf.upfronthosting.co.za> Xavier de Gaye added the comment: New issue 25596 entered: regular files handled as directories in the glob module. Thanks for fixing this Serhiy. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 10 07:55:32 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 10 Nov 2015 12:55:32 +0000 Subject: [issue25595] test_deleted_cwd in test_importlib is failed on AIX In-Reply-To: <1447153392.75.0.692094551582.issue25595@psf.upfronthosting.co.za> Message-ID: <1447160132.21.0.113487613566.issue25595@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Victor for your review. Here is fixed patch that implements your suggestions. ---------- Added file: http://bugs.python.org/file40997/test_deleted_cwd_aix_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 10 07:58:25 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 10 Nov 2015 12:58:25 +0000 Subject: [issue25595] test_deleted_cwd in test_importlib is failed on AIX In-Reply-To: <1447153392.75.0.692094551582.issue25595@psf.upfronthosting.co.za> Message-ID: <1447160305.09.0.317890117328.issue25595@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: And here is simple alternative patch based on Martin's original suggestion in msg236122. ---------- Added file: http://bugs.python.org/file40998/test_deleted_cwd_aix_alt.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 10 08:11:37 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 10 Nov 2015 13:11:37 +0000 Subject: [issue25595] test_deleted_cwd in test_importlib is failed on AIX In-Reply-To: <1447153392.75.0.692094551582.issue25595@psf.upfronthosting.co.za> Message-ID: <1447161097.51.0.599525611348.issue25595@psf.upfronthosting.co.za> STINNER Victor added the comment: test_deleted_cwd_aix_alt.patch: I don't trust tempfile.TemporaryDirectory(), I prefer your patch. test_deleted_cwd_aix_2.patch looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 10 08:24:30 2015 From: report at bugs.python.org (Daniel Plachotich) Date: Tue, 10 Nov 2015 13:24:30 +0000 Subject: [issue25583] os.makedirs with exist_ok=True raises PermissionError on Windows 7^ In-Reply-To: <1446993273.85.0.222873165522.issue25583@psf.upfronthosting.co.za> Message-ID: <1447161870.92.0.0101745795052.issue25583@psf.upfronthosting.co.za> Daniel Plachotich added the comment: Yes, it's probably a better solution. If had been more careful, I wouldn't have scribbled so much text here :) . But is there any sense in adding Windows-specific test with EACCES since the problem with errno may affect other platforms as well (at least in theory)? It's not a Windows-only issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 10 08:25:25 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 10 Nov 2015 13:25:25 +0000 Subject: [issue25263] test_tkinter fails randomly on the buildbots "AMD64 Windows10" (3.4, 3.5, 3.x) In-Reply-To: <1443513254.01.0.657938826089.issue25263@psf.upfronthosting.co.za> Message-ID: <1447161925.46.0.69343090706.issue25263@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The other failure is not Windows specific. It can be reproduced if run test_tk twice. FontTest.setUpClass() incorrectly call parent's method and the root attribute is set in parent class. tearDownClass() sets the root attribute to None in child class, and this overrides parent's attribute. The test in the second run passes self.root (is None) to font.Font constructor, and this is interpreted as no the root argument passed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 10 08:33:36 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 10 Nov 2015 13:33:36 +0000 Subject: [issue25263] test_tkinter fails randomly on the buildbots "AMD64 Windows10" (3.4, 3.5, 3.x) In-Reply-To: <1443513254.01.0.657938826089.issue25263@psf.upfronthosting.co.za> Message-ID: <20151110133323.21712.57239@psf.io> Roundup Robot added the comment: New changeset 385b3aaf8401 by Serhiy Storchaka in branch '3.4': Issue #25263: Fixed the tkinter.test.test_tkinter.test_font.FontTest test https://hg.python.org/cpython/rev/385b3aaf8401 New changeset db168611c6c8 by Serhiy Storchaka in branch '3.5': Issue #25263: Fixed the tkinter.test.test_tkinter.test_font.FontTest test https://hg.python.org/cpython/rev/db168611c6c8 New changeset 0632642c30dd by Serhiy Storchaka in branch 'default': Issue #25263: Fixed the tkinter.test.test_tkinter.test_font.FontTest test https://hg.python.org/cpython/rev/0632642c30dd New changeset f81e357b2318 by Serhiy Storchaka in branch '2.7': Issue #25263: Fixed the tkinter.test.test_tkinter.test_font.FontTest test https://hg.python.org/cpython/rev/f81e357b2318 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 10 09:50:20 2015 From: report at bugs.python.org (Chris Hogan) Date: Tue, 10 Nov 2015 14:50:20 +0000 Subject: [issue25589] test_ascii_formatd fails on Mac when built with Intel compiler In-Reply-To: <1447093853.5.0.154282338345.issue25589@psf.upfronthosting.co.za> Message-ID: <1447167020.1.0.688126842324.issue25589@psf.upfronthosting.co.za> Chris Hogan added the comment: I guess since no one can reproduce the error, it must be a problem with how I'm building it. We build our own dependencies (zlib, bzip, sqlite3, openssl, etc.) with the Intel compiler, so it could be any number of things causing the issue. Closing as not a bug. ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 10 10:35:35 2015 From: report at bugs.python.org (Xavier de Gaye) Date: Tue, 10 Nov 2015 15:35:35 +0000 Subject: [issue25596] regular files handled as directories in the glob module In-Reply-To: <1447154287.89.0.207791672282.issue25596@psf.upfronthosting.co.za> Message-ID: <1447169735.47.0.0121850966925.issue25596@psf.upfronthosting.co.za> Xavier de Gaye added the comment: This second patch rewrites the conditionals that decide whether to call _iglob() recursively, in a more natural way and without changing the behavior from the first patch. Note that when 'dirname == pathname', then basename is empty and glob2() or glob1() are not called. The patch also refactors the code with a new _listdir() function. ---------- Added file: http://bugs.python.org/file40999/glob_isdir_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 10 10:47:03 2015 From: report at bugs.python.org (Ethan Furman) Date: Tue, 10 Nov 2015 15:47:03 +0000 Subject: [issue25594] enum docs outdated re attribute access In-Reply-To: <1447144067.5.0.526378354242.issue25594@psf.upfronthosting.co.za> Message-ID: <1447170423.15.0.575816145473.issue25594@psf.upfronthosting.co.za> Ethan Furman added the comment: Nope, that would be a bug. ---------- assignee: docs at python -> ethan.furman stage: -> test needed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 10 10:49:47 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 10 Nov 2015 15:49:47 +0000 Subject: [issue25263] test_tkinter fails randomly on the buildbots "AMD64 Windows10" (3.4, 3.5, 3.x) In-Reply-To: <1443513254.01.0.657938826089.issue25263@psf.upfronthosting.co.za> Message-ID: <1447170587.1.0.756578834387.issue25263@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Tk bug looks fixed in next releases of Tk 8.5 and 8.6. Here is a patch that adds a workaround for the test. ---------- keywords: +patch stage: -> patch review type: -> behavior Added file: http://bugs.python.org/file41000/tkinter_test_use_workaround.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 10 10:58:18 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 10 Nov 2015 15:58:18 +0000 Subject: [issue25596] regular files handled as directories in the glob module In-Reply-To: <1447154287.89.0.207791672282.issue25596@psf.upfronthosting.co.za> Message-ID: <1447171098.13.0.685226760738.issue25596@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka nosy: +serhiy.storchaka priority: normal -> low stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 10 11:01:35 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 10 Nov 2015 16:01:35 +0000 Subject: [issue25589] test_ascii_formatd fails on Mac when built with Intel compiler In-Reply-To: <1447093853.5.0.154282338345.issue25589@psf.upfronthosting.co.za> Message-ID: <1447171295.5.0.737327406187.issue25589@psf.upfronthosting.co.za> R. David Murray added the comment: Someone can correct me if I'm wrong, but my expectation would be that since we use ICC for the main compile on the ICC buildbots, we also compile the bundled ctypes using it. It is hard to see how any of the other modules would affect this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 10 12:02:38 2015 From: report at bugs.python.org (Darragh Bailey) Date: Tue, 10 Nov 2015 17:02:38 +0000 Subject: [issue25597] unittest.mock does not wrap dict objects correctly Message-ID: <1447174958.96.0.448093662654.issue25597@psf.upfronthosting.co.za> New submission from Darragh Bailey: Both unittest.mock and the backported release for earlier pythons don't appear to support mocking of dictionary objects. Specifically I'm expecting that any of the methods used to test for membership, or get items from a mock object wrapping a dictionary should succeed. However it appears that MagicMock doesn't appear to support this. Attached file shows an attempt to use different methods with a wrapped dictionary object where only the '.get()' method appears to work as expected. ---------- files: test-mock-wraps-dict.py messages: 254453 nosy: Darragh Bailey priority: normal severity: normal status: open title: unittest.mock does not wrap dict objects correctly type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file41001/test-mock-wraps-dict.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 10 12:02:55 2015 From: report at bugs.python.org (Stefan Krah) Date: Tue, 10 Nov 2015 17:02:55 +0000 Subject: [issue25598] Fix memory_hex (#9951) for non-contiguous buffers Message-ID: <1447174975.72.0.408489689517.issue25598@psf.upfronthosting.co.za> New submission from Stefan Krah: memory_hex from #9951 fails for non-contiguous buffers. ---------- assignee: skrah files: memhex.diff keywords: patch messages: 254454 nosy: skrah priority: normal severity: normal status: open title: Fix memory_hex (#9951) for non-contiguous buffers type: crash versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file41002/memhex.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 10 12:19:10 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 10 Nov 2015 17:19:10 +0000 Subject: [issue25598] Fix memory_hex (#9951) for non-contiguous buffers In-Reply-To: <1447174975.72.0.408489689517.issue25598@psf.upfronthosting.co.za> Message-ID: <20151110171907.27691.41511@psf.io> Roundup Robot added the comment: New changeset f3d8bb3ffa98 by Stefan Krah in branch '3.5': Iaaue #25598: Fix memory_hex from #9951 for non-contiguous buffers. https://hg.python.org/cpython/rev/f3d8bb3ffa98 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 10 12:19:10 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 10 Nov 2015 17:19:10 +0000 Subject: [issue9951] introduce bytes.hex method (also for bytearray and memoryview) In-Reply-To: <1285457928.18.0.422778723123.issue9951@psf.upfronthosting.co.za> Message-ID: <20151110171907.27691.82694@psf.io> Roundup Robot added the comment: New changeset f3d8bb3ffa98 by Stefan Krah in branch '3.5': Iaaue #25598: Fix memory_hex from #9951 for non-contiguous buffers. https://hg.python.org/cpython/rev/f3d8bb3ffa98 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 10 12:26:22 2015 From: report at bugs.python.org (Theron Luhn) Date: Tue, 10 Nov 2015 17:26:22 +0000 Subject: [issue25599] asyncio.iscoroutinefunction returns unexpected results when presented with unittest.mock.Mock Message-ID: <1447176382.09.0.498269327302.issue25599@psf.upfronthosting.co.za> New submission from Theron Luhn: >>> asyncio.iscoroutinefunction(unittest.mock.Mock()) This is an unexpected response, both in type (Mock rather than boolean) and value (truthy). inspect.iscoroutinefunction behaves as expected. Workaround: >>> m = unittest.mock.Mock() >>> m._is_coroutine = False >>> asyncio.iscoroutinefunction(m) False ---------- components: asyncio messages: 254457 nosy: Theron Luhn, gvanrossum, haypo, yselivanov priority: normal severity: normal status: open title: asyncio.iscoroutinefunction returns unexpected results when presented with unittest.mock.Mock type: behavior versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 10 12:43:49 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 10 Nov 2015 17:43:49 +0000 Subject: [issue6598] calling email.utils.make_msgid frequently has a non-trivial probability of generating colliding ids In-Reply-To: <1248913936.65.0.487457323949.issue6598@psf.upfronthosting.co.za> Message-ID: <1447177429.32.0.180025265173.issue6598@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: http://buildbot.python.org/all/builders/x86%20Tiger%202.7/builds/3246/steps/test/logs/stdio ====================================================================== FAIL: test_make_msgid_collisions (email.test.test_email.TestMiscellaneous) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/db3l/buildarea/2.7.bolen-tiger/build/Lib/email/test/test_email.py", line 2434, in test_make_msgid_collisions pass File "/Users/db3l/buildarea/2.7.bolen-tiger/build/Lib/contextlib.py", line 24, in __exit__ self.gen.next() File "/Users/db3l/buildarea/2.7.bolen-tiger/build/Lib/test/test_support.py", line 1570, in start_threads raise AssertionError('Unable to join %d threads' % len(started)) AssertionError: Unable to join 5 threads ---------------------------------------------------------------------- Threads that should be finished for 3 seconds can't be finished for 15 minutes. It looks as clock() wrapped around. From clock (3) manpage: Note that the time can wrap around. On a 32-bit system where CLOCKS_PER_SEC equals 1000000 this function will return the same value approximately every 72 minutes. The solution is to use monotonic() (time() on older releases) instead of clock(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 10 12:48:40 2015 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 10 Nov 2015 17:48:40 +0000 Subject: [issue25599] asyncio.iscoroutinefunction returns unexpected results when presented with unittest.mock.Mock In-Reply-To: <1447176382.09.0.498269327302.issue25599@psf.upfronthosting.co.za> Message-ID: <1447177720.85.0.669510156727.issue25599@psf.upfronthosting.co.za> Guido van Rossum added the comment: Hm... I don't know what answer you would expect. Who says your mock shouldn't behave like a coroutine? In general, passing mocks to functions is likely to return a mock -- even boolean functions. Can you provide more context? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 10 12:53:25 2015 From: report at bugs.python.org (SilentGhost) Date: Tue, 10 Nov 2015 17:53:25 +0000 Subject: [issue25594] enum docs outdated re attribute access In-Reply-To: <1447144067.5.0.526378354242.issue25594@psf.upfronthosting.co.za> Message-ID: <1447178005.54.0.653573234116.issue25594@psf.upfronthosting.co.za> SilentGhost added the comment: Here is the test, it seems to have been 2545bfe0d273 that caused it (issue23486): test passes prior to it and fails on it (and I assume uniformly after). ---------- keywords: +patch Added file: http://bugs.python.org/file41003/test_issue25594.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 10 12:54:15 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 10 Nov 2015 17:54:15 +0000 Subject: [issue6598] calling email.utils.make_msgid frequently has a non-trivial probability of generating colliding ids In-Reply-To: <1248913936.65.0.487457323949.issue6598@psf.upfronthosting.co.za> Message-ID: <20151110175407.115892.73339@psf.io> Roundup Robot added the comment: New changeset 3c0a817ab616 by Serhiy Storchaka in branch '3.4': Issue #6598: Avoid clock wrapping around in test_make_msgid_collisions. https://hg.python.org/cpython/rev/3c0a817ab616 New changeset e259c0ab7a69 by Serhiy Storchaka in branch '3.5': Issue #6598: Avoid clock wrapping around in test_make_msgid_collisions. https://hg.python.org/cpython/rev/e259c0ab7a69 New changeset d1c11a78b43a by Serhiy Storchaka in branch 'default': Issue #6598: Avoid clock wrapping around in test_make_msgid_collisions. https://hg.python.org/cpython/rev/d1c11a78b43a New changeset bdd257d60da2 by Serhiy Storchaka in branch '2.7': Issue #6598: Avoid clock wrapping around in test_make_msgid_collisions. https://hg.python.org/cpython/rev/bdd257d60da2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 10 13:15:14 2015 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 10 Nov 2015 18:15:14 +0000 Subject: [issue25593] _sock_connect_cb can be called twice resulting in InvalidStateError In-Reply-To: <1447139794.12.0.288748898255.issue25593@psf.upfronthosting.co.za> Message-ID: <1447179314.37.0.980954818096.issue25593@psf.upfronthosting.co.za> Guido van Rossum added the comment: Please show us how to repro -- there's no way we can figure out how this "impossible" event could happen in your code without understanding your code. Is it possible that multiprocessing forked your event loop or something similarly esoteric? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 10 15:09:27 2015 From: report at bugs.python.org (SilentGhost) Date: Tue, 10 Nov 2015 20:09:27 +0000 Subject: [issue25594] enum instance attribute access possible In-Reply-To: <1447144067.5.0.526378354242.issue25594@psf.upfronthosting.co.za> Message-ID: <1447186167.25.0.825912429428.issue25594@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- components: -Documentation stage: test needed -> needs patch title: enum docs outdated re attribute access -> enum instance attribute access possible _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 10 15:50:50 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 10 Nov 2015 20:50:50 +0000 Subject: [issue25339] sys.stdout.errors is set to "surrogateescape" In-Reply-To: <1444287088.0.0.588605250096.issue25339@psf.upfronthosting.co.za> Message-ID: <1447188650.42.0.197662299382.issue25339@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The default encoding of sys.stdio and sys.stdout is determined by (in order of increasing precedence): 1. locale 2. PYTHONIOENCODING 3. Py_SetStandardStreamEncoding() The default error handler before 3.5 was determined by: 1. 'strict' 2. PYTHONIOENCODING 3. Py_SetStandardStreamEncoding() The default error handler since 3.5 (issue19977) is determined by: 1. PYTHONIOENCODING 2. locale 3. Py_SetStandardStreamEncoding() Even if you explicitly specified the error handler by PYTHONIOENCODING, it doesn't have effect in POSIX locale. This doesn't look right to me. I think the order should be the same as for encoding. Proposed patch makes PYTHONIOENCODING to override locale default for error handler. ---------- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file41004/default_io_error_handle.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 10 16:15:12 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 10 Nov 2015 21:15:12 +0000 Subject: [issue24848] Warts in UTF-7 error handling In-Reply-To: <1439364965.73.0.526700604341.issue24848@psf.upfronthosting.co.za> Message-ID: <1447190112.75.0.299459036564.issue24848@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 10 16:53:45 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 10 Nov 2015 21:53:45 +0000 Subject: [issue25599] asyncio.iscoroutinefunction returns unexpected results when presented with unittest.mock.Mock In-Reply-To: <1447176382.09.0.498269327302.issue25599@psf.upfronthosting.co.za> Message-ID: <1447192425.94.0.68798086103.issue25599@psf.upfronthosting.co.za> STINNER Victor added the comment: >>> asyncio.iscoroutinefunction(unittest.mock.Mock()) Yeah, I already had this issue when I wrote unit tests using mock :-/ I didn't find an obvious fix for this issue, and it's quite easy to workaround it. It looks like the "m._is_coroutine = False" is not used in asyncio tests. I don't recall how I worked around the issue in asyncio tests... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 10 17:31:39 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 10 Nov 2015 22:31:39 +0000 Subject: [issue25558] Use static asserts in C code In-Reply-To: <1446742000.61.0.314081889142.issue25558@psf.upfronthosting.co.za> Message-ID: <1447194699.72.0.612881238551.issue25558@psf.upfronthosting.co.za> STINNER Victor added the comment: This issue can now be closed, no? (I don't think that it's worth to add a new macro and make the existing macro more strict.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 10 18:12:01 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 10 Nov 2015 23:12:01 +0000 Subject: [issue25597] unittest.mock does not wrap dict objects correctly In-Reply-To: <1447174958.96.0.448093662654.issue25597@psf.upfronthosting.co.za> Message-ID: <1447197121.46.0.704904102861.issue25597@psf.upfronthosting.co.za> R. David Murray added the comment: Looking at the source, it's not clear that wraps is supported for __ methods, despite what the documentation implies. That is, MagicProxy doesn't seem to look at the wraps information. I suspect it is doable, but it may be an enhancement request rather than a bug fix, I'm not sure. ---------- nosy: +michael.foord, r.david.murray, rbcollins _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 10 18:19:56 2015 From: report at bugs.python.org (Stephen Ash) Date: Tue, 10 Nov 2015 23:19:56 +0000 Subject: [issue25437] Issue with ftplib.FTP_TLS and server forcing SSL connection reuse In-Reply-To: <1445197458.2.0.693285034257.issue25437@psf.upfronthosting.co.za> Message-ID: <1447197596.22.0.385750919219.issue25437@psf.upfronthosting.co.za> Changes by Stephen Ash : ---------- nosy: +Stephen Ash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 10 19:08:00 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 11 Nov 2015 00:08:00 +0000 Subject: [issue25595] test_deleted_cwd in test_importlib is failed on AIX In-Reply-To: <1447153392.75.0.692094551582.issue25595@psf.upfronthosting.co.za> Message-ID: <1447200480.18.0.411782681542.issue25595@psf.upfronthosting.co.za> Martin Panter added the comment: Wow this is tricky to get right. Victor, you are right to not trust TemporaryDirectory, because when cleanup() fails you don?t get a second chance, and it will leave the directory behind. According to the Microsoft _mkdir() web page , Windows would raise ENOTEMPTY for removing the current directory. Maybe it is time to drop the win32 skip check as well? Here is a patch based on aix_2.patch, but also removing the redundant win32 skip. And ?import errno? was no longer needed. I only tested it on Linux though, which supports removing the cwd. ---------- Added file: http://bugs.python.org/file41005/test_deleted_cwd_aix_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 10 20:31:56 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 11 Nov 2015 01:31:56 +0000 Subject: [issue25590] tab-completition on instances repeatedly accesses attribute/descriptors values In-Reply-To: <1447107343.63.0.0427300203207.issue25590@psf.upfronthosting.co.za> Message-ID: <1447205516.33.0.711444801775.issue25590@psf.upfronthosting.co.za> Martin Panter added the comment: getattr-once.patch handles my first two points. It backports the set() change, and avoids the hasattr() check. I guess we apply this to 3.4+; expect merge conflicts with 3.6. As for the last point, I will make another patch to include special attributes that don?t actually exist yet, where they are currently omitted. Would we consider this a new feature for 3.6? Going by Serhiy?s logic in I would say yes. ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file41006/getattr-once.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 10 21:02:49 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 11 Nov 2015 02:02:49 +0000 Subject: [issue25590] tab-completition on instances repeatedly accesses attribute/descriptors values In-Reply-To: <1447107343.63.0.0427300203207.issue25590@psf.upfronthosting.co.za> Message-ID: <1447207369.44.0.315950171912.issue25590@psf.upfronthosting.co.za> Martin Panter added the comment: uncreated-attr.patch is against the 3.6 branch, and includes the excessive getattr() test, and new code to include uncreated attribute names. I added a paragraph to What?s New describing the new completion behaviour. ---------- Added file: http://bugs.python.org/file41007/uncreated-attr.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 10 21:26:43 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 11 Nov 2015 02:26:43 +0000 Subject: [issue25586] socket.sendall broken when a socket has a timeout In-Reply-To: <1447019255.89.0.976606710887.issue25586@psf.upfronthosting.co.za> Message-ID: <1447208803.72.0.850820893841.issue25586@psf.upfronthosting.co.za> Martin Panter added the comment: That was kind of what I had in mind. The only change I would make is to restore the comma to ?On error (including socket timeout), an exception . . .?. I?ll try to commit this in a few days if nobody has anything else to say. ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 10 22:07:51 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 11 Nov 2015 03:07:51 +0000 Subject: [issue25583] os.makedirs with exist_ok=True raises PermissionError on Windows 7^ In-Reply-To: <1446993273.85.0.222873165522.issue25583@psf.upfronthosting.co.za> Message-ID: <1447211271.81.0.499325358525.issue25583@psf.upfronthosting.co.za> Martin Panter added the comment: It is good to add a regression test for any bug if it?s not too hard. Yes this is not a Windows-only issue, but I understand it is much simpler to produce with Windows. Otherwise you need a special file system setup and a more obscure OS. Please review my patch. It would be good to confirm that the test fails on Windows if the fix is not applied. I have only tested this on Linux, and indirectly via Wine. ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file41008/makedirs-exist.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 10 23:31:02 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 11 Nov 2015 04:31:02 +0000 Subject: [issue25498] Python 3.4.3 core dump with simple sample code In-Reply-To: <1446055572.58.0.349657416945.issue25498@psf.upfronthosting.co.za> Message-ID: <1447216262.32.0.894223208425.issue25498@psf.upfronthosting.co.za> Martin Panter added the comment: I propose this patch, based on Eryksun?s patch (thanks Eryksun). New changes: * Added test case * Applied Serhiy?s review suggestion * Changed the new BufferError exceptions back to TypeError to match previous behaviour and test cases ---------- nosy: +eryksun Added file: http://bugs.python.org/file41009/ctypes_from_buffer_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 11 00:48:12 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 11 Nov 2015 05:48:12 +0000 Subject: [issue25498] Python 3.4.3 core dump with simple sample code In-Reply-To: <1446055572.58.0.349657416945.issue25498@psf.upfronthosting.co.za> Message-ID: <1447220892.26.0.117619892312.issue25498@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Added new comments on Rietveld. Would be nice to add tests for read-only and non-contiguous buffers. eryksun, what is your real name? What we have to add in the Misc/ACKS file? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 11 00:48:59 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 11 Nov 2015 05:48:59 +0000 Subject: [issue24661] CGIHTTPServer: premature unescaping of query string In-Reply-To: <1437228241.83.0.784813490758.issue24661@psf.upfronthosting.co.za> Message-ID: <1447220939.4.0.765185621974.issue24661@psf.upfronthosting.co.za> Martin Panter added the comment: The CGI server no longer unquotes the query string thanks to the fix for Issue 24657. The fix should be in the next (2.7.11) release. ---------- nosy: +martin.panter resolution: -> out of date stage: -> resolved status: open -> closed superseder: -> CGIHTTPServer module discard continuous '/' letters from params given by GET method. type: -> behavior versions: +Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 11 01:15:39 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 11 Nov 2015 06:15:39 +0000 Subject: [issue25590] tab-completition on instances repeatedly accesses attribute/descriptors values In-Reply-To: <1447107343.63.0.0427300203207.issue25590@psf.upfronthosting.co.za> Message-ID: <1447222539.16.0.129810436229.issue25590@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Both patches LGTM. Thank you Martin. > Would we consider this a new feature for 3.6? We can consider this a fix of the regression in issue449227. But this behavior here is so long. I agree with applying it to 3.6 only. For nicer Mercurial history, it would be better to apply both patches separately in 3.6. Would not be simpler to use uninitialized slot attribute in test_uncreated_attr? ---------- assignee: -> martin.panter stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 11 01:24:17 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 11 Nov 2015 06:24:17 +0000 Subject: [issue25595] test_deleted_cwd in test_importlib is failed on AIX In-Reply-To: <1447153392.75.0.692094551582.issue25595@psf.upfronthosting.co.za> Message-ID: <1447223057.5.0.513692838398.issue25595@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Martin's original code looked nicer to me. It' a pity we can't use it. test_deleted_cwd_aix_3.patch LGTM. Thanks Martin! ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 11 01:27:35 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 11 Nov 2015 06:27:35 +0000 Subject: [issue25595] test_deleted_cwd in test_importlib is failed on AIX In-Reply-To: <1447153392.75.0.692094551582.issue25595@psf.upfronthosting.co.za> Message-ID: <20151111062732.17075.23340@psf.io> Roundup Robot added the comment: New changeset d4dc36586f24 by Serhiy Storchaka in branch '3.5': Issue #25595: Fixed test_deleted_cwd in test_importlib on AIX. https://hg.python.org/cpython/rev/d4dc36586f24 New changeset 3f392050d519 by Serhiy Storchaka in branch 'default': Issue #25595: Fixed test_deleted_cwd in test_importlib on AIX. https://hg.python.org/cpython/rev/3f392050d519 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 11 01:28:06 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 11 Nov 2015 06:28:06 +0000 Subject: [issue25595] test_deleted_cwd in test_importlib is failed on AIX In-Reply-To: <1447153392.75.0.692094551582.issue25595@psf.upfronthosting.co.za> Message-ID: <1447223286.06.0.734691142442.issue25595@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 11 02:30:12 2015 From: report at bugs.python.org (mcer45) Date: Wed, 11 Nov 2015 07:30:12 +0000 Subject: [issue25600] argparse, argument_default=argparse.SUPPRESS seems to have no effect Message-ID: <1447227012.01.0.302996872959.issue25600@psf.upfronthosting.co.za> New submission from mcer45: The parameter argument_default=argparse.SUPPRESS seems to have no effect. Example: ===================================================================== help_dirs='ahoy parser = argparse.ArgumentParser( formatter_class=argparse.RawDescriptionHelpFormatter, description='Makes the calendar for the "year"', epilog=textwrap.dedent(help_dirs)) parser.add_argument("user", help='the user directory with the required structure in ./') parser.add_argument("year", type=int, help='the year for this calendar and also the directory for the output') parser.add_argument("-acc","--acc", default='no',nargs='?',choices=['yes','no'],const='yes', help='accomodate ratio according to the cover photo, default=no') parser.add_argument("--color",default='gold', choices=['gold'], help='default color: gold') args = parser.parse_args(['mc', '2015']) print(args) del parser del args parser = argparse.ArgumentParser(argument_default=argparse.SUPPRESS, formatter_class=argparse.RawDescriptionHelpFormatter, description='Makes the calendar for the "year"', epilog=textwrap.dedent(help_dirs)) parser.add_argument("user", help='the user directory with the required structure in ./') parser.add_argument("year", type=int, help='the year for this calendar and also the directory for the output') parser.add_argument("-acc","--acc", default='no',nargs='?',choices=['yes','no'],const='yes', help='accomodate ratio according to the cover photo, default=no') parser.add_argument("--color",default='gold', choices=['gold'], help='default color: gold') args = parser.parse_args(['mc', '2015']) =================================== The results in both cases are the same: Namespace(acc='no', color='gold', user='mc', year=2015) I hoped the defaults will be suppressed. ---------- components: Library (Lib) messages: 254478 nosy: bethard, mcer45 priority: normal severity: normal status: open title: argparse, argument_default=argparse.SUPPRESS seems to have no effect type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 11 02:54:13 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 11 Nov 2015 07:54:13 +0000 Subject: [issue7759] mhlib fails on Btrfs filesystem (test_mhlib failure) In-Reply-To: <1264198934.84.0.705718671648.issue7759@psf.upfronthosting.co.za> Message-ID: <1447228453.84.0.747080935406.issue7759@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The new buildbot edelsohn-sles-z is red from its setting at 19 Aug 2015. test_mhlib is the only failed test. http://buildbot.python.org/all/builders/s390x%20SLES%202.7/builds/114/steps/test/logs/stdio ====================================================================== FAIL: test_listfolders (test.test_mhlib.MhlibTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/dje/cpython-buildarea/2.7.edelsohn-sles-z/build/Lib/test/test_mhlib.py", line 185, in test_listfolders eq(folders, tfolders) AssertionError: Lists differ: [] != ['deep', 'deep/f1', 'deep/f2',... Second list contains 6 additional elements. First extra element 0: deep - [] + ['deep', 'deep/f1', 'deep/f2', 'deep/f2/f3', 'inbox', 'wide'] ---------------------------------------------------------------------- I think we should fix this issue. Proposed patch adds a test that we can use nlinks for count a number of subdirectories. ---------- keywords: +patch nosy: +David.Edelsohn, serhiy.storchaka status: closed -> open versions: -Python 2.6 Added file: http://bugs.python.org/file41010/mhlib_nlinks_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 11 03:07:33 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 11 Nov 2015 08:07:33 +0000 Subject: [issue7759] mhlib fails on Btrfs filesystem (test_mhlib failure) In-Reply-To: <1264198934.84.0.705718671648.issue7759@psf.upfronthosting.co.za> Message-ID: <1447229253.94.0.64889388198.issue7759@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is even simpler and more reliable patch. It works even if the subfolder is a symlink to the directory on the filesystem that doesn't support links counting for directories. ---------- Added file: http://bugs.python.org/file41011/mhlib_nlinks_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 11 03:15:06 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 11 Nov 2015 08:15:06 +0000 Subject: [issue25263] test_tkinter fails randomly on the buildbots "AMD64 Windows10" (3.4, 3.5, 3.x) In-Reply-To: <1443513254.01.0.657938826089.issue25263@psf.upfronthosting.co.za> Message-ID: <1447229706.23.0.0723076701157.issue25263@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Tests are fixed. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 11 03:20:36 2015 From: report at bugs.python.org (=?utf-8?q?Jacek_Ko=C5=82odziej?=) Date: Wed, 11 Nov 2015 08:20:36 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <1447230036.82.0.267447381833.issue23883@psf.upfronthosting.co.za> Changes by Jacek Ko?odziej : Added file: http://bugs.python.org/file41012/Issue23883_all.v6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 11 03:22:30 2015 From: report at bugs.python.org (=?utf-8?q?Jacek_Ko=C5=82odziej?=) Date: Wed, 11 Nov 2015 08:22:30 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <1447230150.41.0.257126373699.issue23883@psf.upfronthosting.co.za> Jacek Ko?odziej added the comment: Serhiy, thank you for the review. I've made proposed changes (along with rebasing Issue23883_all patch; Issue23883_test_gettext.v3.patch still applies cleanly). ---------- Added file: http://bugs.python.org/file41013/Issue23883_support_check__all__.v6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 11 03:31:35 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 11 Nov 2015 08:31:35 +0000 Subject: [issue25601] test_cpickle failure on the ware-gentoo-x86 builbot Message-ID: <1447230695.36.0.35114709633.issue25601@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: http://buildbot.python.org/all/builders/x86%20Gentoo%20Non-Debug%20with%20X%202.7/builds/100/steps/test/logs/stdio There are a lot of failures, all look as: ====================================================================== ERROR: test_simple_newobj (test.test_cpickle.FileIOCPicklerFastTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/buildbot/buildarea/2.7.ware-gentoo-x86/build/Lib/test/pickletester.py", line 1145, in test_simple_newobj s = self.dumps(x, proto) File "/buildbot/buildarea/2.7.ware-gentoo-x86/build/Lib/test/test_cpickle.py", line 141, in dumps p.dump(arg) AttributeError: 'module' object has no attribute '_reduce_ex' ---------------------------------------------------------------------- It looks as the _reduce_ex() function is missed in the copy_reg module. Have no ideas how it is possible. ---------- messages: 254483 nosy: serhiy.storchaka, zach.ware priority: normal severity: normal status: open title: test_cpickle failure on the ware-gentoo-x86 builbot _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 11 03:35:04 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 11 Nov 2015 08:35:04 +0000 Subject: [issue25601] test_cpickle failure on the ware-gentoo-x86 builbot In-Reply-To: <1447230695.36.0.35114709633.issue25601@psf.upfronthosting.co.za> Message-ID: <1447230904.79.0.116335545.issue25601@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Tests type: -> behavior versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 11 03:35:19 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 11 Nov 2015 08:35:19 +0000 Subject: [issue25601] test_cpickle failure on the ware-gentoo-x86 builbot In-Reply-To: <1447230695.36.0.35114709633.issue25601@psf.upfronthosting.co.za> Message-ID: <1447230919.69.0.16966365202.issue25601@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +alexandre.vassalotti, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 11 04:09:51 2015 From: report at bugs.python.org (Alexander Mohr) Date: Wed, 11 Nov 2015 09:09:51 +0000 Subject: [issue25593] _sock_connect_cb can be called twice resulting in InvalidStateError In-Reply-To: <1447139794.12.0.288748898255.issue25593@psf.upfronthosting.co.za> Message-ID: <1447232991.25.0.43847757486.issue25593@psf.upfronthosting.co.za> Alexander Mohr added the comment: Sorry for being obscure before, it was hard to pinpoint. I think I just figured it out! I had code like this in a subprocess: def worker(): while True: obj = self.queue.get() # do work with obj using asyncio http module def producer(): nonlocal self obj2 = self.queue.get() return obj2 workers = [] for i in range(FILE_OP_WORKERS): t = asyncio.ensure_future(worker()) t.add_done_callback(op_finished) workers.append(t) while True: f = loop.run_in_executor(None, producer) obj = loop.run_until_complete(f) t = async_queue.put(obj) loop.run_until_complete(t) loop.run_until_complete(asyncio.wait(workers)) where self.queue is a multiprocessing.Queue, and async_queue is an asyncio queue. The idea is that I have a process populating a multiprocessing queue, and I want to transfer it to an syncio queue while letting the workers do their thing. Without knowing the underlying behavior, my theory is that when python blocks on the multiprocessing queue lock, it releases socket events to the async http module's selectors, and then when the async loop gets to the selectors they're released again. If I switch the producer to instead use a queue.get_nowait and busy wait with asyncio.sleep I don't get the error...however this is not ideal is we're busy waiting. Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 11 05:55:59 2015 From: report at bugs.python.org (Stefan Krah) Date: Wed, 11 Nov 2015 10:55:59 +0000 Subject: [issue25598] Fix memory_hex (#9951) for non-contiguous buffers In-Reply-To: <1447174975.72.0.408489689517.issue25598@psf.upfronthosting.co.za> Message-ID: <1447239359.11.0.987262088808.issue25598@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 11 06:46:08 2015 From: report at bugs.python.org (Jakub Klama) Date: Wed, 11 Nov 2015 11:46:08 +0000 Subject: [issue25602] Add support for EVFILT_USER kqueue filter Message-ID: <1447242368.46.0.687277732517.issue25602@psf.upfronthosting.co.za> New submission from Jakub Klama: It's useful for doing signaling between threads (especially I/O-bound threads). Related github pull request: https://github.com/python/cpython/pull/23 ---------- components: Library (Lib) files: 0001-Add-support-for-EVFILT_USER-kqueue-filter.patch keywords: patch messages: 254485 nosy: jceel priority: normal severity: normal status: open title: Add support for EVFILT_USER kqueue filter type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file41014/0001-Add-support-for-EVFILT_USER-kqueue-filter.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 11 09:16:11 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 11 Nov 2015 14:16:11 +0000 Subject: [issue25600] argparse, argument_default=argparse.SUPPRESS seems to have no effect In-Reply-To: <1447227012.01.0.302996872959.issue25600@psf.upfronthosting.co.za> Message-ID: <1447251371.09.0.209793733852.issue25600@psf.upfronthosting.co.za> R. David Murray added the comment: If you specify a default for an argument, that overrides the global default. ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 11 09:22:54 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 11 Nov 2015 14:22:54 +0000 Subject: [issue7759] mhlib fails on Btrfs filesystem (test_mhlib failure) In-Reply-To: <1264198934.84.0.705718671648.issue7759@psf.upfronthosting.co.za> Message-ID: <1447251774.01.0.790099710174.issue7759@psf.upfronthosting.co.za> R. David Murray added the comment: Sure, why not. Having buildbots be green is good, and I doubt anyone is using mhlib any more even in python2. And if they are the chances this will break something seems extremely small. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 11 09:48:34 2015 From: report at bugs.python.org (Alexander Mohr) Date: Wed, 11 Nov 2015 14:48:34 +0000 Subject: [issue25593] _sock_connect_cb can be called twice resulting in InvalidStateError In-Reply-To: <1447139794.12.0.288748898255.issue25593@psf.upfronthosting.co.za> Message-ID: <1447253314.67.0.7009652299.issue25593@psf.upfronthosting.co.za> Alexander Mohr added the comment: I'm going to close this as I've found a work-around, if I find a better test-case I'll open a new bug. ---------- resolution: -> later status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 11 10:33:48 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 11 Nov 2015 15:33:48 +0000 Subject: [issue7759] mhlib fails on Btrfs filesystem (test_mhlib failure) In-Reply-To: <1264198934.84.0.705718671648.issue7759@psf.upfronthosting.co.za> Message-ID: <20151111153339.58399.85757@psf.io> Roundup Robot added the comment: New changeset 37431d9abbcd by Serhiy Storchaka in branch '2.7': Issue #7759: Fixed the mhlib module on filesystems that doesn't support https://hg.python.org/cpython/rev/37431d9abbcd ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 11 10:38:33 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 11 Nov 2015 15:38:33 +0000 Subject: [issue25601] test_cpickle failure on the ware-gentoo-x86 buildbot In-Reply-To: <1447230695.36.0.35114709633.issue25601@psf.upfronthosting.co.za> Message-ID: <1447256313.73.0.415142622618.issue25601@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- title: test_cpickle failure on the ware-gentoo-x86 builbot -> test_cpickle failure on the ware-gentoo-x86 buildbot _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 11 11:38:53 2015 From: report at bugs.python.org (Zachary Ware) Date: Wed, 11 Nov 2015 16:38:53 +0000 Subject: [issue25601] test_cpickle failure on the ware-gentoo-x86 buildbot In-Reply-To: <1447230695.36.0.35114709633.issue25601@psf.upfronthosting.co.za> Message-ID: <1447259933.02.0.329718256334.issue25601@psf.upfronthosting.co.za> Zachary Ware added the comment: I also have no idea how that happened, but seems to have been a fluke. Build 101 is fine, and nothing has changed on that box. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 11 11:50:39 2015 From: report at bugs.python.org (Theron Luhn) Date: Wed, 11 Nov 2015 16:50:39 +0000 Subject: [issue25599] asyncio.iscoroutinefunction returns unexpected results when presented with unittest.mock.Mock In-Reply-To: <1447176382.09.0.498269327302.issue25599@psf.upfronthosting.co.za> Message-ID: <1447260639.53.0.0574192699335.issue25599@psf.upfronthosting.co.za> Theron Luhn added the comment: For me, the context is a test I was writing that went something like this: >>> import asyncio >>> from unittest.mock import Mock >>> loop = asyncio.get_event_loop() >>> blocking_func = Mock() >>> loop.run_in_executor(None, blocking_func) Traceback (most recent call last): File "", line 1, in File "/usr/local/Cellar/python3/3.5.0/Frameworks/Python.framework/Versions/3.5/lib/python3.5/asyncio/base_events.py", line 497, in run_in_executor raise TypeError("coroutines cannot be used with run_in_executor()") TypeError: coroutines cannot be used with run_in_executor() I understand that the nature of Mock makes its behaviors ambiguous. However, there are a few reasons I think asyncio.iscoroutinefunction(Mock()) should be false: 1) inspect.iscoroutinefunction reports false. asyncio.iscoroutinefunction should be consistent with this. 2) A coroutine function should return a coroutine object. Mock's default behavior won't return a coroutine object, so it shouldn't be identified as a coroutine function by default. 3) It's tidier to make a non-coroutine function Mock into a coroutine function (asyncio.coroutine(Mock())) than it is to make a coroutine function Mock into a non-coroutine function Mock (mock._is_coroutine is implementation-specific hack). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 11 11:52:16 2015 From: report at bugs.python.org (Zachary Ware) Date: Wed, 11 Nov 2015 16:52:16 +0000 Subject: [issue25601] test_cpickle failure on the ware-gentoo-x86 buildbot In-Reply-To: <1447230695.36.0.35114709633.issue25601@psf.upfronthosting.co.za> Message-ID: <1447260736.44.0.789215399964.issue25601@psf.upfronthosting.co.za> Zachary Ware added the comment: This also happened on my Windows buildbot: http://buildbot.python.org/all/builders/AMD64%20Windows8.1%20Non-Debug%202.7/builds/195 That build is running again as build 196. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 11 11:53:39 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 11 Nov 2015 16:53:39 +0000 Subject: [issue7759] mhlib fails on Btrfs filesystem (test_mhlib failure) In-Reply-To: <1264198934.84.0.705718671648.issue7759@psf.upfronthosting.co.za> Message-ID: <1447260819.97.0.567841211178.issue7759@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The test now is passed. ---------- resolution: wont fix -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 11 12:15:26 2015 From: report at bugs.python.org (Zachary Ware) Date: Wed, 11 Nov 2015 17:15:26 +0000 Subject: [issue25601] test_cpickle failure on the ware-gentoo-x86 buildbot In-Reply-To: <1447230695.36.0.35114709633.issue25601@psf.upfronthosting.co.za> Message-ID: <1447262126.14.0.388317062623.issue25601@psf.upfronthosting.co.za> Zachary Ware added the comment: Build 196 on the Windows bot is fine. Could be a bizarre test ordering issue? Nothing else should have changed between builds 195 and 196 on the Windows bot. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 11 12:26:01 2015 From: report at bugs.python.org (Alexander Mohr) Date: Wed, 11 Nov 2015 17:26:01 +0000 Subject: [issue25593] _sock_connect_cb can be called twice resulting in InvalidStateError In-Reply-To: <1447139794.12.0.288748898255.issue25593@psf.upfronthosting.co.za> Message-ID: <1447262761.32.0.34704608054.issue25593@psf.upfronthosting.co.za> Alexander Mohr added the comment: Actually, I just realized I had fixed it locally by changing the callback to the following: 429 def _sock_connect_cb(self, fut, sock, address): 430 if fut.cancelled() or fut.done(): 431 return so a fix is still needed, and I also verified this happens with python3.4 as well. ---------- status: closed -> open versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 11 12:30:15 2015 From: report at bugs.python.org (Alexander Mohr) Date: Wed, 11 Nov 2015 17:30:15 +0000 Subject: [issue25593] _sock_connect_cb can be called twice resulting in InvalidStateError In-Reply-To: <1447139794.12.0.288748898255.issue25593@psf.upfronthosting.co.za> Message-ID: <1447263015.93.0.232616636818.issue25593@psf.upfronthosting.co.za> Alexander Mohr added the comment: clarification, adding the fut.done() check, or monkey patching: orig_sock_connect_cb = asyncio.selector_events.BaseSelectorEventLoop._sock_connect_cb def _sock_connect_cb(self, fut, sock, address): if fut.done(): return return orig_sock_connect_cb(self, fut, sock, address) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 11 13:43:55 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 11 Nov 2015 18:43:55 +0000 Subject: [issue21748] glob.glob does not sort its results In-Reply-To: <1402666303.8.0.471997942959.issue21748@psf.upfronthosting.co.za> Message-ID: <1447267435.17.0.406823610932.issue21748@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 11 16:33:51 2015 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 11 Nov 2015 21:33:51 +0000 Subject: [issue25593] _sock_connect_cb can be called twice resulting in InvalidStateError In-Reply-To: <1447263015.93.0.232616636818.issue25593@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Sorry, the code you posted is still incomprehensible. E.g. I suppose your worker doesn't really have ``` obj = self.queue.get() ``` but rather something like ``` obj = yield from async_queue.get() ``` But in the end, even with that hypothesis, I can't explain what you're seeing, and I believe there is a bug related to bad mixing multiprocessing and asyncio in some code you're not showing, and your "fix" just masks the problem. Note that the code you posted doesn't touch sockets in any way, while the issue you're seeing is related to sockets. So there *must* be more to it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 11 17:01:29 2015 From: report at bugs.python.org (Alexander Mohr) Date: Wed, 11 Nov 2015 22:01:29 +0000 Subject: [issue25593] _sock_connect_cb can be called twice resulting in InvalidStateError In-Reply-To: <1447139794.12.0.288748898255.issue25593@psf.upfronthosting.co.za> Message-ID: <1447279289.26.0.619332445484.issue25593@psf.upfronthosting.co.za> Alexander Mohr added the comment: self.queue is not an async queue, as I stated above its a multiprocessing queue. This code is to multiplex a multiprocessing queue to a async queue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 11 17:30:13 2015 From: report at bugs.python.org (Derek Wilson) Date: Wed, 11 Nov 2015 22:30:13 +0000 Subject: [issue18689] add argument for formatter to logging.Handler and subclasses in logging module In-Reply-To: <1375992937.35.0.58426954587.issue18689@psf.upfronthosting.co.za> Message-ID: <1447281013.16.0.309780332526.issue18689@psf.upfronthosting.co.za> Derek Wilson added the comment: > It's not an ideal world. Sorry, but I think this change is too invasive to consider. Obviously its not ideal, which is why my suggestion doesn't require intelligent 3rd party libraries and is explicitly not invasive. As I said in my previous comment, using a keyword only argument means: "If [3rd party libraries] haven't [properly handled **kwargs] then nothing changes for them and they just support exactly the same features they supported previously." The upshot is it is not invasive and no one needs to care unless they want to use the new functionality. As far as this change being needed or not, nothing "needs" to be made easier to use if it is possible to use it. But that isn't really a good reason not to improve things. I honestly think that part of the reason this hasn't come up is because the advanced features of logging are so difficult to use that people just don't use it to its fullest extent. On top of that, when learning python, logging is way harder to grok than it should be for someone new to python. Logging and unittest are two of the most important libraries for new pythonistas to learn, but they are also some of the most nebulous, stateful, magical, java-like, complicated, verbose, and difficult to master packages in python. They've been around for a while for sure - but doesn't that rather mean that they could use an update? I'm willing to submit a patch if it has the smallest chance of being considered? ---------- versions: +Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 11 18:08:13 2015 From: report at bugs.python.org (Justin Mayfield) Date: Wed, 11 Nov 2015 23:08:13 +0000 Subject: [issue25593] _sock_connect_cb can be called twice resulting in InvalidStateError In-Reply-To: <1447139794.12.0.288748898255.issue25593@psf.upfronthosting.co.za> Message-ID: <1447283293.09.0.514552084578.issue25593@psf.upfronthosting.co.za> Justin Mayfield added the comment: I believe I'm seeing this bug in a non-threaded and non-forked env. System: OSX 10.11.1 (15B42) Python 3.5.0 (from brew install) I'm using aiohttp to create several dozens of HTTP connections to the same server (an async tornado web server). Nothing special is being done around the event loop creation (standard get_event_loop()). However in my system the event loop is frequently stopped, via ioloop.stop(), and restarted via ioloop.run_forever(). I'm not sure this is related to the issue yet, but it's worth mentioning. I can't provide simplified test code just yet, but I can reproduce in my env with nearly 100% odds when doing a full system test. Attached is a sample backtrace. ---------- nosy: +Justin Mayfield Added file: http://bugs.python.org/file41015/asyncio_invalid_state_bt.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 11 18:26:10 2015 From: report at bugs.python.org (Alexander Mohr) Date: Wed, 11 Nov 2015 23:26:10 +0000 Subject: [issue25593] _sock_connect_cb can be called twice resulting in InvalidStateError In-Reply-To: <1447139794.12.0.288748898255.issue25593@psf.upfronthosting.co.za> Message-ID: <1447284370.15.0.885887607456.issue25593@psf.upfronthosting.co.za> Alexander Mohr added the comment: Perhaps I'm doing something really stupid, but I was able to reproduce the two issues I'm having with the following sample script. If you leave the monkey patch disabled, you get the InvalidStateError, if you enable it, you get the ServerDisconnect errors that I'm currently seeing which I work-around with retries. Ideas? import asyncio import aiohttp import multiprocessing import aiohttp.server import logging import traceback # Monkey patching import asyncio.selector_events # http://bugs.python.org/issue25593 if False: orig_sock_connect_cb = asyncio.selector_events.BaseSelectorEventLoop._sock_connect_cb def _sock_connect_cb(self, fut, sock, address): if fut.done(): return return orig_sock_connect_cb(self, fut, sock, address) asyncio.selector_events.BaseSelectorEventLoop._sock_connect_cb = _sock_connect_cb class HttpRequestHandler(aiohttp.server.ServerHttpProtocol): @asyncio.coroutine def handle_request(self, message, payload): response = aiohttp.Response(self.writer, 200, http_version=message.version) response.add_header('Content-Type', 'text/html') response.add_header('Content-Length', '18') response.send_headers() yield from asyncio.sleep(0.5) response.write(b'

It Works!

') yield from response.write_eof() def process_worker(q): loop = asyncio.get_event_loop() #loop.set_debug(True) connector = aiohttp.TCPConnector(force_close=False, keepalive_timeout=8, use_dns_cache=True) session = aiohttp.ClientSession(connector=connector) async_queue = asyncio.Queue(100) @asyncio.coroutine def async_worker(session, async_queue): while True: try: print("blocking on asyncio queue get") url = yield from async_queue.get() print("unblocking on asyncio queue get") print("get aqueue size:", async_queue.qsize()) response = yield from session.request('GET', url) try: data = yield from response.read() print(data) finally: yield from response.wait_for_close() except: traceback.print_exc() def producer(q): print("blocking on multiprocessing queue get") obj2 = q.get() print("unblocking on multiprocessing queue get") print("get qempty:", q.empty()) return obj2 def worker_done(f): try: f.result() print("worker exited") except: traceback.print_exc() workers = [] for i in range(100): t = asyncio.ensure_future(async_worker(session, async_queue)) t.add_done_callback(worker_done) workers.append(t) @asyncio.coroutine def doit(): print("start producer") obj = yield from loop.run_in_executor(None, producer, q) print("finish producer") print("blocking on asyncio queue put") yield from async_queue.put(obj) print("unblocking on asyncio queue put") print("put aqueue size:", async_queue.qsize()) while True: loop.run_until_complete(doit()) def server(): loop = asyncio.get_event_loop() #loop.set_debug(True) f = loop.create_server(lambda: HttpRequestHandler(debug=True, keep_alive=75), '0.0.0.0', '8080') srv = loop.run_until_complete(f) loop.run_forever() if __name__ == '__main__': q = multiprocessing.Queue(100) log_proc = multiprocessing.log_to_stderr() log_proc.setLevel(logging.DEBUG) p = multiprocessing.Process(target=process_worker, args=(q,)) p.start() p2 = multiprocessing.Process(target=server) p2.start() while True: print("blocking on multiprocessing queue put") q.put("http://0.0.0.0:8080") print("unblocking on multiprocessing queue put") print("put qempty:", q.empty()) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 11 18:46:12 2015 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 11 Nov 2015 23:46:12 +0000 Subject: [issue25593] _sock_connect_cb can be called twice resulting in InvalidStateError In-Reply-To: <1447284370.15.0.885887607456.issue25593@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: I wonder if the bug is in aiohttp? The code you show is still too complex to debug for me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 11 19:43:17 2015 From: report at bugs.python.org (Justin Mayfield) Date: Thu, 12 Nov 2015 00:43:17 +0000 Subject: [issue25593] _sock_connect_cb can be called twice resulting in InvalidStateError In-Reply-To: <1447139794.12.0.288748898255.issue25593@psf.upfronthosting.co.za> Message-ID: <1447288997.86.0.246718420722.issue25593@psf.upfronthosting.co.za> Justin Mayfield added the comment: Attaching simplified test setup. It does take some doing to repro so the local async server is required to make it happen (for me). When I tried just pointing to python.org it would not repro in 100 iterations, but using a local dummy server repros 100% for me. ---------- Added file: http://bugs.python.org/file41016/Issue25593_repro_client.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 11 19:43:43 2015 From: report at bugs.python.org (Justin Mayfield) Date: Thu, 12 Nov 2015 00:43:43 +0000 Subject: [issue25593] _sock_connect_cb can be called twice resulting in InvalidStateError In-Reply-To: <1447139794.12.0.288748898255.issue25593@psf.upfronthosting.co.za> Message-ID: <1447289023.54.0.581810439108.issue25593@psf.upfronthosting.co.za> Justin Mayfield added the comment: Attached server side of repro. ---------- Added file: http://bugs.python.org/file41017/Issue25593_repro_server.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 11 20:10:28 2015 From: report at bugs.python.org (Justin Mayfield) Date: Thu, 12 Nov 2015 01:10:28 +0000 Subject: [issue25593] _sock_connect_cb can be called twice resulting in InvalidStateError In-Reply-To: <1447139794.12.0.288748898255.issue25593@psf.upfronthosting.co.za> Message-ID: <1447290628.95.0.998122845808.issue25593@psf.upfronthosting.co.za> Justin Mayfield added the comment: This code repros without aiohttp when pitted against the previously attached web server (again on OSX 10.11, mid-2012 MBPr). Admittedly this may seem very arbitrary but I have better reasons in my production code for stopping an IOLoop and starting it again (which seems to be important to the reproduction steps). import asyncio loop = asyncio.get_event_loop() def batch_open(): for i in range(100): c = asyncio.ensure_future(asyncio.open_connection('127.0.0.1', 8080)) c.add_done_callback(on_resp) def on_resp(task): task.result() loop.stop() loop.call_soon(batch_open) while True: loop.run_forever() ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 11 20:17:25 2015 From: report at bugs.python.org (Justin Mayfield) Date: Thu, 12 Nov 2015 01:17:25 +0000 Subject: [issue25593] _sock_connect_cb can be called twice resulting in InvalidStateError In-Reply-To: <1447139794.12.0.288748898255.issue25593@psf.upfronthosting.co.za> Message-ID: <1447291045.23.0.0232184586425.issue25593@psf.upfronthosting.co.za> Justin Mayfield added the comment: Just reproduced on Linux, Fedora Core 23. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 11 20:17:55 2015 From: report at bugs.python.org (Alexander Mohr) Date: Thu, 12 Nov 2015 01:17:55 +0000 Subject: [issue25593] _sock_connect_cb can be called twice resulting in InvalidStateError In-Reply-To: <1447139794.12.0.288748898255.issue25593@psf.upfronthosting.co.za> Message-ID: <1447291075.69.0.654223306017.issue25593@psf.upfronthosting.co.za> Alexander Mohr added the comment: attaching my simplified testcase and logged an aiohttp bug: https://github.com/KeepSafe/aiohttp/issues/633 ---------- Added file: http://bugs.python.org/file41018/test_app.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 11 20:47:23 2015 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 12 Nov 2015 01:47:23 +0000 Subject: [issue25593] _sock_connect_cb can be called twice resulting in InvalidStateError In-Reply-To: <1447291075.69.0.654223306017.issue25593@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Justin's repro provides a clue: when the event loop is stopped before all callbacks have been processed, when the loop is restarted the I/O selector is asked again to do its work, and it will report all the same sockets as ready. So then the callback will be put into the ready queue again (even though it's already there). Then the second call will find the future already done. I'm not sure how this explains Alexander's issue but it's probably something similar. We should carefully review the other I/O callbacks too -- most of them look like they don't mind being called spuriously, but there are a few others (_sock_recv, _sock_sendall, _sock_accept) that look like they check for fut.cancelled() and might be susceptible to the same bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 11 21:14:15 2015 From: report at bugs.python.org (Justin Mayfield) Date: Thu, 12 Nov 2015 02:14:15 +0000 Subject: [issue25593] _sock_connect_cb can be called twice resulting in InvalidStateError In-Reply-To: <1447139794.12.0.288748898255.issue25593@psf.upfronthosting.co.za> Message-ID: <1447294455.91.0.0895660325336.issue25593@psf.upfronthosting.co.za> Justin Mayfield added the comment: Guido, Shouldn't this not be the case for level triggered polling? From looking at selectors it looks like these are always level triggered which means they should only event once. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 11 21:39:43 2015 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 12 Nov 2015 02:39:43 +0000 Subject: [issue25593] _sock_connect_cb can be called twice resulting in InvalidStateError In-Reply-To: <1447294455.91.0.0895660325336.issue25593@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: I'm not an expert on this terminology but don't you have that backwards? Assume we're using select() for a second. If you ask select() "is this FD ready" several times in a row without doing something to the FD it will answer yes every time once the FD is ready. IIUC that's what level-triggered means, and that's what causes the bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 11 21:52:55 2015 From: report at bugs.python.org (Matthias welp) Date: Thu, 12 Nov 2015 02:52:55 +0000 Subject: [issue25603] spelling mistake - 26.1 typing Message-ID: <1447296775.39.0.293549670767.issue25603@psf.upfronthosting.co.za> New submission from Matthias welp: Almost at the end of the page, under Usage of Typing.NamedTuple(...), this code snippet occurs: `Employee = typing.NamedTuple('Employee', [('name', str), 'id', int)])`. Unfortunately, this has an error in its parenthesis. This can easily be fixed by adding an opening bracket before the `'id'`-part, as seen here: `Employee = typing.NamedTuple('Employee', [('name', str), ('id', int)])`. ---------- assignee: docs at python components: Documentation messages: 254511 nosy: Matthias welp, docs at python priority: normal severity: normal status: open title: spelling mistake - 26.1 typing type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 11 21:54:11 2015 From: report at bugs.python.org (Justin Mayfield) Date: Thu, 12 Nov 2015 02:54:11 +0000 Subject: [issue25593] _sock_connect_cb can be called twice resulting in InvalidStateError In-Reply-To: <1447139794.12.0.288748898255.issue25593@psf.upfronthosting.co.za> Message-ID: <1447296851.02.0.907368351947.issue25593@psf.upfronthosting.co.za> Justin Mayfield added the comment: Nevermind, in the case of writeablity it won't matter either way. -- So in looking at tornado's ioloop they run the ready callbacks before calling poll(). So the callbacks can modify the poll set. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 11 22:47:54 2015 From: report at bugs.python.org (Justin Mayfield) Date: Thu, 12 Nov 2015 03:47:54 +0000 Subject: [issue25593] _sock_connect_cb can be called twice resulting in InvalidStateError In-Reply-To: <1447139794.12.0.288748898255.issue25593@psf.upfronthosting.co.za> Message-ID: <1447300074.71.0.0396309712487.issue25593@psf.upfronthosting.co.za> Justin Mayfield added the comment: I'm attaching a patch that runs `_ready` callbacks at the start of `_run_once`. The style and implications are ranging so I leave it to you at this point. ---------- keywords: +patch Added file: http://bugs.python.org/file41019/run_once_testfix_for_Issue25593.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 11 23:59:42 2015 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 12 Nov 2015 04:59:42 +0000 Subject: [issue25593] _sock_connect_cb can be called twice resulting in InvalidStateError In-Reply-To: <1447139794.12.0.288748898255.issue25593@psf.upfronthosting.co.za> Message-ID: <1447304382.87.0.264315316523.issue25593@psf.upfronthosting.co.za> Guido van Rossum added the comment: Thanks, but I don't like the idea of that patch. It feels like a hack that makes it less likely that the issue occurs, but I don't feel we should rely on the callbacks being called before checking the selector again. There may be other reasons (perhaps a future modification to the code) why we might occasionally check the selector redundantly. IOW I think we should really ensure that all I/O callbacks are properly idempotent. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 00:00:18 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 12 Nov 2015 05:00:18 +0000 Subject: [issue25603] spelling mistake - 26.1 typing In-Reply-To: <1447296775.39.0.293549670767.issue25603@psf.upfronthosting.co.za> Message-ID: <20151112050013.92474.97772@psf.io> Roundup Robot added the comment: New changeset 81cc0cea2323 by Zachary Ware in branch '3.5': Issue #25603: Add missing parenthesis. https://hg.python.org/cpython/rev/81cc0cea2323 New changeset 1af59662f6d5 by Zachary Ware in branch 'default': Closes #25603: Merge with 3.5 https://hg.python.org/cpython/rev/1af59662f6d5 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 00:00:52 2015 From: report at bugs.python.org (Zachary Ware) Date: Thu, 12 Nov 2015 05:00:52 +0000 Subject: [issue25603] spelling mistake - 26.1 typing In-Reply-To: <1447296775.39.0.293549670767.issue25603@psf.upfronthosting.co.za> Message-ID: <1447304452.83.0.0213149600813.issue25603@psf.upfronthosting.co.za> Zachary Ware added the comment: Thanks for the report! ---------- nosy: +zach.ware versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 00:06:22 2015 From: report at bugs.python.org (Mike Gilbert) Date: Thu, 12 Nov 2015 05:06:22 +0000 Subject: [issue24421] Race condition compiling Modules/_math.c In-Reply-To: <1433923600.68.0.73894537311.issue24421@psf.upfronthosting.co.za> Message-ID: <1447304782.84.0.591737856014.issue24421@psf.upfronthosting.co.za> Changes by Mike Gilbert : ---------- nosy: +floppymaster _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 00:45:03 2015 From: report at bugs.python.org (Berker Peksag) Date: Thu, 12 Nov 2015 05:45:03 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <1447307103.55.0.234203392073.issue23883@psf.upfronthosting.co.za> Berker Peksag added the comment: I like Martin's support.expected_module_api() suggestion in msg247167. I still find passing self to a function just to use assertCountEqual a bit weird, but I can live with that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 00:54:24 2015 From: report at bugs.python.org (Justin Mayfield) Date: Thu, 12 Nov 2015 05:54:24 +0000 Subject: [issue25593] _sock_connect_cb can be called twice resulting in InvalidStateError In-Reply-To: <1447139794.12.0.288748898255.issue25593@psf.upfronthosting.co.za> Message-ID: <1447307664.22.0.793191556512.issue25593@psf.upfronthosting.co.za> Justin Mayfield added the comment: I don't believe this is a case of nonidempotent callbacks, unless you are referring to Future.set_result(), which by design can't be called twice. The callbacks are given an inconsistent opportunity to modify the poll set because of indeterminacy in the ioloop. That being said I understand your reluctance given the amount of turmoil this has but would argue that consistency with tornado is a powerful ally and that a model where any callback using call_soon will be guaranteed the opportunity to modify the poll set is a good thing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 01:14:51 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 12 Nov 2015 06:14:51 +0000 Subject: [issue25569] Memory leak in SSLSocket.getpeercert() In-Reply-To: <1446840481.06.0.811345685129.issue25569@psf.upfronthosting.co.za> Message-ID: <20151112061445.19483.42053@psf.io> Roundup Robot added the comment: New changeset 10c3646b2d59 by Benjamin Peterson in branch '2.7': fix memory leak in _get_crl_dp (closes #25569) https://hg.python.org/cpython/rev/10c3646b2d59 New changeset aabe273b20ab by Benjamin Peterson in branch '3.4': fix memory leak in _get_crl_dp (closes #25569) https://hg.python.org/cpython/rev/aabe273b20ab New changeset 07a298572d93 by Benjamin Peterson in branch '3.5': merge 3.5 (#25569) https://hg.python.org/cpython/rev/07a298572d93 New changeset fb55b1ab43fc by Benjamin Peterson in branch 'default': merge 3.5 (#25569) https://hg.python.org/cpython/rev/fb55b1ab43fc ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 01:45:50 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 12 Nov 2015 06:45:50 +0000 Subject: [issue25530] ssl: OP_NO_SSLv3 should always be set unless a user specifically asks for it In-Reply-To: <1446405054.12.0.603454420685.issue25530@psf.upfronthosting.co.za> Message-ID: <20151112064547.21714.45075@psf.io> Roundup Robot added the comment: New changeset d80954d941c7 by Benjamin Peterson in branch '2.7': always set OP_NO_SSLv3 by default (closes #25530) https://hg.python.org/cpython/rev/d80954d941c7 New changeset 56f64ec9259f by Benjamin Peterson in branch '3.4': always set OP_NO_SSLv3 by default (closes #25530) https://hg.python.org/cpython/rev/56f64ec9259f New changeset d1737db0f1b2 by Benjamin Peterson in branch '3.5': merge 3.4 (#25530) https://hg.python.org/cpython/rev/d1737db0f1b2 New changeset 2899acbd2b46 by Benjamin Peterson in branch 'default': merge 3.5 (#25530) https://hg.python.org/cpython/rev/2899acbd2b46 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 03:09:36 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 12 Nov 2015 08:09:36 +0000 Subject: [issue25586] socket.sendall broken when a socket has a timeout In-Reply-To: <1447019255.89.0.976606710887.issue25586@psf.upfronthosting.co.za> Message-ID: <1447315776.2.0.489696219045.issue25586@psf.upfronthosting.co.za> STINNER Victor added the comment: I'm not a big fan of "may" in documentation. I would prefer to rephrase it as an advice. Example: "Considering the loss of information, it's better to not retry sending data to the socket anymore." ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 03:10:17 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 12 Nov 2015 08:10:17 +0000 Subject: [issue25586] socket.sendall broken when a socket has a timeout In-Reply-To: <1447019255.89.0.976606710887.issue25586@psf.upfronthosting.co.za> Message-ID: <1447315817.39.0.367352933817.issue25586@psf.upfronthosting.co.za> STINNER Victor added the comment: Note: socket-docs.patch file is strange, it looks like you removed the first line starting with "diff", and so we don't get the [Review] button. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 03:44:45 2015 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 12 Nov 2015 08:44:45 +0000 Subject: [issue25604] [Minor] bug in integer true division algorithm Message-ID: <1447317885.13.0.151238733995.issue25604@psf.upfronthosting.co.za> New submission from Mark Dickinson: There's a harmless but annoying (for code readers) bug in the code for true division of (long) integers. In `long_true_divide` in `Objects/longobject.c`, we have the following code for manipulating the bits of a 55- or 56-bit long to get something that will be exactly representable as a float: /* The number of extra bits that have to be rounded away. */ extra_bits = MAX(x_bits, DBL_MIN_EXP - shift) - DBL_MANT_DIG; assert(extra_bits == 2 || extra_bits == 3); /* Round by directly modifying the low digit of x. */ mask = (digit)1 << (extra_bits - 1); low = x->ob_digit[0] | inexact; if (low & mask && low & (3*mask-1)) low += mask; x->ob_digit[0] = low & ~(mask-1U); /* Convert x to a double dx; the conversion is exact. */ [...] The last code line above is supposed to be masking out all the bits that we don't want to keep. Instead, it's masking out all but one of those bits. The line x->ob_digit[0] = low & ~(mask-1U); should be replaced with x->ob_digit[0] = low & ~(2*mask-1U); As it stands, the comment about the conversion to double being exact is false. (I've verified this by converting x both to a 64-bit unsigned integer and to a double and checking that the integer and double don't always match in value; with the fix above, they do.) I don't *think* this bug actually affects the output on any platform whose arithmetic and ldexp functions do correct rounding with round-ties-to-even: the extra bit will always get rounded away (in the correct direction) by either the conversion to float (for the non-subnormal case) or by the ldexp operation (for the subnormal case). Still, the bug makes the code a bit more susceptible to platform arithmetic quirks. ---------- assignee: mark.dickinson components: Interpreter Core messages: 254523 nosy: mark.dickinson priority: low severity: normal status: open title: [Minor] bug in integer true division algorithm type: behavior versions: Python 2.7, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 03:54:22 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 12 Nov 2015 08:54:22 +0000 Subject: [issue25604] [Minor] bug in integer true division algorithm In-Reply-To: <1447317885.13.0.151238733995.issue25604@psf.upfronthosting.co.za> Message-ID: <1447318462.38.0.594684329942.issue25604@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 04:29:02 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 12 Nov 2015 09:29:02 +0000 Subject: [issue25605] fcntl doc: document exceptions raised on error for ioctl() and flock() Message-ID: <1447320542.54.0.969865888179.issue25605@psf.upfronthosting.co.za> New submission from STINNER Victor: Attached patch documents the exception raised when ioctl() or flock() functions fail. Note: flock() can also raises a ValueError if the second parameter (op) is unknown. If the patch is approved, I will write a similar patch for Python 3 (just replace IOError with OSError in Python 3 doc). Python 2 online doc: https://docs.python.org/2/library/fcntl.html Python 3 online doc: https://docs.python.org/dev/library/fcntl.html ---------- assignee: docs at python components: Documentation files: fcntl_doc.patch keywords: patch messages: 254524 nosy: docs at python, haypo priority: normal severity: normal status: open title: fcntl doc: document exceptions raised on error for ioctl() and flock() versions: Python 2.7 Added file: http://bugs.python.org/file41020/fcntl_doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 04:35:19 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 12 Nov 2015 09:35:19 +0000 Subject: [issue22995] Restrict default pickleability In-Reply-To: <1417699003.47.0.104663960497.issue22995@psf.upfronthosting.co.za> Message-ID: <20151112093516.33556.15993@psf.io> Roundup Robot added the comment: New changeset c8841db9433d by Serhiy Storchaka in branch '3.4': Issue #22995: Default implementation of __reduce__ and __reduce_ex__ now https://hg.python.org/cpython/rev/c8841db9433d New changeset 4c05e7c195ac by Serhiy Storchaka in branch '3.5': Issue #22995: Default implementation of __reduce__ and __reduce_ex__ now https://hg.python.org/cpython/rev/4c05e7c195ac New changeset a2f574896f49 by Serhiy Storchaka in branch 'default': Issue #22995: Default implementation of __reduce__ and __reduce_ex__ now https://hg.python.org/cpython/rev/a2f574896f49 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 04:37:11 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 12 Nov 2015 09:37:11 +0000 Subject: [issue22995] Restrict default pickleability In-Reply-To: <1417699003.47.0.104663960497.issue22995@psf.upfronthosting.co.za> Message-ID: <20151112093709.21712.2051@psf.io> Roundup Robot added the comment: New changeset 94664fb4354e by Serhiy Storchaka in branch '2.7': Issue #22995: Backported additional tests for non-pickleable types. https://hg.python.org/cpython/rev/94664fb4354e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 04:55:28 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 12 Nov 2015 09:55:28 +0000 Subject: [issue25606] asyncio doc: 'socket' transport extra info is not mandatory Message-ID: <1447322128.43.0.475707567423.issue25606@psf.upfronthosting.co.za> New submission from STINNER Victor: Not all implementations of asyncio event loops can provide the "socket" transport extra info. See for example this discussion on libuv: https://github.com/python/asyncio/issues/286 The information should be marked as "optional", or at least we should document that it can miss depending on the event loop. I guess that other info should be marked as optional. ---------- components: asyncio messages: 254527 nosy: gvanrossum, haypo, yselivanov priority: normal severity: normal status: open title: asyncio doc: 'socket' transport extra info is not mandatory versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 05:01:09 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 12 Nov 2015 10:01:09 +0000 Subject: [issue22995] Restrict default pickleability In-Reply-To: <1417699003.47.0.104663960497.issue22995@psf.upfronthosting.co.za> Message-ID: <20151112100105.33558.25000@psf.io> Roundup Robot added the comment: New changeset 2b950eba9792 by Serhiy Storchaka in branch '2.7': Issue #22995: Default implementation of __reduce__ and __reduce_ex__ now https://hg.python.org/cpython/rev/2b950eba9792 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 05:05:47 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 12 Nov 2015 10:05:47 +0000 Subject: [issue14350] Strange Exception from copying an iterator In-Reply-To: <1332011066.2.0.397754612752.issue14350@psf.upfronthosting.co.za> Message-ID: <1447322747.89.0.485577649264.issue14350@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: -Restrict default pickleability resolution: -> duplicate stage: needs patch -> resolved status: open -> closed superseder: -> Restrict default pickleability _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 07:34:45 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 12 Nov 2015 12:34:45 +0000 Subject: [issue25607] test_distutils provokes unexpected output in test_shutil Message-ID: <1447331685.01.0.00514668944728.issue25607@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: test_distutils changes global logging level for distutils. This affects test_shutil. In Python 2.7: $ ./python -m test.regrtest test_distutils test_shutil [1/2] test_distutils [2/2] test_shutil test test_shutil produced unexpected output: ********************************************************************** zip -q -r archive2.zip dist ********************************************************************** 1 test OK. 1 test failed: test_shutil Python 3 testing is more lenient, but produces unexpected output too. The global logging level is changed in Distribution.parse_command_line() by calling log.set_verbosity(). Proposed patch restores the value of the global logging level in tests that change it. ---------- components: Distutils, Tests files: test_distutils_restore_log_level.patch keywords: patch messages: 254529 nosy: dstufft, eric.araujo, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: test_distutils provokes unexpected output in test_shutil type: behavior versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file41021/test_distutils_restore_log_level.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 08:07:02 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 12 Nov 2015 13:07:02 +0000 Subject: [issue25607] test_distutils provokes unexpected output in test_shutil In-Reply-To: <1447331685.01.0.00514668944728.issue25607@psf.upfronthosting.co.za> Message-ID: <1447333622.59.0.208201255111.issue25607@psf.upfronthosting.co.za> STINNER Victor added the comment: Instead of a context manager, why not adding a addCleanup() in setUp() method of test cases? You might also add a "resource" test in regrtest, but this one might be overkill, since tests using distutils are known (test_distutils), no? Lib/distutils/tests/support.py: + threshold = log.set_threshold(log.WARN) + log.set_threshold(threshold) + yield threshold I would prefer to have a log.get_threshold() function (or log._get_threshold() if you don't want to modify the public API), or even read log._global_log.threshold. test_shutil.py: - with support.change_cwd(root_dir), captured_stdout(): + with support.change_cwd(root_dir): Why do you remove captured_stdout() here? ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 08:34:16 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 12 Nov 2015 13:34:16 +0000 Subject: [issue25604] [Minor] bug in integer true division algorithm In-Reply-To: <1447317885.13.0.151238733995.issue25604@psf.upfronthosting.co.za> Message-ID: <1447335256.23.0.281037325743.issue25604@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Correct. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 10:00:32 2015 From: report at bugs.python.org (Christoph Reiter) Date: Thu, 12 Nov 2015 15:00:32 +0000 Subject: [issue25493] warnings.warn: wrong stacklevel causes import of local file "sys" In-Reply-To: <1445964361.88.0.406365225673.issue25493@psf.upfronthosting.co.za> Message-ID: <1447340432.32.0.277054597076.issue25493@psf.upfronthosting.co.za> Christoph Reiter added the comment: To add some info why we hit that bug: https://bugs.python.org/issue24305 changed the warning stacklevel needed for import warnings from 8 to 2. As a result any code doing import warnings will likely hit that edge case when run with 3.5 and openafs installed. But I'm not sure if there is much code out there doing import warnings.. so ymmv. For anyone with the same problem looking for a workaround: I went through all Python versions and searched for the needed stacklevel. def get_import_stacklevel(import_hook): """Returns the stacklevel value for warnings.warn() for when the warning gets emitted by an imported module, but the warning should point at the code doing the import. Pass import_hook=True if the warning gets generated by an import hook (warn() gets called in load_module(), see PEP302) """ py_version = sys.version_info[:2] if py_version <= (3, 2): # 2.7 included return 4 if import_hook else 2 elif py_version == (3, 3): return 8 if import_hook else 10 elif py_version == (3, 4): return 10 if import_hook else 8 else: # fixed again in 3.5+, see https://bugs.python.org/issue24305 return 4 if import_hook else 2 ---------- nosy: +lazka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 10:25:18 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 12 Nov 2015 15:25:18 +0000 Subject: [issue25607] test_distutils provokes unexpected output in test_shutil In-Reply-To: <1447331685.01.0.00514668944728.issue25607@psf.upfronthosting.co.za> Message-ID: <1447341918.33.0.881588742376.issue25607@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch that just uses addCleanup() as Victor suggested. > Why do you remove captured_stdout() here? It is no longer needed. ---------- Added file: http://bugs.python.org/file41022/test_distutils_restore_log_level_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 10:26:48 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 12 Nov 2015 15:26:48 +0000 Subject: [issue25607] test_distutils provokes unexpected output in test_shutil In-Reply-To: <1447331685.01.0.00514668944728.issue25607@psf.upfronthosting.co.za> Message-ID: <1447342008.47.0.349558504279.issue25607@psf.upfronthosting.co.za> STINNER Victor added the comment: test_distutils_restore_log_level_2.patch looks good to me, it's simpler than the first version. I hope that it will fix the sporadic failures, thanks for working on fixing Python 2.7 buildbots! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 11:46:25 2015 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 12 Nov 2015 16:46:25 +0000 Subject: [issue25593] _sock_connect_cb can be called twice resulting in InvalidStateError In-Reply-To: <1447307664.22.0.793191556512.issue25593@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: I thought some more about this. The problem is due to stopping and restarting the loop, and that's also something that occurs in Alexander's example code, so I retract my accusation of aiohttp (and I don't think I need more investigation of his code). I recall that I thought a LOT about whether to run callbacks and then poll the selector or the other way around. The issue is that in the "steady state" it doesn't matter because the two would alternate either way; but in edge cases it does matter, as we've seen here. I worry about a scenario where a callback does something like this: def evil(): loop.call_soon(evil) loop.stop() Then the following code would never poll the selector with your fix (let's assume there are active FDs): evil() while True: loop.run_forever() Using the existing strategy it would still poll the selector. Also, several tests fail with your patch -- I have to investigate those. All in all I think replacing fut.cancelled() with fut.done() may be the way to go. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 12:25:23 2015 From: report at bugs.python.org (Justin Mayfield) Date: Thu, 12 Nov 2015 17:25:23 +0000 Subject: [issue25593] _sock_connect_cb can be called twice resulting in InvalidStateError In-Reply-To: <1447139794.12.0.288748898255.issue25593@psf.upfronthosting.co.za> Message-ID: <1447349123.76.0.244860398117.issue25593@psf.upfronthosting.co.za> Justin Mayfield added the comment: Interesting. I was going to do an analysis what using _ready.appendleft() for adding selector events would do for that scenario. The idea being to consistently juxtapose exiting callbacks, selector events and new callbacks. However I think this just moves the pawn in this ioloop halting problem. Is it worth investigating a change to the stop mechanism instead? Instead of raising an exception in the middle of run_once, it could set a flag to be seen by run_forever(). This may avoid this class of problem altogether and ensure run_once is a fairly simple and predictable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 12:38:19 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 12 Nov 2015 17:38:19 +0000 Subject: [issue14061] Misc fixes and cleanups in archiving code in shutil and test_shutil In-Reply-To: <1329705067.15.0.02936958618.issue14061@psf.upfronthosting.co.za> Message-ID: <1447349899.9.0.894413234611.issue14061@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Most of issues are already fixed. Proposed patch fixes remnants: * You see a skip message when bz2 or lzma are not available, instead of silent non-testing. * Removed a code that handles zipfile import failure. Importing zipfile now is always successful. * The gztar and zip formats now are registered and supported only when zlib is available. This is documented now. * Broken circular dependency between shutil and tarfile. * Removed outdated sentences about the InfoZIP "zip" utility. ---------- keywords: +patch stage: -> patch review versions: +Python 3.6 Added file: http://bugs.python.org/file41023/shutil_make_archive_misc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 12:42:02 2015 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 12 Nov 2015 17:42:02 +0000 Subject: [issue25593] _sock_connect_cb can be called twice resulting in InvalidStateError In-Reply-To: <1447349123.76.0.244860398117.issue25593@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Yeah, I've thought about changing the stop() mechanism too. It might mean that some callbacks will be executed that are currently skipped though, if your proposal is to run all callbacks in self._ready (excluding new ones) and then just exit if the stop flag is set. I worry about how this would violate expectations. We should be able to get away with this, because PEP 3156 is carefully vague about exactly how soon the loop will stop: it promises that callbacks scheduled *before* stop() was called will run before the loop exist -- but it makes no promises either way about callbacks schedule after stop() is called. A less intrusive change to stop() would be to somehow mark the point in self._ready where stop is called, so stopping at the same point as with the old algorithm, except for one difference: if you call stop() multiple times, it currently leaves extra "markers" in self._ready, which must be consumed by calling run_forever() multiple times. This proposal would change the semantics of that case. Again, I don't think PEP 3156 prevents us from doing that. But I still think those callbacks should be fixed (Alexander's original fix, extended to a few other callbacks that use fut.cancelled()). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 12:48:31 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 12 Nov 2015 17:48:31 +0000 Subject: [issue25607] test_distutils provokes unexpected output in test_shutil In-Reply-To: <1447331685.01.0.00514668944728.issue25607@psf.upfronthosting.co.za> Message-ID: <20151112174827.58397.7118@psf.io> Roundup Robot added the comment: New changeset 4461613ffe78 by Serhiy Storchaka in branch '3.4': Issue #25607: Restore old distutils logging threshold after running tests that https://hg.python.org/cpython/rev/4461613ffe78 New changeset d7741afd8347 by Serhiy Storchaka in branch '2.7': Issue #25607: Restore old distutils logging threshold after running tests that https://hg.python.org/cpython/rev/d7741afd8347 New changeset 7411830c7b24 by Serhiy Storchaka in branch '3.5': Issue #25607: Restore old distutils logging threshold after running tests that https://hg.python.org/cpython/rev/7411830c7b24 New changeset 9f6e43a6b3e0 by Serhiy Storchaka in branch 'default': Issue #25607: Restore old distutils logging threshold after running tests that https://hg.python.org/cpython/rev/9f6e43a6b3e0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 12:57:19 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 12 Nov 2015 17:57:19 +0000 Subject: [issue25607] test_distutils provokes unexpected output in test_shutil In-Reply-To: <1447331685.01.0.00514668944728.issue25607@psf.upfronthosting.co.za> Message-ID: <1447351039.92.0.715921157913.issue25607@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Victor for your review. It's my fault, I missed this failure when added test_zipfile_vs_zip in issue24982. Perhaps because ran only singular test test_shutil on 2.7, and on 3.x an unexpected output doesn't break tests. In any case it is more right to fix the original cause in test_distutils that just silence an unexpected output. ---------- assignee: -> serhiy.storchaka resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 13:04:04 2015 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 12 Nov 2015 18:04:04 +0000 Subject: [issue25606] asyncio doc: 'socket' transport extra info is not mandatory In-Reply-To: <1447322128.43.0.475707567423.issue25606@psf.upfronthosting.co.za> Message-ID: <1447351444.03.0.109593560711.issue25606@psf.upfronthosting.co.za> Guido van Rossum added the comment: The word 'optional' is literally the second word of the description of get_extra_info(). WHat more do you want? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 13:04:06 2015 From: report at bugs.python.org (SilentGhost) Date: Thu, 12 Nov 2015 18:04:06 +0000 Subject: [issue25580] async and await missing from token list In-Reply-To: <1446912139.74.0.381744244104.issue25580@psf.upfronthosting.co.za> Message-ID: <1447351446.48.0.471344618251.issue25580@psf.upfronthosting.co.za> SilentGhost added the comment: I've added versionchanged, since this is what's done in os, for similar lists. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 13:15:48 2015 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 12 Nov 2015 18:15:48 +0000 Subject: [issue25599] asyncio.iscoroutinefunction returns unexpected results when presented with unittest.mock.Mock In-Reply-To: <1447260639.53.0.0574192699335.issue25599@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: OK, I concede your point. It shouldn't be too hard to make asyncio.iscoroutinefunction() behave the same way as inspect.iscoroutinefunction(). Can you submit a patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 13:33:17 2015 From: report at bugs.python.org (Justin Mayfield) Date: Thu, 12 Nov 2015 18:33:17 +0000 Subject: [issue25593] _sock_connect_cb can be called twice resulting in InvalidStateError In-Reply-To: <1447139794.12.0.288748898255.issue25593@psf.upfronthosting.co.za> Message-ID: <1447353197.49.0.264959991969.issue25593@psf.upfronthosting.co.za> Justin Mayfield added the comment: Yes, that's what I was suggesting. Looking at tornado they do the stop between callbacks/matured-scheduled and events. That approach seems somewhat arbitrary to me at first glance but tornado is very mature and they usually have good reasons for what they do. The notion of always completing a cycle seems more apt to me; Ie. your first design. A compelling thought experiment for allowing stop() to be lazy is if a user could somehow know when stop() was going to run or when it had been run. The nature of ioloop programming prevents you from knowing when it will run and because stop() has no return handle/future/task a user can't actually know when it did run. Ie. there is no way to await/add_done_callback on it, so baring hacks that bookend a stop() with marker callbacks it should be, as you said, sufficiently vague to justify a (more) lazy effect. -- I more or less agree on the s/cancelled/done/ changes. I'm using a similar monkey patch in my libraries to dance around this issue right now. I still don't exactly like the idea that code is written with an explicit expectation that it could be pending or cancelled, but then must also be inherently prepared for spurious done callbacks. This seems like a borderline contract violation by add_writer() and co. I suppose that add_writer() is primarily targeted at streams and the case of an EINTR in a socket connect() is a more a one-shot. Tough call. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 14:11:15 2015 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Thu, 12 Nov 2015 19:11:15 +0000 Subject: [issue25608] ascynio readexactly() should raise ValueError if passed length <= 0 in argument Message-ID: <1447355475.79.0.931064144901.issue25608@psf.upfronthosting.co.za> New submission from ???? ?????????: ascynio readexactly() should raise ValueError if passed length <= 0 in argument. Now, it return empty string, which is just error hiding. Why not to raise ValueError ? Returning empty string is error prone. This behaviour was not changed since initial commit of asyncio, so probably was not done intentionally. ---------- components: asyncio messages: 254545 nosy: gvanrossum, haypo, mmarkk, yselivanov priority: normal severity: normal status: open title: ascynio readexactly() should raise ValueError if passed length <= 0 in argument type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 14:14:39 2015 From: report at bugs.python.org (Brett Cannon) Date: Thu, 12 Nov 2015 19:14:39 +0000 Subject: [issue25609] Add a ContextManager ABC and type Message-ID: <1447355679.68.0.225089426373.issue25609@psf.upfronthosting.co.za> New submission from Brett Cannon: There should probably be a context manager ABC in collections.abc that requires __enter__/__exit__ and a matching entry in `typing` that also takes a type argument of what the __enter__ method returns. ---------- components: Library (Lib) keywords: easy messages: 254546 nosy: brett.cannon, gvanrossum priority: normal severity: normal stage: needs patch status: open title: Add a ContextManager ABC and type versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 14:16:08 2015 From: report at bugs.python.org (Brett Cannon) Date: Thu, 12 Nov 2015 19:16:08 +0000 Subject: [issue25610] Add typing.Awaitable Message-ID: <1447355768.55.0.0781055266737.issue25610@psf.upfronthosting.co.za> New submission from Brett Cannon: Probably should have a subclass of Callable in `typing` for Awaitable functions (there is already a corollary object in collections.abc). ---------- components: asyncio messages: 254547 nosy: brett.cannon, giampaolo.rodola, gvanrossum, haypo, pitrou, yselivanov priority: normal severity: normal stage: needs patch status: open title: Add typing.Awaitable versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 14:37:35 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 12 Nov 2015 19:37:35 +0000 Subject: [issue25611] test_deque failure on Gentu and OpenIndiana buildbots on 2.7 Message-ID: <1447357055.57.0.0198756025718.issue25611@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: http://buildbot.python.org/all/builders/x86%20OpenIndiana%202.7/builds/3104/steps/test/logs/stdio http://buildbot.python.org/all/builders/x86%20Gentoo%20Non-Debug%20with%20X%202.7/builds/107/steps/test/logs/stdio ====================================================================== FAIL: test_basics (test.test_deque.TestBasic) ---------------------------------------------------------------------- Traceback (most recent call last): File "/buildbot/buildarea/2.7.ware-gentoo-x86/build/Lib/test/test_deque.py", line 38, in test_basics self.assertEqual(list(d), range(-200, 400)) AssertionError: Lists differ: [-200, -199, -198, -197, -196,... != [-200, -199, -198, -197, -196,... First differing element 200: -5125 0 First list contains 125 additional elements. First extra element 600: 275 Diff is 6032 characters long. Set self.maxDiff to None to see it. ---------------------------------------------------------------------- On other buildbots the test is passed, and I can't reproduce the failure locally. ---------- components: Extension Modules messages: 254548 nosy: rhettinger, serhiy.storchaka priority: normal severity: normal status: open title: test_deque failure on Gentu and OpenIndiana buildbots on 2.7 type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 14:39:40 2015 From: report at bugs.python.org (Zachary Ware) Date: Thu, 12 Nov 2015 19:39:40 +0000 Subject: [issue25611] test_deque failure on Gentoo and OpenIndiana buildbots on 2.7 In-Reply-To: <1447357055.57.0.0198756025718.issue25611@psf.upfronthosting.co.za> Message-ID: <1447357180.24.0.276959069258.issue25611@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- nosy: +zach.ware title: test_deque failure on Gentu and OpenIndiana buildbots on 2.7 -> test_deque failure on Gentoo and OpenIndiana buildbots on 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 14:40:24 2015 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 12 Nov 2015 19:40:24 +0000 Subject: [issue25608] ascynio readexactly() should raise ValueError if passed length <= 0 in argument In-Reply-To: <1447355475.79.0.931064144901.issue25608@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: I'm okay with raising ValueError for length<0; but for length==0 the behavior is very much intentional -- reading zero bytes is sometimes a useful end case that otherwise you would have to work around in the caller. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 15:09:35 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 12 Nov 2015 20:09:35 +0000 Subject: [issue8426] multiprocessing.Queue fails to get() very large objects In-Reply-To: <1271443086.56.0.51527518355.issue8426@psf.upfronthosting.co.za> Message-ID: <1447358975.04.0.626866848578.issue8426@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I agree with Charles-Fran?ois and think this issue should be closed. There is no a bug, and the behavior is documented. ---------- nosy: +serhiy.storchaka status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 15:10:02 2015 From: report at bugs.python.org (Alexander Mohr) Date: Thu, 12 Nov 2015 20:10:02 +0000 Subject: [issue25593] _sock_connect_cb can be called twice resulting in InvalidStateError In-Reply-To: <1447139794.12.0.288748898255.issue25593@psf.upfronthosting.co.za> Message-ID: <1447359002.05.0.543154701636.issue25593@psf.upfronthosting.co.za> Alexander Mohr added the comment: btw want to thank you guys for actively looking into this, I'm very grateful! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 15:12:18 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 12 Nov 2015 20:12:18 +0000 Subject: [issue16394] Reducing tee() memory footprint In-Reply-To: <1351955719.4.0.453680036148.issue16394@psf.upfronthosting.co.za> Message-ID: <1447359138.26.0.169648037634.issue16394@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Raymond, do you want to add a clarification to the documentation, or prefer just to close this issue? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 15:25:32 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 12 Nov 2015 20:25:32 +0000 Subject: [issue25313] IDLE: gracefully handle themes (or keysets, or ...) not present In-Reply-To: <1443983028.38.0.330062493222.issue25313@psf.upfronthosting.co.za> Message-ID: <20151112202529.33538.87499@psf.io> Roundup Robot added the comment: New changeset b95c10cb457d by Terry Jan Reedy in branch '2.7': Issue #25313: Change the handling of new built-in text color themes to better https://hg.python.org/cpython/rev/b95c10cb457d New changeset 6185c5603eed by Terry Jan Reedy in branch '3.4': Issue #25313: Change the handling of new built-in text color themes to better https://hg.python.org/cpython/rev/6185c5603eed ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 15:27:08 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 12 Nov 2015 20:27:08 +0000 Subject: [issue25606] asyncio doc: 'socket' transport extra info is not mandatory In-Reply-To: <1447351444.03.0.109593560711.issue25606@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Guido van Rossum added the comment: > The word 'optional' is literally the second word of the description of get_extra_info(). WHat more do you want? Hum, it can be surprising for users that an application works on "asyncio" but doesn't work on "libuv asyncio". We should explicitly explain that the availability of some information depend on the event loop. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 15:37:08 2015 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 12 Nov 2015 20:37:08 +0000 Subject: [issue25606] asyncio doc: 'socket' transport extra info is not mandatory In-Reply-To: Message-ID: Guido van Rossum added the comment: Well I don't know how adding a note to the doc is going to change that much (those users probably don't read the docs but copy some example), but go ahead and add something. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 15:38:32 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 12 Nov 2015 20:38:32 +0000 Subject: [issue25313] IDLE: gracefully handle themes (or keysets, or ...) not present In-Reply-To: <1443983028.38.0.330062493222.issue25313@psf.upfronthosting.co.za> Message-ID: <1447360712.06.0.221032088825.issue25313@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The patch applied leaves 'name = IDLE New' alone so older IDLEs can use that instead of IDLE Classic as an alternative to IDLE Dark. I will open an issue to revise IDLE New slightly. I also added type='bool' when getting 'default' (the lack thereof lead to IDLE Dark being returned as a custom theme. After working with this, I like the idea of present users with a single list of themes to select, instead of two buttons and two drop-down lists. I tested fairly thoroughly, starting with no user [Theme] section. When I added a print to debug idleConf.CurrentTheme, it was called 13 times on startup, with only Shell opened. ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 15:59:19 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 12 Nov 2015 20:59:19 +0000 Subject: [issue25612] nested try..excepts don't work correctly for generators Message-ID: <1447361959.0.0.839122121456.issue25612@psf.upfronthosting.co.za> New submission from Yury Selivanov: Nested try..except statements with yields can loose reference to the current exception. The following code: class MainError(Exception): pass class SubError(Exception): pass def main(): try: raise MainError() except MainError: try: yield except SubError: print('got SubError') raise coro = main() coro.send(None) coro.throw(SubError()) prints: got SubError Traceback (most recent call last): File "t.py", line 19, in coro.throw(SubError()) File "t.py", line 15, in main raise RuntimeError: No active exception to reraise ---------- components: Interpreter Core messages: 254557 nosy: benjamin.peterson, gvanrossum, haypo, larry, ncoghlan, yselivanov priority: release blocker severity: normal status: open title: nested try..excepts don't work correctly for generators versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 16:00:58 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 12 Nov 2015 21:00:58 +0000 Subject: [issue25612] nested try..excepts don't work correctly for generators In-Reply-To: <1447361959.0.0.839122121456.issue25612@psf.upfronthosting.co.za> Message-ID: <1447362058.21.0.550422543989.issue25612@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 16:13:53 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 12 Nov 2015 21:13:53 +0000 Subject: [issue25612] nested try..excepts don't work correctly for generators In-Reply-To: <1447361959.0.0.839122121456.issue25612@psf.upfronthosting.co.za> Message-ID: <1447362833.08.0.280698725364.issue25612@psf.upfronthosting.co.za> Yury Selivanov added the comment: This was originally discovered here: https://github.com/python/asyncio/issues/287 ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 16:24:39 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 12 Nov 2015 21:24:39 +0000 Subject: [issue25612] nested try..excepts don't work correctly for generators In-Reply-To: <1447361959.0.0.839122121456.issue25612@psf.upfronthosting.co.za> Message-ID: <1447363479.64.0.0653094731208.issue25612@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 16:34:49 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 12 Nov 2015 21:34:49 +0000 Subject: [issue25580] async and await missing from token list In-Reply-To: <1446912139.74.0.381744244104.issue25580@psf.upfronthosting.co.za> Message-ID: <1447364089.31.0.548037460931.issue25580@psf.upfronthosting.co.za> Martin Panter added the comment: Do you have a new version of the patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 16:46:03 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 12 Nov 2015 21:46:03 +0000 Subject: [issue24421] Race condition compiling Modules/_math.c In-Reply-To: <1433923600.68.0.73894537311.issue24421@psf.upfronthosting.co.za> Message-ID: <1447364763.19.0.837009074482.issue24421@psf.upfronthosting.co.za> Martin Panter added the comment: Ideally, I think the solution would be to compile _math.c once, as a dependency shared between both extension modules (perhaps like a static library if necessary). Does anyone know if the build system supports this, or how to do it? Another semi-favourable solution might be to compile _math.c twice, but send the output to separate directories, e.g. . . ./math-build/_math.o and . . ./cmath-build/_math.o. Again, I don?t know if this is practical. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 17:14:06 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 12 Nov 2015 22:14:06 +0000 Subject: [issue25612] nested try..excepts don't work correctly for generators In-Reply-To: <1447363479.68.0.243895412653.issue25612@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Is this issue related to the issue #23353? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 17:15:52 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 12 Nov 2015 22:15:52 +0000 Subject: [issue22995] Restrict default pickleability In-Reply-To: <1417699003.47.0.104663960497.issue22995@psf.upfronthosting.co.za> Message-ID: <1447366552.6.0.968989572103.issue22995@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Was committed the restriction for tp_new == NULL. New patch uses more complex condition for types that doesn't define any reduce-related methods. This case covers _csv.Dialect and memoryview (and buffer in 2.7, issue8323). ---------- Added file: http://bugs.python.org/file41024/pickle_restrictions_4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 17:18:35 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 12 Nov 2015 22:18:35 +0000 Subject: [issue8323] buffer objects are picklable but result is not unpicklable In-Reply-To: <1270507518.5.0.340159262485.issue8323@psf.upfronthosting.co.za> Message-ID: <1447366715.71.0.799865702761.issue8323@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: While buffer is only used in Python 2.x, there is a similar issue in 3.x with memoryview. The patch for issue22995 fixes this issue. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 17:18:57 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 12 Nov 2015 22:18:57 +0000 Subject: [issue25612] nested try..excepts don't work correctly for generators In-Reply-To: <1447361959.0.0.839122121456.issue25612@psf.upfronthosting.co.za> Message-ID: <1447366737.56.0.451293941239.issue25612@psf.upfronthosting.co.za> STINNER Victor added the comment: I reverted the change of the issue #23353 but it doesn't fix this example, so it looks like these issues are not related. Cool. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 17:19:50 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 12 Nov 2015 22:19:50 +0000 Subject: [issue25612] nested try..excepts don't work correctly for generators In-Reply-To: <1447361959.0.0.839122121456.issue25612@psf.upfronthosting.co.za> Message-ID: <1447366790.45.0.168691129558.issue25612@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 17:22:40 2015 From: report at bugs.python.org (Dave Jones) Date: Thu, 12 Nov 2015 22:22:40 +0000 Subject: [issue21748] glob.glob does not sort its results In-Reply-To: <1402666303.8.0.471997942959.issue21748@psf.upfronthosting.co.za> Message-ID: <1447366960.6.0.763843200417.issue21748@psf.upfronthosting.co.za> Dave Jones added the comment: >From the bash man-page: "... If one of these characters appears, then the word is regarded as a pattern, and replaced with an *alphabetically sorted* list of filenames matching the pattern". I would agree that glob.glob shouldn't sort its results (the overhead may be substantial, and there are plenty of use-cases that don't require sorting), but given that the documented behaviour is at odds (implicitly via the shell's documentation) with the implemented behaviour I would argue that it is premature to close this without at least adding a note to the Python docs. (P.S. in case my comment is received poorly, I'm not the original author of this ticket, and no aspersions should be cast upon drj for my possibly foolish views!) ---------- nosy: +Dave Jones _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 17:36:53 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 12 Nov 2015 22:36:53 +0000 Subject: [issue21748] glob.glob does not sort its results In-Reply-To: <1402666303.8.0.471997942959.issue21748@psf.upfronthosting.co.za> Message-ID: <1447367813.55.0.709565237816.issue21748@psf.upfronthosting.co.za> R. David Murray added the comment: Technically the docs are not wrong: "matches files according to the rules of the shell" does not say anything about sorting (matching is separate from what is done with the matched filenames; the shell sorts them and inserts them in place, python returns an unsorted list). It also mentions using listdir, which is documented as unsorted. That said, it would be reasonable to insert a disclaimer that the returned results are unsorted, unlike the shell. If you want to open an new issue with a proposed doc patch, that would be fine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 17:41:59 2015 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 12 Nov 2015 22:41:59 +0000 Subject: [issue21748] glob.glob does not sort its results In-Reply-To: <1402666303.8.0.471997942959.issue21748@psf.upfronthosting.co.za> Message-ID: <1447368119.74.0.457085706811.issue21748@psf.upfronthosting.co.za> Eric V. Smith added the comment: Assuming David means "it wouldn't be unreasonable to insert a disclaimer", I agree. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 17:43:19 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 12 Nov 2015 22:43:19 +0000 Subject: [issue14061] Misc fixes and cleanups in archiving code in shutil and test_shutil In-Reply-To: <1329705067.15.0.02936958618.issue14061@psf.upfronthosting.co.za> Message-ID: <1447368199.87.0.316887201105.issue14061@psf.upfronthosting.co.za> Martin Panter added the comment: Remember that you probably should not mention ?xztar? in the 3.4 or 2.7 docs (even though ?lzma? exists in 3.4). I am not too familiar with using shutil or zipfile, but it seems like extraction of some zip files is always possible, even if zlib (for Deflate) isn?t available (e.g. for zip files that are not compressed, or use bzip2 or LZMA). Maybe you should only make zip file _creation_ conditional. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 17:45:14 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 12 Nov 2015 22:45:14 +0000 Subject: [issue21748] glob.glob does not sort its results In-Reply-To: <1402666303.8.0.471997942959.issue21748@psf.upfronthosting.co.za> Message-ID: <1447368314.12.0.985071495426.issue21748@psf.upfronthosting.co.za> R. David Murray added the comment: You mean my old English teachers were wrong when they said a positive statement was to be preferred to a double negative? :) :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 17:53:32 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 12 Nov 2015 22:53:32 +0000 Subject: [issue25586] socket.sendall broken when a socket has a timeout In-Reply-To: <1447019255.89.0.976606710887.issue25586@psf.upfronthosting.co.za> Message-ID: <1447368812.43.0.704932406278.issue25586@psf.upfronthosting.co.za> Martin Panter added the comment: For what it?s worth, there could be obsure cases where sending more data might be okay. I prefer the original version (but can settle for either). Here?s a third alternative: Considering this loss of information, it is generally best not to send any more data to the socket. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 17:55:06 2015 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 12 Nov 2015 22:55:06 +0000 Subject: [issue21748] glob.glob does not sort its results In-Reply-To: <1402666303.8.0.471997942959.issue21748@psf.upfronthosting.co.za> Message-ID: <1447368906.3.0.439809410024.issue21748@psf.upfronthosting.co.za> Eric V. Smith added the comment: D'oh! I read your original comment as "it would be unreasonable to insert a disclaimer", and then I wondered why you'd used such a convoluted sentence and reversed your meaning. It's all my fault. Fortunately, I don't think Mrs. McKinley from 11th grade English will come after me after all these years. Sorry about that. We're in violent agreement. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 18:19:17 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 12 Nov 2015 23:19:17 +0000 Subject: [issue25605] fcntl doc: document exceptions raised on error for ioctl() and flock() In-Reply-To: <1447320542.54.0.969865888179.issue25605@psf.upfronthosting.co.za> Message-ID: <1447370357.97.0.421919860677.issue25605@psf.upfronthosting.co.za> Martin Panter added the comment: This looks good for Python 2 and the equivalent for Python 3. FWIW the ValueError case is platform-dependent. On Linux, I see EINVAL (the IOError version of ValueError): >>> flock(0, LOCK_UN) >>> flock(0, 0) Traceback (most recent call last): File "", line 1, in IOError: [Errno 22] Invalid argument ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 18:27:16 2015 From: report at bugs.python.org (Matthias Klose) Date: Thu, 12 Nov 2015 23:27:16 +0000 Subject: [issue25613] fix ssl tests with sslv3 disabled Message-ID: <1447370836.15.0.704598456658.issue25613@psf.upfronthosting.co.za> New submission from Matthias Klose: Linux distributions (now starting with the Ubuntu development version for 16.04 LTS) are starting to disable SSLv3, letting at least two test_ssl tests fail. a partial fix is mentioned in https://launchpad.net/bugs/1515793 ---------- messages: 254573 nosy: doko priority: normal severity: normal status: open title: fix ssl tests with sslv3 disabled versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 18:28:20 2015 From: report at bugs.python.org (Alex Gaynor) Date: Thu, 12 Nov 2015 23:28:20 +0000 Subject: [issue25613] fix ssl tests with sslv3 disabled In-Reply-To: <1447370836.15.0.704598456658.issue25613@psf.upfronthosting.co.za> Message-ID: <1447370900.74.0.443630668784.issue25613@psf.upfronthosting.co.za> Alex Gaynor added the comment: Does this issue still occur on default? https://hg.python.org/cpython/rev/d80954d941c7 ---------- nosy: +alex _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 18:41:20 2015 From: report at bugs.python.org (Yclept Nemo) Date: Thu, 12 Nov 2015 23:41:20 +0000 Subject: [issue25614] Lib/code.py: InteractiveConsole.raw_input writes prompt to stdout Message-ID: <1447371680.73.0.599273963393.issue25614@psf.upfronthosting.co.za> New submission from Yclept Nemo: Just like InteractiveInterpreter.write and the actual python interpreter, the console's prompt should be written to stderr. Something like: self.write(prompt) return input() ---------- components: Library (Lib) messages: 254575 nosy: Yclept.Nemo priority: normal severity: normal status: open title: Lib/code.py: InteractiveConsole.raw_input writes prompt to stdout versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 18:42:43 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 12 Nov 2015 23:42:43 +0000 Subject: [issue25612] nested try..excepts don't work correctly for generators In-Reply-To: <1447361959.0.0.839122121456.issue25612@psf.upfronthosting.co.za> Message-ID: <1447371763.42.0.620845494651.issue25612@psf.upfronthosting.co.za> Yury Selivanov added the comment: Another bug: class MainError(Exception): pass class SubError(Exception): pass def main(): try: raise MainError() except MainError: yield coro = main() coro.send(None) coro.throw(SubError()) SubError will propagate, but won't have MainError in its __context__ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 19:07:17 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 13 Nov 2015 00:07:17 +0000 Subject: [issue25498] Python 3.4.3 core dump with simple sample code In-Reply-To: <1446055572.58.0.349657416945.issue25498@psf.upfronthosting.co.za> Message-ID: <1447373237.85.0.729897727545.issue25498@psf.upfronthosting.co.za> Martin Panter added the comment: New patch with Fortran array test, and read-only and reversed memoryview() tests. ---------- Added file: http://bugs.python.org/file41025/ctypes_from_buffer_4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 19:16:43 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 13 Nov 2015 00:16:43 +0000 Subject: [issue25612] nested try..excepts don't work correctly for generators In-Reply-To: <1447361959.0.0.839122121456.issue25612@psf.upfronthosting.co.za> Message-ID: <1447373803.95.0.553564064787.issue25612@psf.upfronthosting.co.za> Yury Selivanov added the comment: Here's a patch the fixes the first problem (but __context__ bug is still open). I'm not sure that the patch is correct :( But at least I've added new unittests (one still failing) ---------- keywords: +patch Added file: http://bugs.python.org/file41026/gen_exc_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 20:00:18 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 13 Nov 2015 01:00:18 +0000 Subject: [issue25579] def is not a keyword with tokenize.py In-Reply-To: <1446910597.11.0.443064601672.issue25579@psf.upfronthosting.co.za> Message-ID: <1447376418.69.0.88796534089.issue25579@psf.upfronthosting.co.za> Yury Selivanov added the comment: St?phane, sorry for not replying earlier, emails from bugs.python.org sometimes go to spam. [TokenInfo(type=55 (ASYNC), string='async', start=(1, 0), end=(1, 5), line='async def foo(): pass'), TokenInfo(type=1 (NAME), string='def', start=(1, 6), end=(1, 9), line='async def foo(): pass'), ^-- this is indeed correct. Right now async/await are treated specially in tokenizer.c & parser, and tokenize.py simply mimics their behaviour. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 20:03:04 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 13 Nov 2015 01:03:04 +0000 Subject: [issue25580] async and await missing from token list In-Reply-To: <1446912139.74.0.381744244104.issue25580@psf.upfronthosting.co.za> Message-ID: <1447376584.86.0.322326008835.issue25580@psf.upfronthosting.co.za> Yury Selivanov added the comment: ASYNC/AWAIT tokens are temporary and will be removed in 3.7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 21:07:39 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 13 Nov 2015 02:07:39 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <1447380459.91.0.597877599824.issue23883@psf.upfronthosting.co.za> Martin Panter added the comment: The reason why I prefer the current API over my support.expected_module_api() idea is it requires the extra assertCountEqual() boilerplate at each call site. Jacek?s three patches look ready to me. I propose: 1. Commit Issue23883_support_check__all__.v6.patch to 3.6, which everything else depends on. 2. Commit Issue23883_test_gettext.v3.patch to 3.6. (Andrew Kuchling?s original gettext.__all__ fix was made in 3.4 and 2.7 as well, but we would have to backport the support function, or rewrite the test, to apply this to earlier branches.) 3. Commit Issue23883_all.v6.patch to 3.6 only to limit the chance of breaking existing code. 4. Rewrite Mauro SM Rodrigues?s issue23883_fileinput.patch to use support.check__all__(). 5. Update Joel Taddei?s Issue23883_tarfile_all.patch and Issue23883_calendar_all.patch for support.check__all__() and addressing review comments. 6. Work on the remaining modules, probably in a separate issue to keep things under control. According to my calculations these modules are: cgi, configparser, doctest, http.cookies, mailbox, mimetypes, plistlib, pydoc, smtpd, tkinter.ttk, tokenize, xml.etree.ElementTree. Another question that comes to mind: Should we add anything into What?s New, maybe warning of new symbols from ?import *?? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 21:44:24 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 13 Nov 2015 02:44:24 +0000 Subject: [issue25017] htmllib deprecated: Which library to use? Missing sane default in docs In-Reply-To: <1441616497.34.0.0999815194375.issue25017@psf.upfronthosting.co.za> Message-ID: <1447382664.02.0.657738027198.issue25017@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a cleaned-up version of Nan?s first patch. ---------- Added file: http://bugs.python.org/file41027/htmllib_deprecation_warning_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 22:02:16 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 13 Nov 2015 03:02:16 +0000 Subject: [issue25590] tab-completition on instances repeatedly accesses attribute/descriptors values In-Reply-To: <1447107343.63.0.0427300203207.issue25590@psf.upfronthosting.co.za> Message-ID: <1447383736.59.0.992036039415.issue25590@psf.upfronthosting.co.za> Martin Panter added the comment: Yeah I plan to merge the first patch (fixing conflicts) into 3.6 without any of the uncreated-property additions, and then apply that extra stuff in a separate commit. Using __slots__ would be simpler; I?ll switch it over. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 22:07:38 2015 From: report at bugs.python.org (Neil Schemenauer) Date: Fri, 13 Nov 2015 03:07:38 +0000 Subject: [issue7759] mhlib fails on Btrfs filesystem (test_mhlib failure) In-Reply-To: <1264198934.84.0.705718671648.issue7759@psf.upfronthosting.co.za> Message-ID: <1447384058.45.0.238366635007.issue7759@psf.upfronthosting.co.za> Neil Schemenauer added the comment: I don't see how that patch can be correct. The logic is now if the directory has two links inside it then skip it. The filesystems that don't count '.' and '..' will have zero links when empty and will have two links when two real files exist in them. I think my original patch is safer. ---------- assignee: -> serhiy.storchaka resolution: fixed -> stage: resolved -> commit review status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 22:10:04 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 13 Nov 2015 03:10:04 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <1447384204.58.0.531562228008.issue23883@psf.upfronthosting.co.za> Berker Peksag added the comment: > The reason why I prefer the current API over my support.expected_module_api() idea is it requires the extra assertCountEqual() boilerplate at each call site. I personally find explicit assert* calls in a test case more readable(e.g. I don't need to check what the helper does every N month), but I guess that's another version of tabs vs. space debate :) > Jacek?s three patches look ready to me. I propose: Your plan sounds good to me. Thanks! > Should we add anything into What?s New, maybe warning of new symbols from ?import *?? I guess it wouldn't hurt to add a sentence :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 22:11:07 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 13 Nov 2015 03:11:07 +0000 Subject: [issue25017] htmllib deprecated: Which library to use? Missing sane default in docs In-Reply-To: <1441616497.34.0.0999815194375.issue25017@psf.upfronthosting.co.za> Message-ID: <1447384267.61.0.103585885863.issue25017@psf.upfronthosting.co.za> Berker Peksag added the comment: htmllib_deprecation_warning_3.patch looks good to me. ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 23:28:40 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 13 Nov 2015 04:28:40 +0000 Subject: [issue19023] ctypes docs: Unimplemented and undocumented features In-Reply-To: <1379246270.23.0.998338553474.issue19023@psf.upfronthosting.co.za> Message-ID: <1447388920.45.0.884834019929.issue19023@psf.upfronthosting.co.za> Martin Panter added the comment: Sye van der Veen: can you sign a contributor agreement ? I think it might be needed for this patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 12 23:44:53 2015 From: report at bugs.python.org (Nan Wu) Date: Fri, 13 Nov 2015 04:44:53 +0000 Subject: [issue25609] Add a ContextManager ABC and type In-Reply-To: <1447355679.68.0.225089426373.issue25609@psf.upfronthosting.co.za> Message-ID: <1447389893.0.0.599795195051.issue25609@psf.upfronthosting.co.za> Nan Wu added the comment: Hi Brett, I'd like work on this feature. Your description here is clear. Besides that, could you give a use case of this context manager? ---------- nosy: +Nan Wu _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 02:10:18 2015 From: report at bugs.python.org (SilentGhost) Date: Fri, 13 Nov 2015 07:10:18 +0000 Subject: [issue25580] async and await missing from token list In-Reply-To: <1446912139.74.0.381744244104.issue25580@psf.upfronthosting.co.za> Message-ID: <1447398618.79.0.247980333815.issue25580@psf.upfronthosting.co.za> SilentGhost added the comment: Hm, not sure why the file didn't get uploaded, I clearly remember attaching it. Yury, what is the implication for this issue? Are you suggesting that the note should state that these two are temporary? Or is this information available somewhere else, in What's new, for example? ---------- Added file: http://bugs.python.org/file41028/issue25580.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 03:14:46 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 13 Nov 2015 08:14:46 +0000 Subject: [issue25605] fcntl doc: document exceptions raised on error for ioctl() and flock() In-Reply-To: <1447320542.54.0.969865888179.issue25605@psf.upfronthosting.co.za> Message-ID: <20151113081443.109191.95806@psf.io> Roundup Robot added the comment: New changeset d3d974e92e6f by Victor Stinner in branch '2.7': Issue #25605: Document exceptions raised by fcntl.ioctl() and fcntl.flock() https://hg.python.org/cpython/rev/d3d974e92e6f New changeset f82cd1ed659e by Victor Stinner in branch '3.4': Issue #25605: Document exceptions raised by fcntl.ioctl() and fcntl.flock() https://hg.python.org/cpython/rev/f82cd1ed659e New changeset cf69fe41f873 by Victor Stinner in branch '3.5': Merge 3.4 (issue #25605) https://hg.python.org/cpython/rev/cf69fe41f873 New changeset 0eddeb57c3d6 by Victor Stinner in branch 'default': Merge 3.5 (issue #25605) https://hg.python.org/cpython/rev/0eddeb57c3d6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 03:14:53 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 13 Nov 2015 08:14:53 +0000 Subject: [issue25605] fcntl doc: document exceptions raised on error for ioctl() and flock() In-Reply-To: <1447320542.54.0.969865888179.issue25605@psf.upfronthosting.co.za> Message-ID: <1447402493.61.0.544346344461.issue25605@psf.upfronthosting.co.za> STINNER Victor added the comment: Thanks for the review. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 04:30:46 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 13 Nov 2015 09:30:46 +0000 Subject: [issue21748] glob.glob does not sort its results In-Reply-To: <1402666303.8.0.471997942959.issue21748@psf.upfronthosting.co.za> Message-ID: <1447407046.89.0.372691027535.issue21748@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: There is nothing special with glob(). By default the ls command outputs sorted list of files, but os.listdir() doesn't. Python is just lower-level language than Posix shell. You always can call sort() on result. It is easy to just add sort() after calling os.listdir() in current glob() implementation. It shouldn't significantly affect performance. I would support this feature. But I'm planning to implement glob() with os.scandir(), and it is not so easy to support sorting in that implementation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 04:40:56 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 13 Nov 2015 09:40:56 +0000 Subject: [issue25498] Python 3.4.3 core dump with simple sample code In-Reply-To: <1446055572.58.0.349657416945.issue25498@psf.upfronthosting.co.za> Message-ID: <1447407656.33.0.767860697065.issue25498@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Great! The patch LGTM. I left only two minor suggestions on Rietveld. ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 04:49:56 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 13 Nov 2015 09:49:56 +0000 Subject: [issue14061] Misc fixes and cleanups in archiving code in shutil and test_shutil In-Reply-To: <1329705067.15.0.02936958618.issue14061@psf.upfronthosting.co.za> Message-ID: <1447408196.4.0.737711571489.issue14061@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yes, I were going to left this for other issue, but now I agree that it is better to left zip in unarhiving registry unconditionally. In 2.7 the support of bztar is not conditional. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 04:59:21 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 13 Nov 2015 09:59:21 +0000 Subject: [issue7759] mhlib fails on Btrfs filesystem (test_mhlib failure) In-Reply-To: <1264198934.84.0.705718671648.issue7759@psf.upfronthosting.co.za> Message-ID: <1447408761.94.0.826199819537.issue7759@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: AFAIK the filesystem either counts directory references, in this case st_nlink >= 2, and st_nlink == 2 only for empty directory. The exception is a root directory, but it is not relevant. Or it doesn't count directory references, in this case st_nlink == 1. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 04:59:40 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 13 Nov 2015 09:59:40 +0000 Subject: [issue25498] Python 3.4.3 regression in ctypes.frombuffer() In-Reply-To: <1446055572.58.0.349657416945.issue25498@psf.upfronthosting.co.za> Message-ID: <1447408779.99.0.764422330448.issue25498@psf.upfronthosting.co.za> STINNER Victor added the comment: The change 1da9630e9b7f was first published in Python 3.4.3. ---------- nosy: +haypo title: Python 3.4.3 core dump with simple sample code -> Python 3.4.3 regression in ctypes.frombuffer() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 05:26:21 2015 From: report at bugs.python.org (Dave Jones) Date: Fri, 13 Nov 2015 10:26:21 +0000 Subject: [issue25615] Document unsorted behaviour of glob.glob Message-ID: <1447410381.17.0.519847126493.issue25615@psf.upfronthosting.co.za> New submission from Dave Jones: As suggested in issue 21748, this is a minor documentation change to make explicitly clear that glob.glob returns unsorted results (on the basis that the existing specification references shell behaviour which is always sorted). ---------- assignee: docs at python components: Documentation files: glob-spec-unsorted.patch keywords: patch messages: 254597 nosy: Dave Jones, docs at python priority: normal severity: normal status: open title: Document unsorted behaviour of glob.glob type: behavior versions: Python 3.6 Added file: http://bugs.python.org/file41029/glob-spec-unsorted.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 05:27:50 2015 From: report at bugs.python.org (Dave Jones) Date: Fri, 13 Nov 2015 10:27:50 +0000 Subject: [issue21748] glob.glob does not sort its results In-Reply-To: <1402666303.8.0.471997942959.issue21748@psf.upfronthosting.co.za> Message-ID: <1447410470.24.0.69691088953.issue21748@psf.upfronthosting.co.za> Dave Jones added the comment: As suggested, doc patch attached to new issue 25615. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 06:19:56 2015 From: report at bugs.python.org (David Jones) Date: Fri, 13 Nov 2015 11:19:56 +0000 Subject: [issue21748] glob.glob does not sort its results In-Reply-To: <1402666303.8.0.471997942959.issue21748@psf.upfronthosting.co.za> Message-ID: <1447413596.65.0.238694471068.issue21748@psf.upfronthosting.co.za> David Jones added the comment: The original bug report did not mention ls (note serhiy.storchaka). It is a red herring. I accept that the Python community doesn't care to have glob.glob sorted. But then I think you should distance yourself from the shell in the documentation. It currently says: "The glob module finds all the pathnames matching a specified pattern according to the rules used by the Unix shell" You could say something like: "The glob module finds all the pathnames matching a specified pattern, using a syntax inspired by the Unix shell; unlike Unix shell the ordering is not guaranteed" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 06:53:32 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 13 Nov 2015 11:53:32 +0000 Subject: [issue25558] Use static asserts in C code In-Reply-To: <1446742000.61.0.314081889142.issue25558@psf.upfronthosting.co.za> Message-ID: <1447415612.03.0.34641604305.issue25558@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 06:57:05 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 13 Nov 2015 11:57:05 +0000 Subject: [issue6598] calling email.utils.make_msgid frequently has a non-trivial probability of generating colliding ids In-Reply-To: <1248913936.65.0.487457323949.issue6598@psf.upfronthosting.co.za> Message-ID: <1447415825.42.0.0558799687409.issue6598@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Perhaps will open a separate issue for more compact non-decimal message ID. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 07:00:12 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 13 Nov 2015 12:00:12 +0000 Subject: [issue25601] test_cpickle failure on the ware-gentoo-x86 buildbot In-Reply-To: <1447230695.36.0.35114709633.issue25601@psf.upfronthosting.co.za> Message-ID: <1447416012.0.0.852836682118.issue25601@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could you reproduce the failure by running tests with the same seed on these machines? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 08:01:21 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 13 Nov 2015 13:01:21 +0000 Subject: [issue25616] Extract OrderedDict tests into separate file Message-ID: <1447419681.57.0.354121086978.issue25616@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: OrderedDict tests now are about 1/3 of test_collections, and I think their volume will grow. I suggest to extract these tests into separate file test_ordereddict. There are precedences: test_deque (deque also is implemented in C), and test_userdict, test_userlist and test_userstring (for historical reasons). The main reason to me is the possibility to run quick OrderedDict tests (and only OrderedDict tests). ---------- components: Tests messages: 254602 nosy: eric.snow, rhettinger, serhiy.storchaka priority: normal severity: normal status: open title: Extract OrderedDict tests into separate file type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 08:19:12 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 13 Nov 2015 13:19:12 +0000 Subject: [issue25462] Avoid repeated hash calculation in C implementation of OrderedDict In-Reply-To: <1445537707.4.0.965290035462.issue25462@psf.upfronthosting.co.za> Message-ID: <20151113131909.18198.11419@psf.io> Roundup Robot added the comment: New changeset 52ff0c00a404 by Serhiy Storchaka in branch '3.5': Issue #25462: The hash of the key now is calculated only once in most https://hg.python.org/cpython/rev/52ff0c00a404 New changeset 828c9b920532 by Serhiy Storchaka in branch 'default': Issue #25462: The hash of the key now is calculated only once in most https://hg.python.org/cpython/rev/828c9b920532 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 08:20:35 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 13 Nov 2015 13:20:35 +0000 Subject: [issue25462] Avoid repeated hash calculation in C implementation of OrderedDict In-Reply-To: <1445537707.4.0.965290035462.issue25462@psf.upfronthosting.co.za> Message-ID: <1447420835.97.0.861314283963.issue25462@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Raymond and Eric. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 08:21:03 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 13 Nov 2015 13:21:03 +0000 Subject: [issue25462] Avoid repeated hash calculation in C implementation of OrderedDict In-Reply-To: <1445537707.4.0.965290035462.issue25462@psf.upfronthosting.co.za> Message-ID: <1447420863.76.0.823966195397.issue25462@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 08:21:16 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 13 Nov 2015 13:21:16 +0000 Subject: [issue25462] Avoid repeated hash calculation in C implementation of OrderedDict In-Reply-To: <1445537707.4.0.965290035462.issue25462@psf.upfronthosting.co.za> Message-ID: <1447420876.26.0.913078303607.issue25462@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: commit review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 09:34:41 2015 From: report at bugs.python.org (Sye van der Veen) Date: Fri, 13 Nov 2015 14:34:41 +0000 Subject: [issue19023] ctypes docs: Unimplemented and undocumented features In-Reply-To: <1447388920.45.0.884834019929.issue19023@psf.upfronthosting.co.za> Message-ID: Sye van der Veen added the comment: Signed and confirmed. :-) On Thu, Nov 12, 2015 at 11:28 PM Martin Panter wrote: > > Martin Panter added the comment: > > Sye van der Veen: can you sign a contributor agreement < > https://www.python.org/psf/contrib/contrib-form/>? I think it might be > needed for this patch. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 09:52:02 2015 From: report at bugs.python.org (Koustav Pal) Date: Fri, 13 Nov 2015 14:52:02 +0000 Subject: [issue25617] Installing local installation of Python Message-ID: <1447426322.89.0.546978633067.issue25617@psf.upfronthosting.co.za> New submission from Koustav Pal: The inherent behaviour of python installations (local or global) is such that it expects to source system wide modules from the global python installation. There is no non hacky way to solve this problem. The idea of local installations is that they should be independent of system-wide builds. Python's behaviour contradicts this condition. In cases where users on clusters need to maintain their own python installations such that these installations are independent of uncontrollable cluster variables, python will break on a regular basis as it tries to import modules from the system wide sources which were compiled on a similar python version but with different parameters. Why was this express decision made to include this path in the python development tree? How can this be resolved without hacking site.py? ---------- components: Installation messages: 254606 nosy: koustavpal88 priority: normal severity: normal status: open title: Installing local installation of Python type: performance versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 11:49:26 2015 From: report at bugs.python.org (Florin Papa) Date: Fri, 13 Nov 2015 16:49:26 +0000 Subject: [issue25300] Enable Intel MPX (Memory protection Extensions) feature In-Reply-To: <1443788737.62.0.174147088714.issue25300@psf.upfronthosting.co.za> Message-ID: <1447433366.66.0.76263702637.issue25300@psf.upfronthosting.co.za> Florin Papa added the comment: Hi all, We have set up a Skylake buildbot, which could be used for MPX builds. The errors that appear when running regrtest are proxy related and we are looking into a solution for that. There is no problem for tests that do not access network resources. The buildbot is available here: http://buildbot.python.org/all/builders/x86-64%20Ubuntu%2015.10%20Skylake%20CPU%202.7 Thank you, Florin Papa ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 12:15:13 2015 From: report at bugs.python.org (Ivan Levkivskyi) Date: Fri, 13 Nov 2015 17:15:13 +0000 Subject: [issue25610] Add typing.Awaitable In-Reply-To: <1447355768.55.0.0781055266737.issue25610@psf.upfronthosting.co.za> Message-ID: <1447434913.06.0.826819472167.issue25610@psf.upfronthosting.co.za> Changes by Ivan Levkivskyi : ---------- nosy: +levkivskyi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 13:03:11 2015 From: report at bugs.python.org (mrudula) Date: Fri, 13 Nov 2015 18:03:11 +0000 Subject: [issue25618] gdk attribute error Message-ID: <1447437791.6.0.752022160668.issue25618@psf.upfronthosting.co.za> New submission from mrudula: I am porting application from python 2 to python 3. Unable to import rati modules and local modules. gdk is not getting imported and unable to access many module. AttributeError: 'gi.repository.Gtk' object has no attribute 'gdk' ---------- components: 2to3 (2.x to 3.x conversion tool) messages: 254608 nosy: mrudula priority: normal severity: normal status: open title: gdk attribute error type: compile error versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 13:15:35 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 13 Nov 2015 18:15:35 +0000 Subject: [issue25580] async and await missing from token list In-Reply-To: <1446912139.74.0.381744244104.issue25580@psf.upfronthosting.co.za> Message-ID: <1447438535.8.0.621256098081.issue25580@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Are you suggesting that the note should state that these two are temporary? Yes, that would be great. > Or is this information available somewhere else, in What's new, for example? Not directly, I think. It was detailed to some extent in PEP 492. In what's new of 3.5 & 3.6 it's stated that async/await will be keywords in 3.7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 13:18:24 2015 From: report at bugs.python.org (Ethan Furman) Date: Fri, 13 Nov 2015 18:18:24 +0000 Subject: [issue25594] enum instance attribute access possible In-Reply-To: <1447144067.5.0.526378354242.issue25594@psf.upfronthosting.co.za> Message-ID: <1447438704.65.0.0137202045669.issue25594@psf.upfronthosting.co.za> Ethan Furman added the comment: Thanks for tracking that down. After more research I'm inclined to leave the code as it is and revamp the docs to clarify that while it may work, the results may not be what you want: -- 8< ------------------- class Color(Enum): red = 1 blue = 2 name = 3 print(Color.name) # Color.name print(Color.name.blue) # Color.blue print(Color.blue.name) # 'blue' (not Color.name!) -- 8< ------------------- Patch attached. ---------- stage: needs patch -> patch review Added file: http://bugs.python.org/file41030/issue25594.stoneleaf.01.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 13:36:49 2015 From: report at bugs.python.org (SilentGhost) Date: Fri, 13 Nov 2015 18:36:49 +0000 Subject: [issue25580] async and await missing from token list In-Reply-To: <1446912139.74.0.381744244104.issue25580@psf.upfronthosting.co.za> Message-ID: <1447439809.86.0.848069136993.issue25580@psf.upfronthosting.co.za> SilentGhost added the comment: Here is the updated wording. I'm not familiar with other such cases in the stdlib, if any one knows of another similar case, I'd be glad to correct the language to match previous usage. ---------- Added file: http://bugs.python.org/file41031/issue25580_2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 14:08:03 2015 From: report at bugs.python.org (terry) Date: Fri, 13 Nov 2015 19:08:03 +0000 Subject: [issue25619] Exception AttributeError: "'NoneType'.... thrown on exit Message-ID: <1447441683.08.0.711928345113.issue25619@psf.upfronthosting.co.za> New submission from terry: The attached code generates this output: init called finished init init called finished init init called finished init initPorts done alldone destroying /sys/class/gpio/gpio16/ destroying /sys/class/gpio/gpio6/ Exception AttributeError: "'NoneType' object has no attribute 'path'" in > ignored destroying /sys/class/gpio/gpio13/ Exception AttributeError: "'NoneType' object has no attribute 'path'" in > ignored It is necessary to have two functions defined (railVarRes() and batleveltopct()) and further more changing the name of railVarRes to arailVarRes changes the behavior: init called finished init init called finished init init called finished init initPorts done alldone destroying /sys/class/gpio/gpio16/ destroying /sys/class/gpio/gpio13/ destroying /sys/class/gpio/gpio6/ Exception AttributeError: "'NoneType' object has no attribute 'path'" in > ignored notice that the order of the class destruction has changed. ---------- files: bug.py messages: 254612 nosy: Terry Garyet priority: normal severity: normal status: open title: Exception AttributeError: "'NoneType'.... thrown on exit type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file41032/bug.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 14:16:42 2015 From: report at bugs.python.org (Marios Kourtesis) Date: Fri, 13 Nov 2015 19:16:42 +0000 Subject: [issue25620] Bytes Issue Message-ID: <1447442202.29.0.169880559008.issue25620@psf.upfronthosting.co.za> New submission from Marios Kourtesis: Hello, Executing the following code in a Python2 interpreter the result is True while running the same code in Python3 is False. I tested this in Python version 2.7.10 and 3.4.2. a = b'a' b = b'b' c = a+b c[1] == b'b' When I call type(c[1]) in Python2 I get str: type(c[1]) While in Python3 I get int: type(c[1]) Is this the expected behavior? ---------- components: Interpreter Core messages: 254613 nosy: Marios Kourtesis priority: normal severity: normal status: open title: Bytes Issue type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 14:21:57 2015 From: report at bugs.python.org (SilentGhost) Date: Fri, 13 Nov 2015 19:21:57 +0000 Subject: [issue25620] Bytes Issue In-Reply-To: <1447442202.29.0.169880559008.issue25620@psf.upfronthosting.co.za> Message-ID: <1447442517.02.0.0524482286407.issue25620@psf.upfronthosting.co.za> SilentGhost added the comment: Yes. It follows from definition of bytes in python3 https://docs.python.org/3/library/functions.html#bytes Some useful information is also available in 3.0 release notes: https://docs.python.org/3/whatsnew/3.0.html#text-vs-data-instead-of-unicode-vs-8-bit ---------- nosy: +SilentGhost resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 14:34:17 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 13 Nov 2015 19:34:17 +0000 Subject: [issue25618] gdk attribute error In-Reply-To: <1447437791.6.0.752022160668.issue25618@psf.upfronthosting.co.za> Message-ID: <1447443257.48.0.430918744292.issue25618@psf.upfronthosting.co.za> R. David Murray added the comment: Your report does not indicate a bug in python or its standard library, which is what this tracker is for. You are more likely to find help with your issues on the python-list mailing list. ---------- nosy: +r.david.murray resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 14:41:26 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 13 Nov 2015 19:41:26 +0000 Subject: [issue25619] Exception AttributeError: "'NoneType'.... thrown on exit In-Reply-To: <1447441683.08.0.711928345113.issue25619@psf.upfronthosting.co.za> Message-ID: <1447443686.75.0.623680718477.issue25619@psf.upfronthosting.co.za> R. David Murray added the comment: Yes, python2 shutdown has this problem: modules and their attributes are set to None during interpreter shutdown. Things are much better in python3. If you want to avoid the error messages, finalize the objects explicitly (making sure to break gc cycles) before the end of your program, or keep explicit references to the objects you need during __del__ (eg: os_path = os.path in the global scope of your module). As for your last comment, you are correct, the GC cleanup order is not deterministic. ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 14:42:48 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 13 Nov 2015 19:42:48 +0000 Subject: [issue25619] Exception AttributeError: "'NoneType'.... thrown on exit In-Reply-To: <1447441683.08.0.711928345113.issue25619@psf.upfronthosting.co.za> Message-ID: <1447443768.22.0.817216126735.issue25619@psf.upfronthosting.co.za> R. David Murray added the comment: Best practice, by the way, is to be explicit about the scope of any resource and clean it up before program end...this is often done by using the context manager protocol. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 15:05:58 2015 From: report at bugs.python.org (Eric Snow) Date: Fri, 13 Nov 2015 20:05:58 +0000 Subject: [issue25616] Extract OrderedDict tests into separate file In-Reply-To: <1447419681.57.0.354121086978.issue25616@psf.upfronthosting.co.za> Message-ID: <1447445158.55.0.039925007042.issue25616@psf.upfronthosting.co.za> Eric Snow added the comment: FWIW, I totally support this. I originally had a patch up that did so but Raymond indicated that he'd rather not split the tests out though I made exactly the same arguments that you have. Perhaps he's changed his mind in the intervening years (or I misunderstood his objections)? :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 15:30:48 2015 From: report at bugs.python.org (Maxime Chambreuil) Date: Fri, 13 Nov 2015 20:30:48 +0000 Subject: [issue25621] ast.literal_eval() fails on docstrings Message-ID: <1447446648.4.0.141417536435.issue25621@psf.upfronthosting.co.za> New submission from Maxime Chambreuil: ast.literal_eval fails when there is docstrings in the file. I used the file attached and this code in our CI server: def is_installable_module(path): """return False if the path doesn't contain an installable odoo module, and the full path to the module manifest otherwise""" manifest_path = is_module(path) if manifest_path: manifest = ast.literal_eval(open(manifest_path).read()) if manifest.get('installable', True): return manifest_path return False I get the following error message: Traceback (most recent call last): File "/home/travis/maintainer-quality-tools/travis/test_flake8", line 14, in for addon in get_modules(os.path.abspath('.')): File "/home/travis/maintainer-quality-tools/travis/getaddons.py", line 53, in get_modules if is_installable_module(os.path.join(path, x))] File "/home/travis/maintainer-quality-tools/travis/getaddons.py", line 38, in is_installable_module manifest = ast.literal_eval(open(manifest_path).read()) File "/usr/lib/python2.7/ast.py", line 49, in literal_eval node_or_string = parse(node_or_string, mode='eval') File "/usr/lib/python2.7/ast.py", line 37, in parse return compile(source, filename, mode, PyCF_ONLY_AST) File "", line 22 { ^ SyntaxError: invalid syntax https://github.com/OCA/knowledge/pull/75 https://github.com/OCA/maintainer-quality-tools/blob/master/travis/getaddons.py#L33 https://travis-ci.org/OCA/knowledge/jobs/90332842 ---------- components: Interpreter Core files: __openerp__.py messages: 254619 nosy: Maxime Chambreuil priority: normal severity: normal status: open title: ast.literal_eval() fails on docstrings type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file41033/__openerp__.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 15:37:26 2015 From: report at bugs.python.org (Maxime Chambreuil) Date: Fri, 13 Nov 2015 20:37:26 +0000 Subject: [issue25621] ast.literal_eval() fails on docstrings In-Reply-To: <1447446648.4.0.141417536435.issue25621@psf.upfronthosting.co.za> Message-ID: <1447447046.38.0.610608322466.issue25621@psf.upfronthosting.co.za> Maxime Chambreuil added the comment: If I remove the docstrings on the first line, ast.literal_eval() does not fail. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 15:41:38 2015 From: report at bugs.python.org (SilentGhost) Date: Fri, 13 Nov 2015 20:41:38 +0000 Subject: [issue25621] ast.literal_eval() fails on docstrings In-Reply-To: <1447446648.4.0.141417536435.issue25621@psf.upfronthosting.co.za> Message-ID: <1447447298.75.0.73383748478.issue25621@psf.upfronthosting.co.za> SilentGhost added the comment: It doesn't seem docstring-specific, docstring is a regular Python object and ast.literal_eval would fail if you have more than one literals of any kind. Put two integers in your file and the literal_eval will fail. ---------- nosy: +SilentGhost, benjamin.peterson, georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 15:50:24 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 13 Nov 2015 20:50:24 +0000 Subject: [issue25621] ast.literal_eval() fails on docstrings In-Reply-To: <1447446648.4.0.141417536435.issue25621@psf.upfronthosting.co.za> Message-ID: <1447447824.25.0.883904356588.issue25621@psf.upfronthosting.co.za> R. David Murray added the comment: Yes, literal_eval only evaluates a single literal, as is documented. ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 16:28:54 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 13 Nov 2015 21:28:54 +0000 Subject: [issue25622] Enable ctypes.test.test_values.Win_ValuesTestCase for non-Windows Message-ID: <1447450134.96.0.43104915369.issue25622@psf.upfronthosting.co.za> New submission from Martin Panter: In /Lib/ctypes/test/test_values.py, three out of the five test cases are only run on Windows. There is a comment saying ?This test only works when python itself is a dll/shared library?, and the tests run fine on Linux. So I propose to remove the Windows-only restriction, and rename the class from Win_ValuesTestCase to PythonValuesTestCase. The immediate benefit for me is that I can see on Linux when I need to update one of those tests before I break a Windows builtbot :) This test used to be completely disabled (probably by accident), and was enabled for Windows only in revision 6f63fff5c120. There was a comment by Zach wondering if it shouldn?t be Windows-specific. ---------- components: Tests, ctypes files: python-values.patch keywords: patch messages: 254623 nosy: martin.panter, zach.ware priority: normal severity: normal stage: patch review status: open title: Enable ctypes.test.test_values.Win_ValuesTestCase for non-Windows type: enhancement versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file41034/python-values.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 16:49:43 2015 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 13 Nov 2015 21:49:43 +0000 Subject: [issue25074] Bind logger and waninigs modules for asyncio __del__ methods In-Reply-To: <1441998965.13.0.504603864253.issue25074@psf.upfronthosting.co.za> Message-ID: <1447451383.41.0.887300487053.issue25074@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Yes, the approach use hackery shadows for binding global variables on shutdown stage. The same I've found in subprocess module: see https://github.com/python/cpython/blob/master/Lib/subprocess.py#L1544 The problem is: I want to inform users about unclosed resources. Printouts like `TypeError: 'NoneType' object is not callable` or `AttributeError: 'NoneType' object has no attribute 'warn'` are too confusing for casual developer. On shutdown logger and warnings modules may be destroyed at the moment of __del__ call, so `warnings.warn`, `loop.call_exception_handler` etc. are forbidden. As an option we can add atexit handler to store shutdown flag into loop object (I don't know other way to get info is interpreter in shutdown or not). According to the flag we can eihter print some short text about non-closed resources or raise proper ResourceWarning along with comprehensive logging with stacktrace if PYTHONASYNCIO is on. Maybe I've missed something and you can suggest better solution. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 16:55:13 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 13 Nov 2015 21:55:13 +0000 Subject: [issue25569] Memory leak in SSLSocket.getpeercert() In-Reply-To: <1446840481.06.0.811345685129.issue25569@psf.upfronthosting.co.za> Message-ID: <1447451713.25.0.624987143298.issue25569@psf.upfronthosting.co.za> Martin Panter added the comment: Seems to have broken the SSL module. Looks like you typoed ?dps? as ?dsp? in some conditional code. http://buildbot.python.org/all/builders/AMD64%20Snow%20Leop%203.4/builds/1326/steps/compile/logs/stdio building '_ssl' extension gcc -fno-strict-aliasing -g -O0 -Wall -Wstrict-prototypes -Werror=declaration-after-statement -I./Include -I. -IInclude -I/Users/buildbot/buildarea/3.4.murray-snowleopard/build/Include -I/Users/buildbot/buildarea/3.4.murray-snowleopard/build -c /Users/buildbot/buildarea/3.4.murray-snowleopard/build/Modules/_ssl.c -o build/temp.macosx-10.6-x86_64-3.4-pydebug/Users/buildbot/buildarea/3.4.murray-snowleopard/build/Modules/_ssl.o /Users/buildbot/buildarea/3.4.murray-snowleopard/build/Modules/_ssl.c: In function ?_get_crl_dp?: /Users/buildbot/buildarea/3.4.murray-snowleopard/build/Modules/_ssl.c:1084: error: ?dsp? undeclared (first use in this function) /Users/buildbot/buildarea/3.4.murray-snowleopard/build/Modules/_ssl.c:1084: error: (Each undeclared identifier is reported only once /Users/buildbot/buildarea/3.4.murray-snowleopard/build/Modules/_ssl.c:1084: error: for each function it appears in.) /Users/buildbot/buildarea/3.4.murray-snowleopard/build/Modules/_ssl.c: In function ?_setup_ssl_threads?: /Users/buildbot/buildarea/3.4.murray-snowleopard/build/Modules/_ssl.c:3828: warning: comparison is always false due to limited range of data type ---------- nosy: +martin.panter status: closed -> open versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 16:56:15 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 13 Nov 2015 21:56:15 +0000 Subject: [issue25569] Memory leak in SSLSocket.getpeercert() In-Reply-To: <1446840481.06.0.811345685129.issue25569@psf.upfronthosting.co.za> Message-ID: <1447451774.99.0.0691515204504.issue25569@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 17:02:30 2015 From: report at bugs.python.org (Neil Schemenauer) Date: Fri, 13 Nov 2015 22:02:30 +0000 Subject: [issue7759] mhlib fails on Btrfs filesystem (test_mhlib failure) In-Reply-To: <1264198934.84.0.705718671648.issue7759@psf.upfronthosting.co.za> Message-ID: <1447452150.03.0.451328936264.issue7759@psf.upfronthosting.co.za> Neil Schemenauer added the comment: So what happens for the filesystems that doesn't count '.' and '..'? It looks to me like if there are exactly two messages in a folder then the revised code will return [] (i.e. it will think the folder is empty). Probably we should revise the unit test to make a folder with two messages. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 17:14:44 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 13 Nov 2015 22:14:44 +0000 Subject: [issue24821] The optimization of string search can cause pessimization In-Reply-To: <1438927886.02.0.407236930114.issue24821@psf.upfronthosting.co.za> Message-ID: <1447452884.31.0.563675010039.issue24821@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Proposed patch makes the degenerate case less hard while preserves the optimization for common case. $ ./python -m timeit -s 's = "?????"*10**5' -- 's.find("?")' 1000 loops, best of 3: 330 usec per loop $ ./python -m timeit -s 's = "?????"*10**5' -- 's.rfind("?")' 1000 loops, best of 3: 325 usec per loop $ ./python -m timeit -s 's = "?????"*10**5' -- 's.find("?")' 100 loops, best of 3: 7.81 msec per loop $ ./python -m timeit -s 's = "?????"*10**5' -- 's.rfind("?")' 100 loops, best of 3: 8.5 msec per loop $ ./python -m timeit -s 's = "?????"*10**5' -- 's.find("?")' 1000 loops, best of 3: 317 usec per loop $ ./python -m timeit -s 's = "?????"*10**5' -- 's.rfind("?")' 1000 loops, best of 3: 327 usec per loop $ ./python -m timeit -s 's = "?????"*10**5' -- 's.find("?")' 1000 loops, best of 3: 1.1 msec per loop $ ./python -m timeit -s 's = "?????"*10**5' -- 's.rfind("?")' 1000 loops, best of 3: 964 usec per loop The slowdown is decreased from 25 times to 3 times. The idea is that after memchr found false positive, make a tens iterations of simple loop before calling memchr again. This splits the cost of the memchr call with a tens of characters. The patch also makes a little refactoring. STRINGLIB(fastsearch_memchr_1char) now is renamed and split on two functions STRINGLIB(find_char) and STRINGLIB(rfind_char) with simpler interface. All preconditional checks are moved into these functions. These functions now are directly used in other files. ---------- keywords: +patch resolution: remind -> stage: needs patch -> patch review Added file: http://bugs.python.org/file41035/find_char.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 17:20:14 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 13 Nov 2015 22:20:14 +0000 Subject: [issue25498] Python 3.4.3 regression in ctypes.frombuffer() In-Reply-To: <1446055572.58.0.349657416945.issue25498@psf.upfronthosting.co.za> Message-ID: <20151113222011.120366.81462@psf.io> Roundup Robot added the comment: New changeset 9b23f7a94ba9 by Martin Panter in branch '3.4': Issue #25498: Fix GC crash due to ctypes objects wrapping a memoryview https://hg.python.org/cpython/rev/9b23f7a94ba9 New changeset 7445de785670 by Martin Panter in branch '3.5': Issue #25498: Merge ctypes crash fix from 3.4 into 3.5 https://hg.python.org/cpython/rev/7445de785670 New changeset deb0fb601191 by Martin Panter in branch '3.5': Issue #25498: Update error message for 3.5 https://hg.python.org/cpython/rev/deb0fb601191 New changeset f3dba13c22e5 by Martin Panter in branch 'default': Issue #25498: Merge ctypes crash fix from 3.5 https://hg.python.org/cpython/rev/f3dba13c22e5 New changeset 08c56962c24c by Martin Panter in branch 'default': Issue #25498: Add NEWS entry for 3.6 https://hg.python.org/cpython/rev/08c56962c24c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 17:28:29 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 13 Nov 2015 22:28:29 +0000 Subject: [issue25583] os.makedirs with exist_ok=True raises PermissionError on Windows 7^ In-Reply-To: <1446993273.85.0.222873165522.issue25583@psf.upfronthosting.co.za> Message-ID: <1447453709.67.0.755478973198.issue25583@psf.upfronthosting.co.za> Martin Panter added the comment: New patch with simpler test case and revised NEWS entry ---------- Added file: http://bugs.python.org/file41036/makedirs-exist.2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 17:35:48 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 13 Nov 2015 22:35:48 +0000 Subject: [issue7759] mhlib fails on Btrfs filesystem (test_mhlib failure) In-Reply-To: <1264198934.84.0.705718671648.issue7759@psf.upfronthosting.co.za> Message-ID: <1447454148.83.0.58517084932.issue7759@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: st_nlink is not related to the number of messages in a folder. It is a number of hard links. If the filesystem supports hard links counting for directories, every directory (except /) has at least two links: one from its parent directory, and one from itself (via "."). Every subdirectory adds yet one hard link via "..". Non-directory files don't create hard links. Typical mail folder can contain thousands of messages and none or only a few subfolders. Subfolders (if there are any) usually are created before messages and hence encountered first in directory listing. Hereby the optimization can have significant effect. If there is a real case when st_nlink != 1 and is less then a number of subdirectories + 2, we should consider removing the optimization. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 17:58:22 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 13 Nov 2015 22:58:22 +0000 Subject: [issue25580] async and await missing from token list In-Reply-To: <1446912139.74.0.381744244104.issue25580@psf.upfronthosting.co.za> Message-ID: <1447455502.37.0.341977923187.issue25580@psf.upfronthosting.co.za> Martin Panter added the comment: Will they really be removed? What are the compatibility implications? Maybe it would be better to alias them to NAME, or keep them as unused values. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 18:04:25 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 13 Nov 2015 23:04:25 +0000 Subject: [issue25580] async and await missing from token list In-Reply-To: <1446912139.74.0.381744244104.issue25580@psf.upfronthosting.co.za> Message-ID: <1447455865.08.0.465302929354.issue25580@psf.upfronthosting.co.za> Martin Panter added the comment: My only background here is via the tokenize module, which seems to currently behave as described in : async and await are either NAME tokens (like ordinary identifiers and other reserved keywords) outside a coroutine definition, but they become special ASYNC and AWAIT tokens inside a coroutine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 18:07:40 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 13 Nov 2015 23:07:40 +0000 Subject: [issue25498] Python 3.4.3 regression in ctypes.frombuffer() In-Reply-To: <1446055572.58.0.349657416945.issue25498@psf.upfronthosting.co.za> Message-ID: <1447456060.47.0.0872102486123.issue25498@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks to the various people that helped report and solve this. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 18:11:53 2015 From: report at bugs.python.org (Maciej Szulik) Date: Fri, 13 Nov 2015 23:11:53 +0000 Subject: [issue13940] imaplib: Mailbox names are not quoted In-Reply-To: <1328357098.01.0.78801274991.issue13940@psf.upfronthosting.co.za> Message-ID: <1447456313.47.0.914217809001.issue13940@psf.upfronthosting.co.za> Maciej Szulik added the comment: >From imaplib.IMAP4 class description we're stating to quote parameters if necessary. This patch adds that capability according to https://tools.ietf.org/html/rfc3501#section-5.1 ---------- keywords: +patch Added file: http://bugs.python.org/file41037/issue13940.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 18:19:30 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 13 Nov 2015 23:19:30 +0000 Subject: [issue25615] Document unsorted behaviour of glob.glob In-Reply-To: <1447410381.17.0.519847126493.issue25615@psf.upfronthosting.co.za> Message-ID: <1447456770.8.0.5985492525.issue25615@psf.upfronthosting.co.za> Martin Panter added the comment: Looks good to me. Also worth applying to earlier versions I think. ---------- nosy: +martin.panter stage: -> patch review versions: +Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 18:32:25 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 13 Nov 2015 23:32:25 +0000 Subject: [issue25620] Bytes Issue In-Reply-To: <1447442202.29.0.169880559008.issue25620@psf.upfronthosting.co.za> Message-ID: <1447457545.86.0.308040437309.issue25620@psf.upfronthosting.co.za> Martin Panter added the comment: More up-to-date information about the differences might be . If you want code that works in both versions, I find it simpler to use slicing: c[1:2] == b'b'. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 18:57:41 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 13 Nov 2015 23:57:41 +0000 Subject: [issue25590] tab-completition on instances repeatedly accesses attribute/descriptors values In-Reply-To: <1447107343.63.0.0427300203207.issue25590@psf.upfronthosting.co.za> Message-ID: <20151113235738.14349.5984@psf.io> Roundup Robot added the comment: New changeset 92f989bfeca2 by Martin Panter in branch '3.4': Issue #25590: Make rlcompleter only call getattr() once per attribute https://hg.python.org/cpython/rev/92f989bfeca2 New changeset 808279e14700 by Martin Panter in branch '3.5': Issue #25590: Merge rlcompleter change from 3.4 into 3.5 https://hg.python.org/cpython/rev/808279e14700 New changeset ff68304356fe by Martin Panter in branch 'default': Issue #25590: Merge rlcompleter getattr change from 3.5 https://hg.python.org/cpython/rev/ff68304356fe New changeset bbf63749a129 by Martin Panter in branch 'default': Issue #25590: Complete attribute names even if they are not yet created https://hg.python.org/cpython/rev/bbf63749a129 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 19:45:13 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 14 Nov 2015 00:45:13 +0000 Subject: [issue25590] tab-completition on instances repeatedly accesses attribute/descriptors values In-Reply-To: <1447107343.63.0.0427300203207.issue25590@psf.upfronthosting.co.za> Message-ID: <20151114004510.14353.14758@psf.io> Roundup Robot added the comment: New changeset 16d83e11675f by Martin Panter in branch '2.7': Issue #25590: Make rlcompleter only call getattr() once per attribute https://hg.python.org/cpython/rev/16d83e11675f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 19:45:13 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 14 Nov 2015 00:45:13 +0000 Subject: [issue25017] htmllib deprecated: Which library to use? Missing sane default in docs In-Reply-To: <1441616497.34.0.0999815194375.issue25017@psf.upfronthosting.co.za> Message-ID: <20151114004511.14353.37505@psf.io> Roundup Robot added the comment: New changeset 7bc8f56ef1f3 by Martin Panter in branch '2.7': Issue #25017: Document that htmllib is superseded by module HTMLParser https://hg.python.org/cpython/rev/7bc8f56ef1f3 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 19:48:43 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 14 Nov 2015 00:48:43 +0000 Subject: [issue25017] htmllib deprecated: Which library to use? Missing sane default in docs In-Reply-To: <1441616497.34.0.0999815194375.issue25017@psf.upfronthosting.co.za> Message-ID: <1447462123.27.0.0557596549751.issue25017@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 21:11:41 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 14 Nov 2015 02:11:41 +0000 Subject: [issue25590] tab-completition on instances repeatedly accesses attribute/descriptors values In-Reply-To: <1447107343.63.0.0427300203207.issue25590@psf.upfronthosting.co.za> Message-ID: <1447467101.73.0.726857437874.issue25590@psf.upfronthosting.co.za> Martin Panter added the comment: I also ported the getattr patch to the 2.7 branch. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 21:27:23 2015 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 14 Nov 2015 02:27:23 +0000 Subject: [issue25590] tab-completition on instances repeatedly accesses attribute/descriptors values In-Reply-To: <1447107343.63.0.0427300203207.issue25590@psf.upfronthosting.co.za> Message-ID: <1447468043.83.0.230035885679.issue25590@psf.upfronthosting.co.za> Ezio Melotti added the comment: Thanks for taking care of this! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 23:24:29 2015 From: report at bugs.python.org (terry) Date: Sat, 14 Nov 2015 04:24:29 +0000 Subject: [issue25619] Exception AttributeError: "'NoneType'.... thrown on exit In-Reply-To: <1447443768.22.0.817216126735.issue25619@psf.upfronthosting.co.za> Message-ID: <7F40CFD6-35DA-43F9-80A9-631AA33EF49C@gmail.com> terry added the comment: My real application (not this example code that also 'breaks') is a battery monitor that starts at boot time and only exits when the battery is near death. So there is effectively a while(batlevelgood) loop that polls the battery level and doesn't exit until near battery death. I only encounters this while debugging and having to kill (ctrl-c) the script, having no chance to clean up properly. Admittedly I'm not very experienced in Python but I am an experienced programmer. I will look up context mgr protocol, but this was certainly odd behavior. It isn't every day that the name of a function not even called changes observed program behavior. Terry > On Nov 13, 2015, at 1:42 PM, R. David Murray wrote: > > > R. David Murray added the comment: > > Best practice, by the way, is to be explicit about the scope of any resource and clean it up before program end...this is often done by using the context manager protocol. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ ---------- title: Exception AttributeError: "'NoneType'.... thrown on exit -> Exception AttributeError: "'NoneType'.... thrown on exit _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 23:37:50 2015 From: report at bugs.python.org (A. Jesse Jiryu Davis) Date: Sat, 14 Nov 2015 04:37:50 +0000 Subject: [issue25612] nested try..excepts don't work correctly for generators In-Reply-To: <1447361959.0.0.839122121456.issue25612@psf.upfronthosting.co.za> Message-ID: <1447475870.89.0.381074024385.issue25612@psf.upfronthosting.co.za> Changes by A. Jesse Jiryu Davis : ---------- nosy: +emptysquare _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 14 03:02:38 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 14 Nov 2015 08:02:38 +0000 Subject: [issue25168] test_datetime.test_strptime() random failures on "s390x SLES" buildbots In-Reply-To: <1442584249.02.0.854297601638.issue25168@psf.upfronthosting.co.za> Message-ID: <1447488158.12.0.299820745507.issue25168@psf.upfronthosting.co.za> Martin Panter added the comment: I wonder if this has anything to do with _strptime._TimeRE_cache. This seems to get initialized when _strptime is first imported. Some of the tests in datetimetester temporarily set the timezone to -0500 EST, and another to UTC, but they change it back afterwards. So I cannot see how it could have an effect, but I don?t have a better theory. >>> import _strptime # Regular expression cache is initialized >>> _strptime._TimeRE_cache["Z"] # I don't have a time zone set '(?Pgmt|utc)' >>> import os, time >>> os.environ["TZ"] = 'EST+05EDT,M3.2.0,M11.1.0' >>> time.tzset() >>> time.tzname ('EST', 'EDT') >>> from datetime import datetime >>> datetime.strptime("-0500 EST", "%z %Z") # Using original cache Traceback (most recent call last): File "", line 1, in File "/home/proj/python/cpython/Lib/_strptime.py", line 555, in _strptime_datetime tt, fraction = _strptime(data_string, format) File "/home/proj/python/cpython/Lib/_strptime.py", line 356, in _strptime (data_string, format)) ValueError: time data '-0500 EST' does not match format '%z %Z' ---------- components: +Tests nosy: +martin.panter type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 14 03:11:29 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 14 Nov 2015 08:11:29 +0000 Subject: [issue25569] Memory leak in SSLSocket.getpeercert() In-Reply-To: <1446840481.06.0.811345685129.issue25569@psf.upfronthosting.co.za> Message-ID: <20151114081126.109175.13689@psf.io> Roundup Robot added the comment: New changeset 3b9fb8ebf44f by Benjamin Peterson in branch '2.7': fix build with older openssl (#25569) https://hg.python.org/cpython/rev/3b9fb8ebf44f New changeset f13a75544b6f by Benjamin Peterson in branch '3.4': fix build with older openssl (#25569) https://hg.python.org/cpython/rev/f13a75544b6f New changeset 83ea7e75605a by Benjamin Peterson in branch '3.5': merge 3.4 (#25569) https://hg.python.org/cpython/rev/83ea7e75605a New changeset 8ac09e46ca45 by Benjamin Peterson in branch 'default': merge 3.5 (#25569) https://hg.python.org/cpython/rev/8ac09e46ca45 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 14 03:12:48 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 14 Nov 2015 08:12:48 +0000 Subject: [issue25623] Keep the link to Python implementation of OrderedDict Message-ID: <1447488768.43.0.519685796607.issue25623@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: For now C implementation of OrderedDict totally overrides Python implementation. >>> import collections >>> collections.OrderedDict.__init__ The only way to get Python implementation of OrderedDict is to block the _collections module and reload the collections module. >>> del sys.modules['collections'] >>> del sys.modules['collections.abc'] >>> sys.modules['_collections'] = None >>> import collections >>> collections.OrderedDict.__init__ But this also blocks collections.deque, collections.defaultdict, and the acceleration of collections.Counter. As long as C implementation of OrderedDict still has some bugs (and I'm not sure we will have fixed all them before releasing 3.5.1), I think it would be good to have a workaround for applications that encounter one of still not fixed bugs. I propose to keep a reference to Python implementation as collections._OrderedDict. This is not a public interface and we don't promise existing this name in future releases. This is just a way to make a workaround for the time while C implementation is not stable enough. I hope we will got rid from it in 3.7. A workaround for an application that suffers from OrderedDict bug: import collections try: collections.OrderedDict = collections._OrderedDict except AttributeError: pass ---------- components: Library (Lib) files: OrderedDict_python_impl.patch keywords: patch messages: 254645 nosy: eric.snow, rhettinger, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Keep the link to Python implementation of OrderedDict type: enhancement versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file41038/OrderedDict_python_impl.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 14 03:34:21 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 14 Nov 2015 08:34:21 +0000 Subject: [issue24928] mock.patch.dict spoils order of items in collections.OrderedDict In-Reply-To: <1440443995.19.0.0795335566212.issue24928@psf.upfronthosting.co.za> Message-ID: <1447490061.98.0.984795736758.issue24928@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +needs review nosy: +michael.foord stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 14 03:55:36 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 14 Nov 2015 08:55:36 +0000 Subject: [issue25168] test_datetime.test_strptime() random failures on "s390x SLES" buildbots In-Reply-To: <1442584249.02.0.854297601638.issue25168@psf.upfronthosting.co.za> Message-ID: <20151114085531.14353.72562@psf.io> Roundup Robot added the comment: New changeset 139c18943d9b by Martin Panter in branch 'default': Issue #25168: Temporary timezone and cache debugging https://hg.python.org/cpython/rev/139c18943d9b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 14 04:25:24 2015 From: report at bugs.python.org (Dingyuan Wang) Date: Sat, 14 Nov 2015 09:25:24 +0000 Subject: [issue25624] shutil.make_archive makes invalid directory entries Message-ID: <1447493124.52.0.848319062026.issue25624@psf.upfronthosting.co.za> New submission from Dingyuan Wang: The _make_zipfile in shutil uses ZIP_DEFLATED compression by default, and the fix introduced by #24982 adds directory entries. In zipfile.ZipFile.write, directories is added as 0 file_size, 0 compress_size, regardless of the compression method. Deflate will compress an empty string as \x03\x00, thus the directory entries become incorrect. The command line interface of zipfile is correct. Shutil can be fixed as zipfile.main. As a directory entry with compression methods other than ZIP_STORED is meaningless, zipfile.write and (maybe) zipfile.writestr should always write a ZIP_STORED header for directory entries to avoid the above problem occuring by programming mistakes. ---------- components: Library (Lib) messages: 254647 nosy: gumblex priority: normal severity: normal status: open title: shutil.make_archive makes invalid directory entries type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 14 04:28:24 2015 From: report at bugs.python.org (SilentGhost) Date: Sat, 14 Nov 2015 09:28:24 +0000 Subject: [issue25624] shutil.make_archive makes invalid directory entries In-Reply-To: <1447493124.52.0.848319062026.issue25624@psf.upfronthosting.co.za> Message-ID: <1447493304.15.0.904746592948.issue25624@psf.upfronthosting.co.za> SilentGhost added the comment: Can you provide a test? ---------- nosy: +SilentGhost, serhiy.storchaka, tarek versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 14 05:11:22 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 14 Nov 2015 10:11:22 +0000 Subject: [issue25624] shutil.make_archive makes invalid directory entries In-Reply-To: <1447493124.52.0.848319062026.issue25624@psf.upfronthosting.co.za> Message-ID: <1447495882.78.0.564997013169.issue25624@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Do you want to provide a patch? ---------- assignee: -> serhiy.storchaka keywords: +easy stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 14 05:13:26 2015 From: report at bugs.python.org (Dingyuan Wang) Date: Sat, 14 Nov 2015 10:13:26 +0000 Subject: [issue25624] shutil.make_archive makes invalid directory entries In-Reply-To: <1447493124.52.0.848319062026.issue25624@psf.upfronthosting.co.za> Message-ID: <1447496006.02.0.558986648855.issue25624@psf.upfronthosting.co.za> Dingyuan Wang added the comment: $ mkdir foo; touch foo/a.txt; python3 -c "import shutil; shutil.make_archive('foo', 'zip', base_dir='foo')"; unzip -t foo.zip Archive: foo.zip testing: foo/ error: invalid compressed data to inflate testing: foo/a.txt OK At least one error was detected in foo.zip. (This affects 2.7, 3.4+) ---------- versions: +Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 14 05:52:44 2015 From: report at bugs.python.org (Dingyuan Wang) Date: Sat, 14 Nov 2015 10:52:44 +0000 Subject: [issue25624] shutil.make_archive makes invalid directory entries In-Reply-To: <1447493124.52.0.848319062026.issue25624@psf.upfronthosting.co.za> Message-ID: <1447498364.17.0.783090043913.issue25624@psf.upfronthosting.co.za> Dingyuan Wang added the comment: My patch for this. ---------- keywords: +patch Added file: http://bugs.python.org/file41039/storedirectory.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 14 06:43:37 2015 From: report at bugs.python.org (Daniel Plachotich) Date: Sat, 14 Nov 2015 11:43:37 +0000 Subject: [issue25583] os.makedirs with exist_ok=True raises PermissionError on Windows 7^ In-Reply-To: <1446993273.85.0.222873165522.issue25583@psf.upfronthosting.co.za> Message-ID: <1447501417.25.0.73847141585.issue25583@psf.upfronthosting.co.za> Daniel Plachotich added the comment: Looks good to me. Without the fix, the test fails on Windows 7 as expected. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 14 07:36:26 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 14 Nov 2015 12:36:26 +0000 Subject: [issue3353] make built-in tokenizer available via Python C API In-Reply-To: <1216035196.11.0.15913194841.issue3353@psf.upfronthosting.co.za> Message-ID: <1447504586.53.0.178611936657.issue3353@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag versions: +Python 3.6 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 14 07:51:44 2015 From: report at bugs.python.org (STINNER Victor) Date: Sat, 14 Nov 2015 12:51:44 +0000 Subject: [issue24821] The optimization of string search can cause pessimization In-Reply-To: <1438927886.02.0.407236930114.issue24821@psf.upfronthosting.co.za> Message-ID: <1447505504.07.0.102766107699.issue24821@psf.upfronthosting.co.za> STINNER Victor added the comment: > The patch also makes a little refactoring. STRINGLIB(fastsearch_memchr_1char) now is renamed and split on two functions STRINGLIB(find_char) and STRINGLIB(rfind_char) with simpler interface. Could you please push this part of the change? It looks good to me. -- The C library provides a wmemchr() function which can be used to search for a wchar_t character inside a wchar_t* string. * for 16-bit wchar_t (ex: Windows, AIX), it can be used for Python UCS2 strings * for 32-bit wchar_t (ex: Linux, Mac OS X), it can be used for Python UCS4 strings I don't know if the type is signed or not. If the type is signed, we have to ensure that wmemchr() works as expected. -- I didn't review carefully your new heuristic to search for a character. Did you try to not use memchr() but a simple C loop for UCS-2 and UCS-4? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 14 07:54:12 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 14 Nov 2015 12:54:12 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <20151114125408.88508.65047@psf.io> Roundup Robot added the comment: New changeset f8fa7bc837a3 by Martin Panter in branch 'default': Issue #23883: Add test.support.check__all__() and test gettext.__all__ https://hg.python.org/cpython/rev/f8fa7bc837a3 New changeset 78d67bdc1142 by Martin Panter in branch 'default': Issue #23883: Add missing APIs to __all__; patch by Jacek Ko?odziej https://hg.python.org/cpython/rev/78d67bdc1142 New changeset 25a7ceed79d1 by Martin Panter in branch 'default': Issue #23883: Add news listing modules with new exported APIs https://hg.python.org/cpython/rev/25a7ceed79d1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 14 08:05:19 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 14 Nov 2015 13:05:19 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <1447506319.4.0.681628611111.issue23883@psf.upfronthosting.co.za> Martin Panter added the comment: Thankyou for sticking with this Jacek. I have committed your three patches. I reworded the documentation a little bit, mainly so it says that it looks for ?public? names, rather than documented names, because it does not look at documentation at all. I also added a note to the Changes in the Python API section of What?s New. Next step I think is to finish off those patches for tarfile, calendar and fileinput. ---------- stage: patch review -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 14 08:15:01 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 14 Nov 2015 13:15:01 +0000 Subject: [issue25388] tokenizer crash/misbehavior -- heap use-after-free In-Reply-To: <1444706115.92.0.283351483962.issue25388@psf.upfronthosting.co.za> Message-ID: <20151114131458.4665.37743@psf.io> Roundup Robot added the comment: New changeset 73da4fd7542b by Serhiy Storchaka in branch '3.4': Issue #25388: Fixed tokenizer crash when processing undecodable source code https://hg.python.org/cpython/rev/73da4fd7542b New changeset e4a69eb34ad7 by Serhiy Storchaka in branch '3.5': Issue #25388: Fixed tokenizer crash when processing undecodable source code https://hg.python.org/cpython/rev/e4a69eb34ad7 New changeset ea0c4b811eae by Serhiy Storchaka in branch 'default': Issue #25388: Fixed tokenizer crash when processing undecodable source code https://hg.python.org/cpython/rev/ea0c4b811eae New changeset 8e472cc258ec by Serhiy Storchaka in branch '2.7': Issue #25388: Fixed tokenizer hang when processing undecodable source code https://hg.python.org/cpython/rev/8e472cc258ec ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 14 08:34:34 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 14 Nov 2015 13:34:34 +0000 Subject: [issue25168] test_datetime.test_strptime() random failures on "s390x SLES" buildbots In-Reply-To: <1442584249.02.0.854297601638.issue25168@psf.upfronthosting.co.za> Message-ID: <1447508074.66.0.525534025508.issue25168@psf.upfronthosting.co.za> Martin Panter added the comment: Info when the s390x SLES 3.x buildbot failed : _TimeRE_cache['Z']='(?Pstd|utc|gmt|dst)' TZ=None, or None via getenv() _regex_cache={'%Y-%m-%d %H:%M:%S.%f': re.compile('(?P\\d\\d\\d\\d)-(?P1[0-2]|0[1-9]|[1-9])-(?P3[0-1]|[1-2]\\d|0[1-9]|[1-9]| [1-9])\\s+(?P2[0-3]|[0-1]\\d|\\d):(?P[0-5]\\d|\\d):(?P6[0-1]|[0-5]\\d|\\d)\\.(?P[0-9]{1,6})', re.IGNORECASE), '%Z': re.compile('(?Pstd|utc|gmt|dst)', re.IGNORECASE), '%z %Z': re.compile('(?P[+-]\\d\\d[0-5]\\d)\\s+(?Pstd|utc|gmt|dst)', re.IGNORECASE), '%z': re.compile('(?P[+-]\\d\\d[0-5]\\d)', re.IGNORECASE)} So it seems _TimeRE_cache has been initialized when time.tzname = ("STD", "DST"), and this agrees with the contents of _regex_cache. When the tests fail, there is no TZ environment variable set, but the test is trying to use the time zone ?EST?, which apparently comes from time.tzname[0]. The question in my mind is why did tzname change from when _strptime was initialized to when the tests ran? Keys in _regex_cache, showing what has been parsed since it was cleared: '%Y-%m-%d %H:%M:%S.%f' '%Z' '%z %Z' '%z' test_strptime() is inherited by various classes. The first version passed, and the other five failed: test_strptime (test.datetimetester.TestDateTime) ... ok test_strptime (test.datetimetester.TestSubclassDateTime) ... FAIL test_strptime (test.datetimetester.TestDateTimeTZ) ... FAIL test_strptime (test.datetimetester.TestDateTime) ... FAIL test_strptime (test.datetimetester.TestSubclassDateTime) ... FAIL test_strptime (test.datetimetester.TestDateTimeTZ) ... FAIL Inbetween the good and the first bad test_strptime() runs, there are the remaining TestDateTime tests, then the TestDateOnly, TestTZInfo, TestTimeZone, TestTimeTZ, TestDate, TestTimezoneConversions and TestTime classes, and finally the initial TestSubclassDateTime tests. Tests appear to be in alphabetical order by method name within each class, but the classes are in arbitrary order. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 14 08:45:19 2015 From: report at bugs.python.org (=?utf-8?q?Jacek_Ko=C5=82odziej?=) Date: Sat, 14 Nov 2015 13:45:19 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <1447508719.41.0.601472920181.issue23883@psf.upfronthosting.co.za> Jacek Ko?odziej added the comment: Martin, yay! :) And thank you for the documentation correction. Milap, Joel, Mauro, are you still interested in working on patches for calendar/tarfile/fileinput patches? I intend to finish them up if that's not the case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 14 08:48:56 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 14 Nov 2015 13:48:56 +0000 Subject: [issue24821] The optimization of string search can cause pessimization In-Reply-To: <1438927886.02.0.407236930114.issue24821@psf.upfronthosting.co.za> Message-ID: <20151114134853.21873.73148@psf.io> Roundup Robot added the comment: New changeset 1412be96faf0 by Serhiy Storchaka in branch 'default': Issue #24821: Refactor STRINGLIB(fastsearch_memchr_1char) and split it on https://hg.python.org/cpython/rev/1412be96faf0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 14 08:54:21 2015 From: report at bugs.python.org (Alex Gaynor) Date: Sat, 14 Nov 2015 13:54:21 +0000 Subject: [issue25569] Memory leak in SSLSocket.getpeercert() In-Reply-To: <1446840481.06.0.811345685129.issue25569@psf.upfronthosting.co.za> Message-ID: <1447509261.54.0.183005928097.issue25569@psf.upfronthosting.co.za> Alex Gaynor added the comment: fixed ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 14 08:55:18 2015 From: report at bugs.python.org (Alex Gaynor) Date: Sat, 14 Nov 2015 13:55:18 +0000 Subject: [issue25578] Memory leak in SSLSocket.getpeercert() with 0-length AIA extension In-Reply-To: <1446910116.69.0.509897683055.issue25578@psf.upfronthosting.co.za> Message-ID: <1447509318.94.0.341298410328.issue25578@psf.upfronthosting.co.za> Changes by Alex Gaynor : ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 14 09:10:59 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 14 Nov 2015 14:10:59 +0000 Subject: [issue24821] The optimization of string search can cause pessimization In-Reply-To: <1438927886.02.0.407236930114.issue24821@psf.upfronthosting.co.za> Message-ID: <1447510259.26.0.450784704309.issue24821@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > Could you please push this part of the change? It looks good to me. Done. The patch that make an optimization now looks much simpler. > The C library provides a wmemchr() function which can be used to search for a wchar_t character inside a wchar_t* string. Yes, I know. But this is C99 function, hence we should add configure test for it, and I don't know if it exists on Windows. I did not test its performance. > Did you try to not use memchr() but a simple C loop for UCS-2 and UCS-4? A simple C loop is 25-50% slower. My patch tries to use memchr(), but if it founds false positive, runs a simple C loop for limited length. This makes a performance only insignificantly worse in the case of few false positives, but makes it much better in cases of often or grouped together false positives. The common case when there are no false positives is not affected. MEMCHR_CUT_OFF is heuristic parameter. It is equal to the number of characters for which memchr()/memrchr() and a simple loop work the same time. On my machine it is 10-15 for UCS1 and 20-50 for UCS2 and UCS4 (depending on direction and character width). ---------- Added file: http://bugs.python.org/file41040/find_char_false_positives.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 14 09:25:58 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 14 Nov 2015 14:25:58 +0000 Subject: [issue25168] test_datetime.test_strptime() random failures on "s390x SLES" buildbots In-Reply-To: <1442584249.02.0.854297601638.issue25168@psf.upfronthosting.co.za> Message-ID: <1447511158.95.0.378015134182.issue25168@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +David.Edelsohn _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 14 09:26:11 2015 From: report at bugs.python.org (Robin Roth) Date: Sat, 14 Nov 2015 14:26:11 +0000 Subject: [issue2466] os.path.ismount doesn't work for mounts the user doesn't have permission to see In-Reply-To: <1206293428.96.0.660613140218.issue2466@psf.upfronthosting.co.za> Message-ID: <1447511171.68.0.588046150002.issue2466@psf.upfronthosting.co.za> Robin Roth added the comment: Antoine's suggestion does not work, because "dirname" does not cover enough cases (for example trailing slash, possibly more). As suggested by him I now use realpath (instead of abspath). I can't come up with a symlink-situation that is broken with the old code, but realpath is what "ismount" actually means. I also added a testcase that resembles the issue, i.e. it fails with the old code and passes with the fix. I mock the "Permission denied" by raising a generic OSError. Mocking can not resemble every real-life situation but by simulating all issues reporting and then fixing them, one should get a solid test coverage. I also took the liberty of minor cleanup in/around the functions changed, i.e. remove unused imports and remove single-use variables to make the code easier to read. Attached the updated patch. ---------- Added file: http://bugs.python.org/file41041/test_fix_ismount_directory_not_readable.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 14 11:26:55 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 14 Nov 2015 16:26:55 +0000 Subject: [issue25168] test_datetime.test_strptime() random failures on "s390x SLES" buildbots In-Reply-To: <1442584249.02.0.854297601638.issue25168@psf.upfronthosting.co.za> Message-ID: <1447518415.77.0.115365512281.issue25168@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thanks to Martin's research I have wrote a patch that resets a cache when timezone is changed. Martin's example in msg254643 works with this patch. ---------- keywords: +patch Added file: http://bugs.python.org/file41042/strptime_cache_timezone.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 14 12:45:43 2015 From: report at bugs.python.org (=?utf-8?b?SsOhY2h5bSBCYXJ2w61uZWs=?=) Date: Sat, 14 Nov 2015 17:45:43 +0000 Subject: [issue25625] "chdir" Contex manager for pathlib Message-ID: <1447523143.32.0.921942004004.issue25625@psf.upfronthosting.co.za> New submission from J?chym Barv?nek: I use this context manager in my code: @contextmanager def in_directory(path): pwd = str(Path().absolute()) if not path.is_dir(): path = path.parent os.chdir(str(path)) yield path.absolute() os.chdir(pwd) I thought it would be nice to have something like this in the pathlib as a method of Path library, I find it quite convenient, especially when dealing with subprocesses. ---------- components: Library (Lib) messages: 254664 nosy: J?chym Barv?nek priority: normal severity: normal status: open title: "chdir" Contex manager for pathlib type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 14 12:46:56 2015 From: report at bugs.python.org (SilentGhost) Date: Sat, 14 Nov 2015 17:46:56 +0000 Subject: [issue25625] "chdir" Contex manager for pathlib In-Reply-To: <1447523143.32.0.921942004004.issue25625@psf.upfronthosting.co.za> Message-ID: <1447523216.2.0.382148928742.issue25625@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- nosy: +pitrou versions: +Python 3.6 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 14 13:58:23 2015 From: report at bugs.python.org (desbma) Date: Sat, 14 Nov 2015 18:58:23 +0000 Subject: [issue25625] "chdir" Contex manager for pathlib In-Reply-To: <1447523143.32.0.921942004004.issue25625@psf.upfronthosting.co.za> Message-ID: <1447527503.2.0.866276605324.issue25625@psf.upfronthosting.co.za> desbma added the comment: I'm not a Python core developer, but a few thoughts: * this is not thread safe * subprocess.Popen already has a cwd parameter for similar purpose ---------- nosy: +desbma _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 14 14:09:39 2015 From: report at bugs.python.org (Mauro S. M. Rodrigues) Date: Sat, 14 Nov 2015 19:09:39 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <1447528179.2.0.986091342477.issue23883@psf.upfronthosting.co.za> Mauro S. M. Rodrigues added the comment: Yes, I'm, I have a commitment now but I'll submit a new version later today ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 14 14:11:06 2015 From: report at bugs.python.org (=?utf-8?b?SsOhY2h5bSBCYXJ2w61uZWs=?=) Date: Sat, 14 Nov 2015 19:11:06 +0000 Subject: [issue25625] "chdir" Contex manager for pathlib In-Reply-To: <1447527503.2.0.866276605324.issue25625@psf.upfronthosting.co.za> Message-ID: J?chym Barv?nek added the comment: I did not know about cwd for Popen. It seems like the better way to go. Thank you. 2015-11-14 19:58 GMT+01:00 desbma : > > desbma added the comment: > > I'm not a Python core developer, but a few thoughts: > * this is not thread safe > * subprocess.Popen already has a cwd parameter for similar purpose > > ---------- > nosy: +desbma > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 14 14:24:42 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 14 Nov 2015 19:24:42 +0000 Subject: [issue25388] tokenizer crash/misbehavior -- heap use-after-free In-Reply-To: <1444706115.92.0.283351483962.issue25388@psf.upfronthosting.co.za> Message-ID: <1447529082.78.0.793337865473.issue25388@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 14 14:48:21 2015 From: report at bugs.python.org (Ben Cipollini) Date: Sat, 14 Nov 2015 19:48:21 +0000 Subject: [issue25626] Gzip fails for file over 2**32 bytes Message-ID: <1447530501.75.0.968129152166.issue25626@psf.upfronthosting.co.za> New submission from Ben Cipollini: Gzip fails when opening a file more than 2**32 bytes. This is a new issue in Python 3.5. We hit this opening large neuroimaging files from the Human Connectome Project. See https://github.com/nipy/nibabel/issues/362 for more details. When size is > 2**32, we get the following error on Python 3.5: /usr/lib/python3.5/gzip.py in read(self, size) 467 buf = self._fp.read(io.DEFAULT_BUFFER_SIZE) 468 --> 469 uncompress = self._decompressor.decompress(buf, size) 470 if self._decompressor.unconsumed_tail != b"": 471 self._fp.prepend(self._decompressor.unconsumed_tail) OverflowError: Python int too large for C unsigned int ---------- messages: 254668 nosy: Ben Cipollini priority: normal severity: normal status: open title: Gzip fails for file over 2**32 bytes type: crash versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 14 14:55:00 2015 From: report at bugs.python.org (Matthew Brett) Date: Sat, 14 Nov 2015 19:55:00 +0000 Subject: [issue25626] Gzip fails for file over 2**32 bytes In-Reply-To: <1447530501.75.0.968129152166.issue25626@psf.upfronthosting.co.za> Message-ID: <1447530900.48.0.145338055773.issue25626@psf.upfronthosting.co.za> Changes by Matthew Brett : ---------- nosy: +Matthew.Brett _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 14 15:00:46 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 14 Nov 2015 20:00:46 +0000 Subject: [issue25619] Exception AttributeError: "'NoneType'.... thrown on exit In-Reply-To: <1447441683.08.0.711928345113.issue25619@psf.upfronthosting.co.za> Message-ID: <1447531246.57.0.342471338616.issue25619@psf.upfronthosting.co.za> R. David Murray added the comment: Yes, well, that is part of the fragility of python2's shutdown garbage collection, and one of the reasons it got improved. Changing the name of a function can change the order things get retrieved from various internal dictionaries, because they are hash tables. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 14 15:16:04 2015 From: report at bugs.python.org (SilentGhost) Date: Sat, 14 Nov 2015 20:16:04 +0000 Subject: [issue25626] Gzip fails for file over 2**32 bytes In-Reply-To: <1447530501.75.0.968129152166.issue25626@psf.upfronthosting.co.za> Message-ID: <1447532164.83.0.813840238436.issue25626@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- components: +Library (Lib) nosy: +nadeem.vawda, twouters versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 14 16:13:32 2015 From: report at bugs.python.org (Bernd Dietzel) Date: Sat, 14 Nov 2015 21:13:32 +0000 Subject: [issue25627] distutils : file "bdist_rpm.py" allows Shell injection in "name Message-ID: <1447535612.69.0.122030151224.issue25627@psf.upfronthosting.co.za> New submission from Bernd Dietzel: https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1514183 File : /usr/lib/python2.7/distutils/command/bdist_rpm.py Line 358 : This line in the code uses the depreached os.popen command, should be replaced with subprocess.Popen() : out = os.popen(q_cmd) Exploit demo : ============ 1) Download the setup.py script witch i attached 2) Create a test folder an put the setup.py script in this folder 3) cd to the test folder 4) python setup.py bdist_rpm 5) A xmessage window pops up as a proof of concept ---------- components: Distutils files: setup.py messages: 254670 nosy: TheRegRunner, dstufft, eric.araujo priority: normal severity: normal status: open title: distutils : file "bdist_rpm.py" allows Shell injection in "name type: security versions: Python 2.7 Added file: http://bugs.python.org/file41043/setup.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 14 16:16:14 2015 From: report at bugs.python.org (Bernd Dietzel) Date: Sat, 14 Nov 2015 21:16:14 +0000 Subject: [issue25627] distutils : file "bdist_rpm.py" allows Shell injection in "name" In-Reply-To: <1447535612.69.0.122030151224.issue25627@psf.upfronthosting.co.za> Message-ID: <1447535774.32.0.699086138306.issue25627@psf.upfronthosting.co.za> Changes by Bernd Dietzel : ---------- title: distutils : file "bdist_rpm.py" allows Shell injection in "name -> distutils : file "bdist_rpm.py" allows Shell injection in "name" _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 14 17:04:18 2015 From: report at bugs.python.org (SilentGhost) Date: Sat, 14 Nov 2015 22:04:18 +0000 Subject: [issue25627] distutils : file "bdist_rpm.py" allows Shell injection in "name" In-Reply-To: <1447535612.69.0.122030151224.issue25627@psf.upfronthosting.co.za> Message-ID: <1447538658.99.0.123320673574.issue25627@psf.upfronthosting.co.za> SilentGhost added the comment: This also seem to affect python 3, there os.popen implemented using subprocess.Popen, but that one is called with shell=True. So basically the string that's passed to os.popen should be quoted. The attached patch seem to be sufficient when applied on the default branch. ---------- keywords: +patch nosy: +SilentGhost Added file: http://bugs.python.org/file41044/issue25627.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 14 17:58:33 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 14 Nov 2015 22:58:33 +0000 Subject: [issue23914] pickle fails with SystemError In-Reply-To: <1428756762.72.0.925495036586.issue23914@psf.upfronthosting.co.za> Message-ID: <1447541913.01.0.1821975866.issue23914@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch that makes broken OBJ opcode to raise UnpicklingError instead of SystemError, improves some UnpicklingError messages, and adds tests for unpickling broken data. ---------- assignee: -> serhiy.storchaka keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file41045/unpickle_bad_stack.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 14 18:15:17 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 14 Nov 2015 23:15:17 +0000 Subject: [issue25578] Memory leak in SSLSocket.getpeercert() with 0-length AIA extension In-Reply-To: <1446910116.69.0.509897683055.issue25578@psf.upfronthosting.co.za> Message-ID: <20151114231514.18210.2953@psf.io> Roundup Robot added the comment: New changeset 79abea02a569 by Benjamin Peterson in branch '2.7': fix possible memory lea k in _get_aia_uri (closes #25578) https://hg.python.org/cpython/rev/79abea02a569 New changeset bddc5491d0fb by Benjamin Peterson in branch '3.4': fix possible memory lea k in _get_aia_uri (closes #25578) https://hg.python.org/cpython/rev/bddc5491d0fb New changeset 6c733337afae by Benjamin Peterson in branch '3.5': merge 3.4 (#25578) https://hg.python.org/cpython/rev/6c733337afae New changeset 858cb1538531 by Benjamin Peterson in branch 'default': merge 3.5 (#25578) https://hg.python.org/cpython/rev/858cb1538531 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 14 18:35:56 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 14 Nov 2015 23:35:56 +0000 Subject: [issue8728] 2.7 regression in httplib.py: AttributeError: 'NoneType' object has no attribute 'makefile' In-Reply-To: <1273960882.3.0.07398568579.issue8728@psf.upfronthosting.co.za> Message-ID: <1447544156.86.0.969972394977.issue8728@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- status: open -> pending type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 14 18:41:17 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 14 Nov 2015 23:41:17 +0000 Subject: [issue15504] pickle/cPickle saves invalid/incomplete data In-Reply-To: <1343663028.38.0.42350418133.issue15504@psf.upfronthosting.co.za> Message-ID: <1447544477.25.0.0612888112648.issue15504@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Since issue13555 is fixed, I think this issue is fixed too. ---------- nosy: +serhiy.storchaka status: open -> pending type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 14 18:47:13 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 14 Nov 2015 23:47:13 +0000 Subject: [issue18287] PyType_Ready() should sanity-check the tp_name field In-Reply-To: <1372000372.42.0.425313116494.issue18287@psf.upfronthosting.co.za> Message-ID: <1447544833.88.0.46346367056.issue18287@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- versions: +Python 3.5, Python 3.6 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 14 18:59:35 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 14 Nov 2015 23:59:35 +0000 Subject: [issue21134] Segfault when stringifying UnicodeEncodeError (or UnicodeDecodeError) created with __new__() In-Reply-To: <1396447837.72.0.201261233456.issue21134@psf.upfronthosting.co.za> Message-ID: <1447545575.67.0.141342785469.issue21134@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Do you have a patch Victor? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 14 19:56:52 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 15 Nov 2015 00:56:52 +0000 Subject: [issue20220] test_datetime, test_tarfile, test_strptime time zone failures In-Reply-To: <1389384273.4.0.330615086279.issue20220@psf.upfronthosting.co.za> Message-ID: <1447549012.67.0.861559418786.issue20220@psf.upfronthosting.co.za> Martin Panter added the comment: The problem is probably triggered by the test in test_imaplib which sets the timezone to ?STD-1DST?. It was added in revision 42b9d9d795f7, in 2012 for Python 3.3 only, which explains why we don?t have any trouble with Python 2. I am no expert on time zone settings, but this either looks like a bug or unfortunate quirk in the C library. I only have the Gnu library handy to play with at the moment. Using my demo C program, it looks like tzset() fails to update tzname if both (1) New York time is set rather than UTC and (2) the temporary TZ value did not include DST rules: $ sudo timedatectl status # Note UTC time zone Local time: Sun 2015-11-15 00:16:54 UTC Universal time: Sun 2015-11-15 00:16:54 UTC RTC time: Sun 2015-11-15 00:16:54 Time zone: UTC (UTC, +0000) Network time on: no NTP synchronized: no RTC in local TZ: no $ sudo timedatectl set-timezone America/New_York $ ./tz-quirk "STD-1DST" Initially: TZ= tzname={"GMT", "GMT"} After tzset(): TZ= tzname={"EST", "EDT"} Set TZ: TZ="STD-1DST" tzname={"STD", "DST"} Unset TZ: TZ= tzname={"STD", "DST"} If you include DST rules in the TZ value, the problem does not occur. Maybe this could be a good enough workaround: $ ./tz-quirk "STD-1DST,M3.2.0,M11.1.0" Initially: TZ= tzname={"GMT", "GMT"} After tzset(): TZ= tzname={"EST", "EDT"} Set TZ: TZ="STD-1DST,M3.2.0,M11.1.0" tzname={"STD", "DST"} Unset TZ: TZ= tzname={"EST", "EDT"} $ sudo timedatectl set-timezone UTC # Restore my setting $ pacman -Qo /lib/libc.so.6 /usr/lib/libc.so.6 is owned by glibc 2.22-3 ---------- components: +Tests nosy: +martin.panter title: TarFile.list() outputs wrong time -> test_datetime, test_tarfile, test_strptime time zone failures versions: +Python 3.6 Added file: http://bugs.python.org/file41046/tz-quirk.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 14 19:58:41 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 15 Nov 2015 00:58:41 +0000 Subject: [issue25168] test_datetime.test_strptime() random failures on "s390x SLES" buildbots In-Reply-To: <1442584249.02.0.854297601638.issue25168@psf.upfronthosting.co.za> Message-ID: <1447549121.47.0.020973136611.issue25168@psf.upfronthosting.co.za> Martin Panter added the comment: I just discovered Issue 20220 about a similar story with a tarfile test case. It looks like this is caused by the same underlying C library quirk, so I am closing this as a duplicate. Using Antoine?s reproducer there I triggered both this datetime failure and the tarfile failure: TZ='America/New_York' ./python -m test -v test_imaplib test_tarfile test_datetime Also Serhiy I discovered Issue 6478 about the strptime() cache which has patches trying to do a similar thing to your patch. ---------- resolution: -> duplicate status: open -> closed superseder: -> test_datetime, test_tarfile, test_strptime time zone failures _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 14 20:22:27 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 15 Nov 2015 01:22:27 +0000 Subject: [issue20220] test_datetime, test_tarfile, test_strptime time zone failures In-Reply-To: <1389384273.4.0.330615086279.issue20220@psf.upfronthosting.co.za> Message-ID: <1447550547.92.0.730388344206.issue20220@psf.upfronthosting.co.za> Martin Panter added the comment: I added test_strptime to the title due to Issue 22795, but Antoine?s trick doesn?t seem to help reproduce it. In this run all three failed: [158/390] test_imaplib [171/390] test_strptime ====================================================================== ERROR: test_bad_timezone (test.test_strptime.StrptimeTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/dje/cpython-buildarea/3.4.edelsohn-rhel-z/build/Lib/test/test_strptime.py", line 332, in test_bad_timezone tz_value = _strptime._strptime_time(tz_name, "%Z")[8] File "/home/dje/cpython-buildarea/3.4.edelsohn-rhel-z/build/Lib/_strptime.py", line 494, in _strptime_time tt = _strptime(data_string, format)[0] File "/home/dje/cpython-buildarea/3.4.edelsohn-rhel-z/build/Lib/_strptime.py", line 337, in _strptime (data_string, format)) ValueError: time data 'STD' does not match format '%Z' ====================================================================== ERROR: test_timezone (test.test_strptime.StrptimeTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/dje/cpython-buildarea/3.4.edelsohn-rhel-z/build/Lib/test/test_strptime.py", line 310, in test_timezone strp_output = _strptime._strptime_time(strf_output, "%Z") File "/home/dje/cpython-buildarea/3.4.edelsohn-rhel-z/build/Lib/_strptime.py", line 494, in _strptime_time tt = _strptime(data_string, format)[0] File "/home/dje/cpython-buildarea/3.4.edelsohn-rhel-z/build/Lib/_strptime.py", line 337, in _strptime (data_string, format)) ValueError: time data 'STD' does not match format '%Z' ---------------------------------------------------------------------- Ran 48 tests in 0.067s FAILED (errors=2) test test_strptime failed [192/390/1] test_tarfile test_list_command_verbose (test.test_tarfile.CommandLineTest) ... FAIL [389/390/2] test_datetime test_strptime (test.datetimetester.TestDateTime_Fast) ... ERROR test_strptime (test.datetimetester.TestDateTimeTZ_Fast) ... ERROR test_strptime (test.datetimetester.TestSubclassDateTime_Fast) ... ERROR Here is a patch that adds DST rules. I think it should work around the problem at least for test_datetime and test_tarfile. ---------- keywords: +patch Added file: http://bugs.python.org/file41047/tz-rules.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 15 02:21:37 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 15 Nov 2015 07:21:37 +0000 Subject: [issue20220] test_datetime, test_tarfile, test_strptime time zone failures In-Reply-To: <1389384273.4.0.330615086279.issue20220@psf.upfronthosting.co.za> Message-ID: <1447572097.77.0.188696680831.issue20220@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. ---------- assignee: -> martin.panter stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 15 03:23:44 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 15 Nov 2015 08:23:44 +0000 Subject: [issue15721] PEP 3121, 384 Refactoring applied to tkinter module In-Reply-To: <1345287224.98.0.204885883161.issue15721@psf.upfronthosting.co.za> Message-ID: <1447575824.15.0.0580727044231.issue15721@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This change causes a crash when create instances of _tkinter classes (issue23815). If this will not be fixed I suggest to revert the patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 15 03:28:13 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 15 Nov 2015 08:28:13 +0000 Subject: [issue23815] Segmentation fault when create _tkinter objects In-Reply-To: <1427745415.01.0.962782500028.issue23815@psf.upfronthosting.co.za> Message-ID: <1447576093.43.0.186657919846.issue23815@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Before issue15721 the tp_new was NULL, and this prevented from creating instances. After issue15721 the tp_new is inherited from object. An instance is created, but all internal pointers are NULLs. Following repr() dereferences NULL. ---------- versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 15 04:01:39 2015 From: report at bugs.python.org (irdb) Date: Sun, 15 Nov 2015 09:01:39 +0000 Subject: [issue1794] Hot keys must work in any keyboard layout In-Reply-To: <1200070698.92.0.206138884505.issue1794@psf.upfronthosting.co.za> Message-ID: <1447578099.48.0.746012018461.issue1794@psf.upfronthosting.co.za> Changes by irdb : ---------- nosy: +irdb _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 15 04:15:44 2015 From: report at bugs.python.org (Ethan Furman) Date: Sun, 15 Nov 2015 09:15:44 +0000 Subject: [issue25594] enum instance attribute access possible In-Reply-To: <1447144067.5.0.526378354242.issue25594@psf.upfronthosting.co.za> Message-ID: <1447578944.12.0.0442011861901.issue25594@psf.upfronthosting.co.za> Changes by Ethan Furman : Added file: http://bugs.python.org/file41048/issue25594.stoneleaf.03.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 15 05:36:49 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 15 Nov 2015 10:36:49 +0000 Subject: [issue20220] test_datetime, test_tarfile, test_strptime time zone failures In-Reply-To: <1389384273.4.0.330615086279.issue20220@psf.upfronthosting.co.za> Message-ID: <1447583809.23.0.0464421693237.issue20220@psf.upfronthosting.co.za> Martin Panter added the comment: I discovered a way to trigger the test_strptime failure. In 3.6, if I rename the CacheTests class to ZCacheTests in in test_strptime.py, it seems to stop it running before the StrptimeTests class. Then you can trigger the failure it with: ./python -m test -u all -v test_{urllibnet,imaplib,strptime} 1. test_urllibnet loads the _strptime module and initializes the cache with the normal timezone info 2. test_imaplib temporarily sets TZ=STD-1DST, triggering the glibc bug 3. test_strptime tries parsing "STD" using the original time zone settings and fails You have to stop CacheTests running before step 3, because it resets the _strptime cache. Anyway, I am now fairly confident my patch will avoid the test_strptime failure as well, so I think it is worthwhile committing it. But I guess a bug should be reported to the glibc people too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 15 05:40:13 2015 From: report at bugs.python.org (Dave Jones) Date: Sun, 15 Nov 2015 10:40:13 +0000 Subject: [issue25615] Document unsorted behaviour of glob.glob In-Reply-To: <1447410381.17.0.519847126493.issue25615@psf.upfronthosting.co.za> Message-ID: <1447584013.67.0.954507814465.issue25615@psf.upfronthosting.co.za> Dave Jones added the comment: Sounds good; the patch seems to apply cleanly to checkouts of 2.7, 3.4, and 3.5 so I'm assuming I don't need to do anything else? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 15 06:13:22 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 15 Nov 2015 11:13:22 +0000 Subject: [issue25626] Gzip fails for file over 2**32 bytes In-Reply-To: <1447530501.75.0.968129152166.issue25626@psf.upfronthosting.co.za> Message-ID: <1447586002.89.0.504314186433.issue25626@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks for the report. Can you confirm if this demo illustrates your problem? For me, I only have 2 GiB of memory so I get a MemoryError, which seems reasonable for my situation. from gzip import GzipFile from io import BytesIO file = BytesIO() writer = GzipFile(fileobj=file, mode="wb") writer.write(b"data") writer.close() file.seek(0) reader = GzipFile(fileobj=file, mode="rb") data = reader.read(2**32) # Ideally this should return b"data" Assuming that triggers the OverflowError, then the heart of the problem is that the zlib.decompressobj.decompress() method does not accept such large numbers for the length limit: >>> import zlib >>> decompressor = zlib.decompressobj(wbits=16 + 15) >>> decompressor.decompress(file.getvalue(), 2**32) Traceback (most recent call last): File "", line 1, in OverflowError: Python int too large for C unsigned int I think the ideal fix would be to cap the limit at 2**32 - 1 in the zlib library. Would this be okay for a 3.5.1 bug fix release, or would it be considered a feature change? Failing that, another option would be to cap the limit in the gzip library, and just document the zlib limitation. I already have a patch in Issue 23200 documenting another quirk when max_length=0. The same problem may also apply to the LZMA and bzip2 modules; I need to check. ---------- keywords: +3.5regression nosy: +martin.panter type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 15 06:19:39 2015 From: report at bugs.python.org (SilentGhost) Date: Sun, 15 Nov 2015 11:19:39 +0000 Subject: [issue25594] enum instance attribute access possible In-Reply-To: <1447144067.5.0.526378354242.issue25594@psf.upfronthosting.co.za> Message-ID: <1447586379.5.0.307531143255.issue25594@psf.upfronthosting.co.za> SilentGhost added the comment: No further comments re the latest patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 15 07:20:34 2015 From: report at bugs.python.org (Ben Cipollini) Date: Sun, 15 Nov 2015 12:20:34 +0000 Subject: [issue25626] Gzip fails for file over 2**32 bytes In-Reply-To: <1447530501.75.0.968129152166.issue25626@psf.upfronthosting.co.za> Message-ID: <1447590034.55.0.510716861804.issue25626@psf.upfronthosting.co.za> Ben Cipollini added the comment: @Martin: yes, that reproduces the problem. >I think the ideal fix would be to cap the limit at 2**32 - 1 in the zlib library. If this cap is implemented, is there any workaround how we can efficiently open gzipped files over 4GB? Such files exist, exist in high-priority, government-funded datasets, and neuroinformatics in Python requires a way to open them efficiently. >another option would be to cap the limit in the gzip library Again, these limitations are new in Python 3.5 and currently block us from using Python 3.5 to run neuroinformatics efficiently. Is there any chance to revert this new behavior, or any known memory-efficient workaround? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 15 07:30:29 2015 From: report at bugs.python.org (Ateik Al-Zehla) Date: Sun, 15 Nov 2015 12:30:29 +0000 Subject: [issue25251] Unknown MS Compiler version 1900 In-Reply-To: <1443392264.43.0.443478210283.issue25251@psf.upfronthosting.co.za> Message-ID: <1447590629.53.0.0908441405229.issue25251@psf.upfronthosting.co.za> Ateik Al-Zehla added the comment: how to apply patch file : patch.diff ? plz help ---------- nosy: +Ateik Al-Zehla _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 15 14:06:56 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 15 Nov 2015 19:06:56 +0000 Subject: [issue25615] Document unsorted behaviour of glob.glob In-Reply-To: <1447410381.17.0.519847126493.issue25615@psf.upfronthosting.co.za> Message-ID: <1447614416.56.0.364747995229.issue25615@psf.upfronthosting.co.za> Raymond Hettinger added the comment: +1 for the doc update. For future reference, the doc patches are much easier to review if you don't rewrap the text (we can easily do that part before applying the patch). ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 15 14:21:13 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 15 Nov 2015 19:21:13 +0000 Subject: [issue25628] Make namedtuple "verbose" and "renanme" parameters into keyword only arguments Message-ID: <1447615273.45.0.0364929463097.issue25628@psf.upfronthosting.co.za> New submission from Raymond Hettinger: This is a usability and readability improvement made possible by Python 3's keyword only arguments. Usability is improved by getting a much less confusing response from the following mistake: namedtuple('Point', 'x', 'y') ^--- invisibly goes to the "verbose" argument The "verbose" argument is normally used interactively (much like help() and dis()) or is used with a keyword argument, so it is unlikely that existing scripts will be much affected. For the rare cases, the remediation is simple and improves code clarity (replacing "True" with "verbose=True"). ---------- components: Library (Lib) files: namedtuple_keywords.diff keywords: patch messages: 254689 nosy: rhettinger priority: normal severity: normal status: open title: Make namedtuple "verbose" and "renanme" parameters into keyword only arguments type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file41049/namedtuple_keywords.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 15 14:26:15 2015 From: report at bugs.python.org (Dave Jones) Date: Sun, 15 Nov 2015 19:26:15 +0000 Subject: [issue25615] Document unsorted behaviour of glob.glob In-Reply-To: <1447410381.17.0.519847126493.issue25615@psf.upfronthosting.co.za> Message-ID: <1447615575.79.0.0841160087894.issue25615@psf.upfronthosting.co.za> Dave Jones added the comment: Ah, sorry about that - force of habit. I did wonder if it was preferable to have a nicely wrapped patch, or to have a clean diff but obviously figured wrong! I'll know for future :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 15 14:35:00 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 15 Nov 2015 19:35:00 +0000 Subject: [issue25628] Make namedtuple "verbose" and "rename" parameters into keyword only arguments In-Reply-To: <1447615273.45.0.0364929463097.issue25628@psf.upfronthosting.co.za> Message-ID: <1447616100.23.0.115932117158.issue25628@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- title: Make namedtuple "verbose" and "renanme" parameters into keyword only arguments -> Make namedtuple "verbose" and "rename" parameters into keyword only arguments _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 15 14:36:55 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 15 Nov 2015 19:36:55 +0000 Subject: [issue25627] distutils : file "bdist_rpm.py" allows Shell injection in "name" In-Reply-To: <1447535612.69.0.122030151224.issue25627@psf.upfronthosting.co.za> Message-ID: <1447616215.25.0.556161643247.issue25627@psf.upfronthosting.co.za> R. David Murray added the comment: Since setup.py can run arbitrary python code, it is pointless to worry about this from a security perspective. The change is otherwise not a bad idea, though, since it avoids filename quoting problems. Is there any chance this would break existing setup.py files that do their own quoting of the filenames to get around the quoting problem? I'm guessing not since the filename gets used in multiple contexts, and the other contexts probably require an unquoted filename. Which would make this a simple bug fix against bdist_rpm. However, why not convert to using Popen? ---------- nosy: +r.david.murray type: security -> behavior versions: +Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 15 14:37:31 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 15 Nov 2015 19:37:31 +0000 Subject: [issue25627] distutils : file "bdist_rpm.py" does not quote filenames when executing the rpm command In-Reply-To: <1447535612.69.0.122030151224.issue25627@psf.upfronthosting.co.za> Message-ID: <1447616251.31.0.526164275331.issue25627@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- title: distutils : file "bdist_rpm.py" allows Shell injection in "name" -> distutils : file "bdist_rpm.py" does not quote filenames when executing the rpm command _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 15 15:17:47 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 15 Nov 2015 20:17:47 +0000 Subject: [issue25629] Move set fill/used updates out of set_insert_clean() Message-ID: <1447618667.35.0.632647105996.issue25629@psf.upfronthosting.co.za> New submission from Raymond Hettinger: Will need to update the comment block over set_insert_clean() as well. ---------- components: Interpreter Core files: set_faster_resize2.diff keywords: patch messages: 254692 nosy: rhettinger priority: normal severity: normal stage: patch review status: open title: Move set fill/used updates out of set_insert_clean() type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file41050/set_faster_resize2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 15 15:25:03 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 15 Nov 2015 20:25:03 +0000 Subject: [issue25628] Make namedtuple "verbose" and "rename" parameters into keyword only arguments In-Reply-To: <1447615273.45.0.0364929463097.issue25628@psf.upfronthosting.co.za> Message-ID: <1447619103.93.0.0800894636916.issue25628@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I like the idea. But this is backward incompatible change. I would first add a warning. Here is a patch. Yes, the code looks a little cumbersome, but this is only for one or two releases. ---------- nosy: +serhiy.storchaka stage: -> patch review Added file: http://bugs.python.org/file41051/namedtuple_keywords_deprecate.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 15 15:48:48 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 15 Nov 2015 20:48:48 +0000 Subject: [issue16394] Reducing tee() memory footprint In-Reply-To: <1351955719.4.0.453680036148.issue16394@psf.upfronthosting.co.za> Message-ID: <1447620528.47.0.797447743586.issue16394@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Unlike the other "equivalents" in the docs, this one is further away from the actual implementation. So, I think I should add a clarification that the example code is a "rough logical equivalent" but that actual implementation may have shared queues (Jython, PyPy, and IronPython are free to have their own implementation choices). ---------- priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 15 15:50:15 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 15 Nov 2015 20:50:15 +0000 Subject: [issue25609] Add a ContextManager ABC and type In-Reply-To: <1447355679.68.0.225089426373.issue25609@psf.upfronthosting.co.za> Message-ID: <1447620615.62.0.807744038888.issue25609@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 15 15:56:10 2015 From: report at bugs.python.org (STINNER Victor) Date: Sun, 15 Nov 2015 20:56:10 +0000 Subject: [issue21134] Segfault when stringifying UnicodeEncodeError (or UnicodeDecodeError) created with __new__() In-Reply-To: <1396447837.72.0.201261233456.issue21134@psf.upfronthosting.co.za> Message-ID: <1447620970.89.0.513454070007.issue21134@psf.upfronthosting.co.za> STINNER Victor added the comment: > Do you have a patch Victor? Nope. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 15 16:11:42 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 15 Nov 2015 21:11:42 +0000 Subject: [issue25609] Add a ContextManager ABC and type In-Reply-To: <1447355679.68.0.225089426373.issue25609@psf.upfronthosting.co.za> Message-ID: <1447621902.9.0.678711568332.issue25609@psf.upfronthosting.co.za> Raymond Hettinger added the comment: -0 on this one. This is slightly more useful than the other "one-trick-ponies" like Container, Hashable, and Iterable. Those each provide some "recognition" capabilities using isinstance() but don't provide any useful "mixin" capabilities. In practice, I'm not seeing the "recognition" capabilities being used (i.e. no one is using "if isinstance(obj, Container)" in real code). So adding another one-trick pony that won't get used is a bit of a waste. Also, this would add more clutter to the collections ABCs, obscuring the ones that actually have added value (i.e. MutableMapping has been a great success). The collections.abc module has become a dumping ground for ABCs that that don't really have anything to do with collections and aren't useful for day-to-day development (Awaitable, Coroutine, AsyncIterable, AsyncIterator, etc). One idea is to have a separate module of generic recognition abcs that would be used in much the same way as the old types module. Otherwise, the collections.abc module will continue unabated growth away from its original purpose as a small group of powerful mixin classes (Sequence, MutableSequence, Set, MutableSet, Mapping, MutableMapping, and the dict views). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 15 16:52:49 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 15 Nov 2015 21:52:49 +0000 Subject: [issue25616] Extract OrderedDict tests into separate file In-Reply-To: <1447419681.57.0.354121086978.issue25616@psf.upfronthosting.co.za> Message-ID: <1447624369.75.0.736047023926.issue25616@psf.upfronthosting.co.za> Raymond Hettinger added the comment: If it helps with all the great work you're doing, go ahead and move the OD tests out to a separate file. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 15 16:55:37 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 15 Nov 2015 21:55:37 +0000 Subject: [issue25611] test_deque failure on Gentoo and OpenIndiana buildbots on 2.7 In-Reply-To: <1447357055.57.0.0198756025718.issue25611@psf.upfronthosting.co.za> Message-ID: <1447624537.64.0.114709529597.issue25611@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 15 17:29:46 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 15 Nov 2015 22:29:46 +0000 Subject: [issue25623] Keep the link to Python implementation of OrderedDict In-Reply-To: <1447488768.43.0.519685796607.issue25623@psf.upfronthosting.co.za> Message-ID: <1447626586.84.0.571978665604.issue25623@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I think we should stick with fixing bugs as found (even if that process spills into 3.5.2). The current tests do a good job of making sure the basic functionality is in place and there has been use in the field. Also, you've already done a good job fixing a few of the most egregious bugs. Likewise should have an aversion to temporary APIs like _collections and to API changes between micro releases. In general, this strategy is likely to cause more pain than it alleviates. So, put me down for -1 on this one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 15 17:30:50 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 15 Nov 2015 22:30:50 +0000 Subject: [issue24928] mock.patch.dict spoils order of items in collections.OrderedDict In-Reply-To: <1440443995.19.0.0795335566212.issue24928@psf.upfronthosting.co.za> Message-ID: <1447626650.09.0.0340309268829.issue24928@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> michael.foord _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 15 17:36:35 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Sun, 15 Nov 2015 22:36:35 +0000 Subject: [issue23564] Patch fixing sanity check for ordered fd sequence in _posixsubprocess.c In-Reply-To: <1425315012.54.0.714244886784.issue23564@psf.upfronthosting.co.za> Message-ID: <1447626995.37.0.637843867209.issue23564@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Hisham, could you sign the Python contributor agreement? https://www.python.org/psf/contrib/contrib-form/ thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 15 17:42:28 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Sun, 15 Nov 2015 22:42:28 +0000 Subject: [issue17131] subprocess.Popen.terminate can raise exception on Posix In-Reply-To: <1360058099.4.0.320628892834.issue17131@psf.upfronthosting.co.za> Message-ID: <1447627348.1.0.53469656571.issue17131@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- resolution: -> duplicate status: open -> closed superseder: -> subprocess.Popen.send_signal doesn't check whether the process has terminated _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 15 17:42:57 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Sun, 15 Nov 2015 22:42:57 +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: <1447627377.18.0.503493820491.issue6973@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- assignee: -> gregory.p.smith nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 15 18:22:18 2015 From: report at bugs.python.org (=?utf-8?q?Pawe=C5=82_Krawczyk?=) Date: Sun, 15 Nov 2015 23:22:18 +0000 Subject: [issue25630] SIGSEGV in os.putenv() Message-ID: <1447629738.32.0.300278557124.issue25630@psf.upfronthosting.co.za> New submission from Pawe? Krawczyk: A numerical value argument of the os.putenv() call causes my python3.5 to crash with SIGSEGV, for example: Python 3.5.0+ (default, Oct 11 2015, 09:05:38) [GCC 5.2.1 20151010] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.putenv('AAA', 1) Segmentation fault (core dumped) While numerical 1 (one) is not a valid argument for the function which expects a string as value, it shouldn't crash but rather throw an exception. This seems to be the behaviour in python3.4: Python 3.4.3 (default, Oct 14 2015, 20:28:29) [GCC 4.8.4] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.putenv('AAA', 1) Traceback (most recent call last): File "", line 1, in TypeError: Can't convert 'int' object to str implicitly >>> I can provide a strace/ltrace/core dump but it's huge and I'm not sure if it's necessary taking into account that this issue is trivial to reproduce. ---------- components: Library (Lib) messages: 254700 nosy: Pawe? Krawczyk priority: normal severity: normal status: open title: SIGSEGV in os.putenv() type: crash versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 15 19:31:08 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 16 Nov 2015 00:31:08 +0000 Subject: [issue23564] Patch fixing sanity check for ordered fd sequence in _posixsubprocess.c In-Reply-To: <1425315012.54.0.714244886784.issue23564@psf.upfronthosting.co.za> Message-ID: <1447633868.04.0.764843623646.issue23564@psf.upfronthosting.co.za> Martin Panter added the comment: FWIW I think this patch is trivial enough not to need an agreement. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 15 19:59:01 2015 From: report at bugs.python.org (Emanuel Barry) Date: Mon, 16 Nov 2015 00:59:01 +0000 Subject: [issue25623] Keep the link to Python implementation of OrderedDict In-Reply-To: <1447488768.43.0.519685796607.issue25623@psf.upfronthosting.co.za> Message-ID: <1447635541.39.0.207043592341.issue25623@psf.upfronthosting.co.za> Emanuel Barry added the comment: I would personally suggest a more permanent and accessible way, in the way the decimal module handles it. I'd add a '_pycollections' module holding the pure Python implementations of OrderedDict and _count_elements, then have the collections package import them if the C accelerators don't work. While the '_pydecimal' module is not guaranteed to remain across versions, successfully importing it means that you are guaranteed to use the pure Python version of it. In the same direction, successfully importing OrderedDict from _pycollections would guarantee that you're using the pure Python version of it. This would have the side-effect of allowing people relying on the pure Python implementation details to use them (see #25315). ---------- nosy: +ebarry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 15 20:06:05 2015 From: report at bugs.python.org (Itai Bar-Natan) Date: Mon, 16 Nov 2015 01:06:05 +0000 Subject: [issue25631] Segmentation fault with invalid Unicode command-line arguments in embedded Python Message-ID: <1447635965.36.0.72529883046.issue25631@psf.upfronthosting.co.za> New submission from Itai Bar-Natan: The following embedded application, which calls Py_Main with a "-W X" argument where X is not a valid Unicode string, returns a segmentation fault: ``` #include "Python.h" main() { wchar_t *invalid_str; invalid_str = malloc(2*sizeof(wchar_t)); invalid_str[0] = 0x110000; invalid_str[1] = 0; wchar_t *argv[4] = {L"embedded-python", L"-W", invalid_str, NULL}; Py_Main(3, argv); } ``` This segmentation fault is present in Python 3.4, 3.5, and the latest development branch I downloaded, but is not present in Python 3.2. This program is obviously invalid and it may be reasonable to emit a fatal error in this situation, but it should not give a segmentation fault. I believe the issue is that this codes leads to exception being thrown before exceptions are initialized, and more specifically, a call to PyExceptionClass_Check() within PyErr_Object() reads a NULL pointer. I haven't tested this but I expect that this problem would not appear when calling Python directly since Python sanitizes the command line arguments from main(). Nonetheless even here the possibility of other exceptions being raised early in the initialization sequence remains a potential problem. ---------- components: Interpreter Core messages: 254703 nosy: itaibn priority: normal severity: normal status: open title: Segmentation fault with invalid Unicode command-line arguments in embedded Python type: crash versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 15 21:32:00 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 16 Nov 2015 02:32:00 +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: <20151116023155.88490.56477@psf.io> Roundup Robot added the comment: New changeset 6bd3c8623bb2 by Gregory P. Smith in branch '3.4': Fix issue #6973: When we know a subprocess.Popen process has died, do https://hg.python.org/cpython/rev/6bd3c8623bb2 New changeset bc907c76f054 by Gregory P. Smith in branch '3.5': Fix issue #6973: When we know a subprocess.Popen process has died, do https://hg.python.org/cpython/rev/bc907c76f054 New changeset e51c46d12ec1 by Gregory P. Smith in branch 'default': Fix issue #6973: When we know a subprocess.Popen process has died, do https://hg.python.org/cpython/rev/e51c46d12ec1 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 15 21:35:11 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 16 Nov 2015 02:35:11 +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: <1447641311.1.0.389987470901.issue6973@psf.upfronthosting.co.za> Gregory P. Smith added the comment: I chose to go with the "there should not be an error" approach similar to how Python deals with multiple file closes. Both are technically programming errors but the point of Python is make life easier. Reasoning? I don't want someone to ever think they could depend on getting an exception from send_signal/terminate/kill in this "process has already died and someone has called wait or poll to get its return code" situation as that is unreliable and potentially impacts other innocent processes. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 15 22:12:44 2015 From: report at bugs.python.org (Mauro S. M. Rodrigues) Date: Mon, 16 Nov 2015 03:12:44 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <1447643564.78.0.216442161306.issue23883@psf.upfronthosting.co.za> Mauro S. M. Rodrigues added the comment: New version. ---------- Added file: http://bugs.python.org/file41052/issue23883_fileinput.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 15 22:13:10 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 16 Nov 2015 03:13:10 +0000 Subject: [issue25623] Keep the link to Python implementation of OrderedDict In-Reply-To: <1447488768.43.0.519685796607.issue25623@psf.upfronthosting.co.za> Message-ID: <1447643590.51.0.984873456958.issue25623@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > This would have the side-effect of allowing people relying > on the pure Python implementation details to use them Right. That's why we don't want to do this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 15 22:37:35 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 16 Nov 2015 03:37:35 +0000 Subject: [issue19081] zipimport behaves badly when the zip file changes while the process is running In-Reply-To: <1379995203.41.0.89812771706.issue19081@psf.upfronthosting.co.za> Message-ID: <1447645055.29.0.0555541809671.issue19081@psf.upfronthosting.co.za> Gregory P. Smith added the comment: I'm unassigning as i won't be figuring out how to hackishly fix this again. The best solution is a complete rewrite of zipimport. this remains a known issue: if you use zipimport, do not allow the zip file to change out from underneath your running process or you will have "fun". ---------- assignee: gregory.p.smith -> priority: high -> normal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 00:11:16 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 16 Nov 2015 05:11:16 +0000 Subject: [issue23564] Patch fixing sanity check for ordered fd sequence in _posixsubprocess.c In-Reply-To: <1425315012.54.0.714244886784.issue23564@psf.upfronthosting.co.za> Message-ID: <1447650676.75.0.613516100702.issue23564@psf.upfronthosting.co.za> Gregory P. Smith added the comment: heh, you're right. it's a trivial obvious fix for the mistake in the existing implementation. writing a test and committing. the other option would be to get rid of the sanity check entirely or change it not to use the odd "require a sorted list" code. but i like the sanity check and refactoring it to not require a sorted list within this code path would be complicated. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 00:29:54 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 16 Nov 2015 05:29:54 +0000 Subject: [issue23564] Patch fixing sanity check for ordered fd sequence in _posixsubprocess.c In-Reply-To: <1425315012.54.0.714244886784.issue23564@psf.upfronthosting.co.za> Message-ID: <20151116052951.120366.79820@psf.io> Roundup Robot added the comment: New changeset 55f7a99a5433 by Gregory P. Smith in branch '3.5': Fixes #23564: Fix a partially broken sanity check in the _posixsubprocess https://hg.python.org/cpython/rev/55f7a99a5433 New changeset 97e2a6810f7f by Gregory P. Smith in branch 'default': Fixes #23564: Fix a partially broken sanity check in the _posixsubprocess https://hg.python.org/cpython/rev/97e2a6810f7f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 00:30:44 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 16 Nov 2015 05:30:44 +0000 Subject: [issue23564] Patch fixing sanity check for ordered fd sequence in _posixsubprocess.c In-Reply-To: <1425315012.54.0.714244886784.issue23564@psf.upfronthosting.co.za> Message-ID: <1447651844.39.0.537809226515.issue23564@psf.upfronthosting.co.za> Gregory P. Smith added the comment: I didn't bother adding the fix to 3.4, it isn't high value. ---------- resolution: -> fixed status: open -> closed versions: +Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 00:37:09 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 16 Nov 2015 05:37:09 +0000 Subject: [issue25628] Make namedtuple "verbose" and "rename" parameters into keyword only arguments In-Reply-To: <1447615273.45.0.0364929463097.issue25628@psf.upfronthosting.co.za> Message-ID: <1447652229.0.0.613990496909.issue25628@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I don't think a warning is necessary because of what "verbose" does. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 00:55:22 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 16 Nov 2015 05:55:22 +0000 Subject: [issue25611] test_deque failure on Gentoo and OpenIndiana buildbots on 2.7 In-Reply-To: <1447357055.57.0.0198756025718.issue25611@psf.upfronthosting.co.za> Message-ID: <1447653322.27.0.265987031239.issue25611@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I believe this was fixed by changesets a2a518b6ded4 and d920b09d22ce . The buildbots show green for the latest build. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 00:58:19 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 16 Nov 2015 05:58:19 +0000 Subject: [issue25630] SIGSEGV in os.putenv() In-Reply-To: <1447629738.32.0.300278557124.issue25630@psf.upfronthosting.co.za> Message-ID: <20151116055816.109179.56789@psf.io> Roundup Robot added the comment: New changeset 3ae62099d70b by Benjamin Peterson in branch '3.5': make the PyUnicode_FSConverter cleanup set the decrefed argument to NULL (closes #25630) https://hg.python.org/cpython/rev/3ae62099d70b New changeset d8d67b502bcc by Benjamin Peterson in branch 'default': merge 3.5 (#25630) https://hg.python.org/cpython/rev/d8d67b502bcc ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 01:12:17 2015 From: report at bugs.python.org (Antony Lee) Date: Mon, 16 Nov 2015 06:12:17 +0000 Subject: [issue25632] Document BUILD_*_UNPACK opcodes Message-ID: <1447654337.27.0.0979674663638.issue25632@psf.upfronthosting.co.za> New submission from Antony Lee: The additional unpack generalizations provided by Python3.5 rely on a new set of opcodes, BUILD_{TUPLE,LIST,DICT,SET}_UNPACK, that are not documented in the docs for the dis module. ---------- assignee: docs at python components: Documentation messages: 254715 nosy: Antony.Lee, docs at python priority: normal severity: normal status: open title: Document BUILD_*_UNPACK opcodes versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 01:27:17 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 16 Nov 2015 06:27:17 +0000 Subject: [issue25628] Make namedtuple "verbose" and "rename" parameters into keyword only arguments In-Reply-To: <1447615273.45.0.0364929463097.issue25628@psf.upfronthosting.co.za> Message-ID: <1447655237.91.0.348693988345.issue25628@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Existing scripts can contain passing positional 'rename' argument: namedtuple('Point', 'x y', False, True). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 01:54:40 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 16 Nov 2015 06:54:40 +0000 Subject: [issue25626] Gzip fails for file over 2**32 bytes In-Reply-To: <1447530501.75.0.968129152166.issue25626@psf.upfronthosting.co.za> Message-ID: <1447656880.84.0.182555307113.issue25626@psf.upfronthosting.co.za> Martin Panter added the comment: Ben: By adding the cap, it means when the lower-level zlib module is asked to decode say 5?GiB, it will decode at most 4?GiB (rather than raising an exception). The 4?GiB limit (UINT_MAX to be precise) is due to the underlying zlib library; it?s not Python?s doing, and the limit was present before 3.5 as well. In 3.5, if you ask GzipFile.read() to decompress 5?GiB, it will actually feed the decompressor 8?KiB (io.DEFAULT_BUFFER_SIZE) of compressed data, which will decompress to at most 8?MB or so (max compression ratio is 1:1032). Then it will feed the next 8?KiB chunk. So it does not matter whether the limit is 4 or 5?GiB because there can only be 8ish MB data per internal decompress() call. Before 3.5, it first feeds a 1?KiB chunk, but exponentially increases the chunk size up to 10?MiB in each internal iteration. If you think the new 3.5 implementation (with OverflowError fixed) is significantly less efficient, I can look at ways of improving it. But I am a bit skeptical. Usually I find once you process 10s or 100s of kB of data at once, any increases in the buffer size have negligible effect on the little time spent in native Python code, and times actually get worse as your buffers get too big, probably due to ineffective use of fast memory caching. === I propose this patch for the 3.5 branch, which implements the internal capping in the zlib module. It changes the zlib module to accept sizes greater than UINT_MAX, but internally limits them. I think this is the most practical way forward, because it does not require Python code to know the value of UINT_MAX (which could in theory vary by platform). I would be good to get a review of my patch. In particular, is this change okay for the 3.5 maintainence branch? It would also be good to confirm that my patch fixes the original problem, i.e. read(2**32) works on computers with more than 4?GiB of memory (which I cannot test). This regression is caused by Issue 23529, where I make sure that GzipFile.read(size) doesn?t buffer huge amounts of data from a decompression bomb. ---------- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file41053/zlib-size_t.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 02:02:21 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 16 Nov 2015 07:02:21 +0000 Subject: [issue25626] Gzip fails for file over 2**32 bytes In-Reply-To: <1447530501.75.0.968129152166.issue25626@psf.upfronthosting.co.za> Message-ID: <1447657341.78.0.782613273134.issue25626@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 02:31:21 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 16 Nov 2015 07:31:21 +0000 Subject: [issue25628] Make namedtuple "verbose" and "rename" parameters into keyword only arguments In-Reply-To: <1447615273.45.0.0364929463097.issue25628@psf.upfronthosting.co.za> Message-ID: <1447659081.41.0.877164683471.issue25628@psf.upfronthosting.co.za> Raymond Hettinger added the comment: My judgment call is that the keyword-only change can be made directly, that the costs and clutter of deprecation and delay aren't worth in it this case, that the nature of the "verbose" and "rename" arguments puts this in the rare-to-non-existent category, that any remediation would be trivial (easier than shutting-off a warning), and that the user's come out ahead with the cleaner cut-over in this case. There's no value in being pedantic on this one, some judgment is required. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 02:45:28 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 16 Nov 2015 07:45:28 +0000 Subject: [issue25628] Make namedtuple "verbose" and "rename" parameters into keyword only arguments In-Reply-To: <1447615273.45.0.0364929463097.issue25628@psf.upfronthosting.co.za> Message-ID: <1447659928.59.0.940781481934.issue25628@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: OK, leave it to you. But may be worth to add a versionchanged directive. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 03:42:51 2015 From: report at bugs.python.org (jon orebro) Date: Mon, 16 Nov 2015 08:42:51 +0000 Subject: [issue25633] The documentation for urllib.request should mention http.client.HTTPException Message-ID: <1447663371.73.0.839165836135.issue25633@psf.upfronthosting.co.za> New submission from jon orebro: The documentation for urllib.request should mention that a robust client using urllib.request must be prepared for exceptions of type http.client.HTTPException in addition to urllib.error.URLError. Example: the server breaks HTTP and returns an empty status line and we get a http.client.BadStatusLine. ---------- assignee: docs at python components: Documentation messages: 254720 nosy: docs at python, jon orebro priority: normal severity: normal status: open title: The documentation for urllib.request should mention http.client.HTTPException type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 04:21:18 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 16 Nov 2015 09:21:18 +0000 Subject: [issue9051] Improve pickle format for timezone aware datetime instances In-Reply-To: <1277151308.95.0.331220838487.issue9051@psf.upfronthosting.co.za> Message-ID: <20151116092115.88486.67261@psf.io> Roundup Robot added the comment: New changeset e48da8f01316 by Serhiy Storchaka in branch '3.4': Issue #9051: Added tests for pickling and copying the timezone objects. https://hg.python.org/cpython/rev/e48da8f01316 New changeset 634905e9628d by Serhiy Storchaka in branch '3.5': Issue #9051: Added tests for pickling and copying the timezone objects. https://hg.python.org/cpython/rev/634905e9628d New changeset 9c31544d6a66 by Serhiy Storchaka in branch 'default': Issue #9051: Added tests for pickling and copying the timezone objects. https://hg.python.org/cpython/rev/9c31544d6a66 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 04:39:59 2015 From: report at bugs.python.org (Jun Wang) Date: Mon, 16 Nov 2015 09:39:59 +0000 Subject: [issue25634] Add a dedicated subclass for attribute missing errors Message-ID: <1447666799.36.0.119700754928.issue25634@psf.upfronthosting.co.za> New submission from Jun Wang: See this simple example: class A(): def __init__(self, x=None): self.x = x @property def t(self): return self.x.t def __getattr__(self, name): return 'default' print(A().t) AttributeError is raised as "'NoneType' object has no attribute 't'". Currently __getattr__ is called if any AttributeError is raised, so the result of a.t is *default*, while an AttributeError is the desired behavior. The most intuitive solution seems to add a subclass of AttributeError, say AttributeMissError, which triggers __getattr__. At present, I have to do some tricky and ugly things to __getattribute__ to show where the AttributeError occurs, or it's quite hard to figure out what happened with no informative traceback messages. ---------- components: Interpreter Core messages: 254722 nosy: ?? priority: normal severity: normal status: open title: Add a dedicated subclass for attribute missing errors type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 04:45:31 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 16 Nov 2015 09:45:31 +0000 Subject: [issue20220] test_datetime, test_tarfile, test_strptime time zone failures In-Reply-To: <1389384273.4.0.330615086279.issue20220@psf.upfronthosting.co.za> Message-ID: <20151116094528.120348.80166@psf.io> Roundup Robot added the comment: New changeset 673b4b093796 by Martin Panter in branch '3.4': Issue #20220: Add DST rules to work around glibc quirk https://hg.python.org/cpython/rev/673b4b093796 New changeset 364bd520d9f1 by Martin Panter in branch '3.5': Issue #20220: Merge time zone workaround from 3.4 into 3.5 https://hg.python.org/cpython/rev/364bd520d9f1 New changeset 039a370d047d by Martin Panter in branch 'default': Issue #20220: Revert time zone test debugging, revision 139c18943d9b https://hg.python.org/cpython/rev/039a370d047d New changeset 007235e65603 by Martin Panter in branch 'default': Issue #20220: Merge time zone workaround from 3.5 https://hg.python.org/cpython/rev/007235e65603 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 04:54:00 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 16 Nov 2015 09:54:00 +0000 Subject: [issue9051] Improve pickle format for timezone aware datetime instances In-Reply-To: <1277151308.95.0.331220838487.issue9051@psf.upfronthosting.co.za> Message-ID: <1447667640.06.0.627095424109.issue9051@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: >>> import pickle, pickletools, datetime >>> len(pickle.dumps([datetime.datetime.utcfromtimestamp(i) for i in range(10000)], 3)) / 10000 30.9283 >>> len(pickle.dumps([datetime.datetime.fromtimestamp(i, datetime.timezone.utc) for i in range(10000)], 3)) / 10000 32.936 >>> len(pickle.dumps([datetime.datetime.utcfromtimestamp(i) for i in range(10000)], 4)) / 10000 19.0074 >>> len(pickle.dumps([datetime.datetime.fromtimestamp(i, datetime.timezone.utc) for i in range(10000)], 4)) / 10000 21.0144 In best case the UTC timezone costs only 2 bytes per datetime instance (BINGET + 1-byte index). In worst case it can cost 5 bytes (LONG_BINGET + 4-bytes index). Saving few bytes for single timezone instance has significant effect only for small pickled data. But in this case it is more advantageous to save a datetime just as a timestamp. I suggest to close this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 05:36:31 2015 From: report at bugs.python.org (Michael Foord) Date: Mon, 16 Nov 2015 10:36:31 +0000 Subject: [issue24928] mock.patch.dict spoils order of items in collections.OrderedDict In-Reply-To: <1440443995.19.0.0795335566212.issue24928@psf.upfronthosting.co.za> Message-ID: <1447670191.3.0.320317432529.issue24928@psf.upfronthosting.co.za> Michael Foord added the comment: Patch looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 06:48:34 2015 From: report at bugs.python.org (Michael Foord) Date: Mon, 16 Nov 2015 11:48:34 +0000 Subject: [issue25532] infinite loop when running inspect.unwrap over unittest.mock.call In-Reply-To: <1446421817.99.0.495650724157.issue25532@psf.upfronthosting.co.za> Message-ID: <1447674514.59.0.352750737192.issue25532@psf.upfronthosting.co.za> Michael Foord added the comment: I'm happy to blacklist __wrapped__ in call. I don't see how call can detect that kind of introspection in the general case though. Limiting call depth would be one option, but any limit is going to be arbitrary and I don't "like" that as a solution. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 07:02:31 2015 From: report at bugs.python.org (Amit Feller) Date: Mon, 16 Nov 2015 12:02:31 +0000 Subject: [issue24313] json fails to serialise numpy.int64 In-Reply-To: <1432801951.51.0.0124262456045.issue24313@psf.upfronthosting.co.za> Message-ID: <1447675351.23.0.570304209394.issue24313@psf.upfronthosting.co.za> Changes by Amit Feller : ---------- nosy: +Amit Feller _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 07:14:39 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 16 Nov 2015 12:14:39 +0000 Subject: [issue25626] Gzip fails for file over 2**32 bytes In-Reply-To: <1447530501.75.0.968129152166.issue25626@psf.upfronthosting.co.za> Message-ID: <1447676079.53.0.713798211738.issue25626@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Is 3.4 affected? A uint_converter was added in issue18294. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 07:26:26 2015 From: report at bugs.python.org (Eli_B) Date: Mon, 16 Nov 2015 12:26:26 +0000 Subject: [issue24313] json fails to serialise numpy.int64 In-Reply-To: <1432801951.51.0.0124262456045.issue24313@psf.upfronthosting.co.za> Message-ID: <1447676786.87.0.974052746616.issue24313@psf.upfronthosting.co.za> Changes by Eli_B : ---------- nosy: +Eli_B _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 07:32:58 2015 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 16 Nov 2015 12:32:58 +0000 Subject: [issue22555] Tracking issue for adjustments to binary/text boundary handling In-Reply-To: <1412481703.35.0.528069461639.issue22555@psf.upfronthosting.co.za> Message-ID: <1447677178.2.0.697334294312.issue22555@psf.upfronthosting.co.za> Nick Coghlan added the comment: In discussing the Windows aspects of the bytes/text boundary handling issues with Brett & Steve recently, I realised I hadn't clearly defined what "fixed" looked like from my perspective. The attached test case is an initial attempt at that. It currently fails on a UTF-8 Linux system, with the "test_dash_c_unicode" case failing when the interpreter is misconfigured with "LANG=C" - the problem there is that when we encode from the -c command line argument back to bytes, we don't pass "surrogateescape". I'd be interested in knowing how much of this already passes on a Windows system. There's also a currently missing test case, which is to pass the info to the subprocess via stdin - "assert_python_ok()" doesn't currently support that, so implementing it will either require a new flag, or direct invocation of spawn_python(). ---------- nosy: +brett.cannon, steve.dower Added file: http://bugs.python.org/file41054/test_cmd_line_unicode.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 07:37:13 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 16 Nov 2015 12:37:13 +0000 Subject: [issue24750] IDLE: Cosmetic improvements for main window In-Reply-To: <1438203302.32.0.836313086846.issue24750@psf.upfronthosting.co.za> Message-ID: <20151116123710.14353.61475@psf.io> Roundup Robot added the comment: New changeset ff31af003c35 by Terry Jan Reedy in branch '2.7': Issue #24750: Improve appearance of IDLE editor window status bar. https://hg.python.org/cpython/rev/ff31af003c35 New changeset ecb74f61a5d4 by Terry Jan Reedy in branch '3.4': Issue #24750: Improve appearance of IDLE editor window status bar. https://hg.python.org/cpython/rev/ecb74f61a5d4 New changeset 483a5cd9f975 by Terry Jan Reedy in branch '2.7': Issue #24750: whitespace https://hg.python.org/cpython/rev/483a5cd9f975 New changeset 38d9ffbb595b by Terry Jan Reedy in branch '3.4': Issue #24750: whitespace https://hg.python.org/cpython/rev/38d9ffbb595b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 07:38:43 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 16 Nov 2015 12:38:43 +0000 Subject: [issue24750] IDLE: Cosmetic improvements for main window In-Reply-To: <1438203302.32.0.836313086846.issue24750@psf.upfronthosting.co.za> Message-ID: <1447677523.19.0.787113133464.issue24750@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Leaving open for now for scrollbar upgrade. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 07:56:36 2015 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Mon, 16 Nov 2015 12:56:36 +0000 Subject: [issue21579] Python 3.4: tempfile.close attribute does not work In-Reply-To: <1401083279.44.0.182194375794.issue21579@psf.upfronthosting.co.za> Message-ID: <1447678596.37.0.293715510786.issue21579@psf.upfronthosting.co.za> ???? ????????? added the comment: Please merge patch, proposed by Eduardo Seabra (Eduardo.Seabra). And document that this is UNIX-only solution. ---------- versions: +Python 3.5, Python 3.6 Added file: http://bugs.python.org/file41055/test_tempfile.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 08:45:21 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 16 Nov 2015 13:45:21 +0000 Subject: [issue25616] Extract OrderedDict tests into separate file In-Reply-To: <1447419681.57.0.354121086978.issue25616@psf.upfronthosting.co.za> Message-ID: <1447681521.3.0.766049887053.issue25616@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Raymond. Here is a patch. It is in Git format, hence Rietveld will not work with it. During creating a patch I found a bug in test_dict_update, it tested only default implementation and didn't test subclasses. ---------- keywords: +patch stage: -> patch review versions: +Python 2.7, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file41056/test_ordered_dict.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 08:47:11 2015 From: report at bugs.python.org (keakon) Date: Mon, 16 Nov 2015 13:47:11 +0000 Subject: [issue25635] urllib2 cannot fully read FTP file Message-ID: <1447681631.39.0.26682578174.issue25635@psf.upfronthosting.co.za> New submission from keakon: I found the bug from this slide: http://sector.ca/Portals/17/Presentations15/SecTor_Branca.pdf The second way cannot fully read the file. import urllib2 url = 'ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-extended-latest' response = urllib2.urlopen(url) data = response.read() print len(data) # 6653498 data = urllib2.urlopen(url).read() print len(data) # 65536 It might be something wrong with the FTP server. It's OK when I read from my own FTP server. ---------- components: Library (Lib) messages: 254733 nosy: keakon priority: normal severity: normal status: open title: urllib2 cannot fully read FTP file type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 09:29:08 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 16 Nov 2015 14:29:08 +0000 Subject: [issue13821] misleading return from isidentifier In-Reply-To: <1326934459.59.0.614334427327.issue13821@psf.upfronthosting.co.za> Message-ID: <1447684148.82.0.795571620322.issue13821@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python, haypo, serhiy.storchaka stage: -> needs patch type: -> behavior versions: +Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 09:29:45 2015 From: report at bugs.python.org (Eli_B) Date: Mon, 16 Nov 2015 14:29:45 +0000 Subject: [issue24313] json fails to serialise numpy.int64 In-Reply-To: <1432801951.51.0.0124262456045.issue24313@psf.upfronthosting.co.za> Message-ID: <1447684185.53.0.00354461679564.issue24313@psf.upfronthosting.co.za> Eli_B added the comment: On 64-bit Windows, my 64-bit Python 2.7.9 and my 32-bit 2.7.10 Python both reproduce the failure with a similar traceback. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 09:50:13 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 16 Nov 2015 14:50:13 +0000 Subject: [issue25634] Add a dedicated subclass for attribute missing errors In-Reply-To: <1447666799.36.0.119700754928.issue25634@psf.upfronthosting.co.za> Message-ID: <1447685413.33.0.743463063099.issue25634@psf.upfronthosting.co.za> R. David Murray added the comment: I understand what you are concerned about, but unfortunately that would be a significant backward compatibility break. This would need discussion on python-ideas, I think. Even aside from the backward compatibility issue I have a feeling the additional complexity this would add to attribute resolution would be deemed too large to be worthwhile, but I haven't looked at the relevant code so I might be wrong. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 09:59:48 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 16 Nov 2015 14:59:48 +0000 Subject: [issue25635] urllib2 cannot fully read FTP file In-Reply-To: <1447681631.39.0.26682578174.issue25635@psf.upfronthosting.co.za> Message-ID: <1447685988.63.0.639195433849.issue25635@psf.upfronthosting.co.za> R. David Murray added the comment: Most likely it is a timing issue, with the response object sometimes getting GCed before the read is complete (your local server would make this less likely since the read would complete sooner). I think this has been fixed in python3. Can you check? Note, however, that this is not best practice code. Ideally you should explicitly close the response object after reading from it. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 10:06:36 2015 From: report at bugs.python.org (=?utf-8?q?Cristian_M=C4=83gheru=C8=99an-Stanciu?=) Date: Mon, 16 Nov 2015 15:06:36 +0000 Subject: [issue557704] netrc module can't handle all passwords Message-ID: <1447686396.19.0.922461348685.issue557704@psf.upfronthosting.co.za> Cristian M?gheru?an-Stanciu added the comment: Why is this issue fixed? I still see this problem on 2.7 and 3.4.3. Can someone please reopen it? mdengler's patch seems to work fine on my machine on both 2.7 and 3.4.3. ---------- nosy: +Cristian M?gheru?an-Stanciu _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 10:24:15 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 16 Nov 2015 15:24:15 +0000 Subject: [issue24623] Parser: broken line numbers for triple-quoted strings In-Reply-To: <1436730078.84.0.940151456611.issue24623@psf.upfronthosting.co.za> Message-ID: <1447687455.86.0.627908535617.issue24623@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This is a duplicate of issue16806 ---------- nosy: +serhiy.storchaka resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> col_offset is -1 and lineno is wrong for multiline string expressions _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 10:30:02 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 16 Nov 2015 15:30:02 +0000 Subject: [issue13821] misleading return from isidentifier In-Reply-To: <1326934459.59.0.614334427327.issue13821@psf.upfronthosting.co.za> Message-ID: <1447687802.85.0.0965377886784.issue13821@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 11:32:54 2015 From: report at bugs.python.org (Eryk Sun) Date: Mon, 16 Nov 2015 16:32:54 +0000 Subject: [issue25631] Segmentation fault with invalid Unicode command-line arguments in embedded Python In-Reply-To: <1447635965.36.0.72529883046.issue25631@psf.upfronthosting.co.za> Message-ID: <1447691574.09.0.925595204356.issue25631@psf.upfronthosting.co.za> Eryk Sun added the comment: The interpreter isn't initialized, so calling PyErr_Format in a release build segfaults when it tries to dereference a NULL PyThreadState. OTOH, a debug build should call PyThreadState_Get, which in this case calls Py_FatalError and aborts the process. Unfortunately 3.5.0+ debug builds don't call PyThreadState_Get due to the fix for issue 25150. > the possibility of other exceptions being raised early in the > initialization sequence remains a potential problem. PEP 432 proposes a pre-initialization phase that sets a valid Python thread state. ---------- nosy: +eryksun, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 11:46:34 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 16 Nov 2015 16:46:34 +0000 Subject: [issue25498] Python 3.4.3 regression in ctypes.frombuffer() In-Reply-To: <1446055572.58.0.349657416945.issue25498@psf.upfronthosting.co.za> Message-ID: <20151116164629.88512.57008@psf.io> Roundup Robot added the comment: New changeset b04ae5392cf2 by Serhiy Storchaka in branch '3.4': Issue #25498: Fixed contributors name. https://hg.python.org/cpython/rev/b04ae5392cf2 New changeset 3738b0ca1356 by Serhiy Storchaka in branch '3.5': Issue #25498: Fixed contributors name. https://hg.python.org/cpython/rev/3738b0ca1356 New changeset 559ff2852cf2 by Serhiy Storchaka in branch 'default': Issue #25498: Fixed contributors name. https://hg.python.org/cpython/rev/559ff2852cf2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 13:27:01 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 16 Nov 2015 18:27:01 +0000 Subject: [issue22555] Tracking issue for adjustments to binary/text boundary handling In-Reply-To: <1412481703.35.0.528069461639.issue22555@psf.upfronthosting.co.za> Message-ID: <1447698421.48.0.362267060071.issue22555@psf.upfronthosting.co.za> Steve Dower added the comment: Right now all of the tests fail on Windows by default (cp437 for me). If I change the default IO encoding to utf-8 (hacked into pylifecycle.c, since PYTHONIOENCODING is ignored by subprocesses using -E), the four "Misconfigured" tests crash at the os.fsencode() call (as "mbcs:strict" cannot encode the characters - this may be a real issue, haven't dug into it yet). Adding more hacks to get past this point brings me back into the ASCII encoding performed by the test, and I'm not sure whether that's just an incorrect assumption for Windows or not. Separate issue: if I run "chcp 437" before the tests, the output is garbage. If I run "chcp 65001" then it shows the characters in the font correctly. The std streams encoding is taken from this value, but it doesn't map back to UTF-8, which is probably another issue. If I add a separate check in fileutils.c at _Py_device_encoding then I get UTF-8 enabled streams when the console is set for cp65001. However, there are still a number of places that use GetACP() to determine the locale and encoding to use, which is incorrect for Unicode-aware programs. In particular, this should not happen: >>> f=open('test.txt', 'w') >>> f.encoding 'cp1252' There's no good reason for the default encoding to not be UTF-8 these days, but this is a much bigger change. It's probably worth doing for 3.6, but may need more discussion... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 13:37:05 2015 From: report at bugs.python.org (Christian Ullrich) Date: Mon, 16 Nov 2015 18:37:05 +0000 Subject: [issue25636] Let launcher autoselect best 32-bit Python on 64-bit system Message-ID: <1447699025.13.0.574177201603.issue25636@psf.upfronthosting.co.za> New submission from Christian Ullrich: As described in PEP 397, the launcher can autoselect the "best" Python version available on a system, or a full version number (major.minor) can be specified. In the latter case, optionally a "-32" suffix can be given to select a 32-bit version, which is useful on 64-bit systems where a 64-bit Python is also present. By default it will select the highest (native) version. I have an application that runs unmodified on Python 3.[345], but only with the 32-bit version because it loads a DLL (this is on Windows, but I think the basic issue applies to other systems as well) that has no 64-bit version available. I would like to run it on any system that has *any* suitable Python installed. However, with the version selection syntax supported by the launcher, I can only demand a 32-bit version if I also specify the Python minor version I want, and I do not necessarily know that in advance. What I would like the launcher to support is a version specification that allows using the "-32" suffix in all possible combinations with version numbers: py -3.5-32 (same as today, 32-bit Python 3.5) py -3-32 (highest 32-bit Python 3) py -32 (highest 32-bit Python available) The last form above, with no major version given, would look for the highest minor version in the default major version. The syntax might have to be different for compatibility reasons, although both incomplete specifications would result in an error message in all released versions. I have been looking for a reason this limited syntax was chosen, but there has not to my knowledge been any discussion of this change on python-dev, and the May 2011 revision to PEP 397 ("based on python-dev feedback") in which it was introduced over the original, more flexible syntax also gives no further hint about its reasoning. Solving this in application code could be done, of course, but both apparent solutions are incredibly ugly: - Reimplementing the version autoselection by listing the available 32-bit versions. - "Shooting blind", invoking every possible version from the top down until one works. "3.5-32? Nope. 3.4-32? Nope. 3.3-32? Yes!" This approach has the added downside that the launcher may not be in the $PATH at all. That is improbable, but possible. I would much rather leave the work to the launcher, where the required knowledge is obviously available. Thanks for hearing me out :-) ---------- messages: 254742 nosy: Christian.Ullrich priority: normal severity: normal status: open title: Let launcher autoselect best 32-bit Python on 64-bit system type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 13:58:14 2015 From: report at bugs.python.org (Brett Cannon) Date: Mon, 16 Nov 2015 18:58:14 +0000 Subject: [issue25609] Add a ContextManager ABC and type In-Reply-To: <1447355679.68.0.225089426373.issue25609@psf.upfronthosting.co.za> Message-ID: <1447700294.7.0.0199799457793.issue25609@psf.upfronthosting.co.za> Brett Cannon added the comment: The reason I suggested the ABC for context managers is mostly to provide a way to help people make sure to implement __enter__() and to provide a default __exit__() which has the proper signature (I personally always forget how many arguments __exit__() takes and what the arguments are past the first one). The type part of this feature request is because I realized that a type hint of "context manager" isn't really useful, but "context manager returning ..." is since a `with` statement does introduce a new variable. IOW none of this has anything to do with isinstance() and it's all about easing the use of the context manager interface and proper type hints for the `with` statement. As for a new module analogous to the `types` module just for ABCs, that's fine by me. I had the same reaction you did, Raymond, about putting it in collections.abc. I can open another issue for that idea and leave this open as it's somewhat orthogonal to what I'm proposing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 14:21:22 2015 From: report at bugs.python.org (Brett Cannon) Date: Mon, 16 Nov 2015 19:21:22 +0000 Subject: [issue25637] Move non-collections-related ABCs out of collections.abc Message-ID: <1447701682.74.0.653642972551.issue25637@psf.upfronthosting.co.za> New submission from Brett Cannon: In discussing adding a context manager ABC in issue #25609, the idea of creating a new module for ABCs that is more analogous to the types modules came up. Currently all ABCs that are generic in the stdlib and don't belong to a specific module end up in collections.abc, e.g. the Awaitable ABC has nothing to do with data structures and yet it's in a module in the collections package. What we could do is create an interfaces module which contains all the ABCs that are not specific to a package. This would mean moving the ABCs out of collections.abc that have nothing to do with collections such as things for async, etc. The real question, though, is how to decide what belongs where, e.g. is Iterable/Iterator a collection, and if so then what about Generator? The other option is that instead of introducing a generic interfaces module we simply create appropriate new modules to house the thematic ABCs and avoid a dumping ground scenario, e.g. some new module for the async stuff instead of just dumping them in an interfaces module. All the other ABCs could probably find existing homes, e.g. Callable could go into functools (although do we want to start a practice of having an abc submodule for all instances where ABCs exist and thus introduce functools.abc?). ---------- components: Library (Lib) messages: 254744 nosy: brett.cannon, rhettinger, stutzbach priority: normal severity: normal stage: test needed status: open title: Move non-collections-related ABCs out of collections.abc type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 14:22:31 2015 From: report at bugs.python.org (Brett Cannon) Date: Mon, 16 Nov 2015 19:22:31 +0000 Subject: [issue25609] Add a ContextManager ABC and type In-Reply-To: <1447355679.68.0.225089426373.issue25609@psf.upfronthosting.co.za> Message-ID: <1447701751.81.0.717995479449.issue25609@psf.upfronthosting.co.za> Brett Cannon added the comment: Depending on how issue #25637 turns out, the ABC could go into contextlib or a new interfaces modules. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 14:23:50 2015 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 16 Nov 2015 19:23:50 +0000 Subject: [issue25637] Move non-collections-related ABCs out of collections.abc In-Reply-To: <1447701682.74.0.653642972551.issue25637@psf.upfronthosting.co.za> Message-ID: <1447701830.97.0.526380295087.issue25637@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 14:41:23 2015 From: report at bugs.python.org (Brett Cannon) Date: Mon, 16 Nov 2015 19:41:23 +0000 Subject: [issue25638] Verify the etree_parse and etree_iterparse benchmarks are working appropriately Message-ID: <1447702883.28.0.950037808414.issue25638@psf.upfronthosting.co.za> New submission from Brett Cannon: If you look at bit.ly/pycon-ca-keynote you will notice that the etree_parse and etree_iterparse benchmarks were horrible for everyone. Because of how badly everyone seemed to do, I think the benchmarks should be verified to be doing reasonable things on implementations other than CPython 2.7. ---------- components: Benchmarks messages: 254746 nosy: brett.cannon, pitrou priority: normal severity: normal status: open title: Verify the etree_parse and etree_iterparse benchmarks are working appropriately _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 14:41:33 2015 From: report at bugs.python.org (Brett Cannon) Date: Mon, 16 Nov 2015 19:41:33 +0000 Subject: [issue25638] Verify the etree_parse and etree_iterparse benchmarks are working appropriately In-Reply-To: <1447702883.28.0.950037808414.issue25638@psf.upfronthosting.co.za> Message-ID: <1447702893.92.0.0532598335994.issue25638@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- assignee: -> brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 14:59:01 2015 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 16 Nov 2015 19:59:01 +0000 Subject: [issue25637] Move non-collections-related ABCs out of collections.abc In-Reply-To: <1447701682.74.0.653642972551.issue25637@psf.upfronthosting.co.za> Message-ID: <1447703941.51.0.0966865598076.issue25637@psf.upfronthosting.co.za> Yury Selivanov added the comment: We had this discussion when we were adding Awaitable, AsyncIterable etc. I suggested to simply put them in the top-level 'abc' module (where ABCMeta is defined). ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 15:07:56 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 16 Nov 2015 20:07:56 +0000 Subject: [issue25638] Verify the etree_parse and etree_iterparse benchmarks are working appropriately In-Reply-To: <1447702883.28.0.950037808414.issue25638@psf.upfronthosting.co.za> Message-ID: <1447704476.39.0.195391556779.issue25638@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Would you have a quick summary for those not willing to watch a whole keynote? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 15:09:28 2015 From: report at bugs.python.org (Neil Schemenauer) Date: Mon, 16 Nov 2015 20:09:28 +0000 Subject: [issue7759] mhlib fails on Btrfs filesystem (test_mhlib failure) In-Reply-To: <1264198934.84.0.705718671648.issue7759@psf.upfronthosting.co.za> Message-ID: <1447704568.88.0.212707425548.issue7759@psf.upfronthosting.co.za> Neil Schemenauer added the comment: Okay, feel free to close this bug. I had heard that HFS+ counts files but I don't have a way to verify that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 15:12:57 2015 From: report at bugs.python.org (Brett Cannon) Date: Mon, 16 Nov 2015 20:12:57 +0000 Subject: [issue25637] Move non-collections-related ABCs out of collections.abc In-Reply-To: <1447701682.74.0.653642972551.issue25637@psf.upfronthosting.co.za> Message-ID: <1447704777.02.0.144896266934.issue25637@psf.upfronthosting.co.za> Brett Cannon added the comment: I guess is the objection of putting concrete ABCs in the abc module is that the abc module contains the actual code to implement ABCs and not ABCs themselves. Personally I would be fine with a submodule within abc like abc.interfaces. Personally I'm starting to warm to the idea of sticking ABCs in proper packages as e.g. functools.abc for Callable; namespaces are one honking great idea after all. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 15:14:14 2015 From: report at bugs.python.org (Brett Cannon) Date: Mon, 16 Nov 2015 20:14:14 +0000 Subject: [issue25638] Verify the etree_parse and etree_iterparse benchmarks are working appropriately In-Reply-To: <1447702883.28.0.950037808414.issue25638@psf.upfronthosting.co.za> Message-ID: <1447704854.27.0.0943663302755.issue25638@psf.upfronthosting.co.za> Brett Cannon added the comment: That link is to a Jupyter notebook so you don't have to watch anything. Plus the video is not even up yet so you can't skip the keynote even if you wanted to since you can't watch it yet. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 15:32:54 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 16 Nov 2015 20:32:54 +0000 Subject: [issue25638] Verify the etree_parse and etree_iterparse benchmarks are working appropriately In-Reply-To: <1447702883.28.0.950037808414.issue25638@psf.upfronthosting.co.za> Message-ID: <1447705974.12.0.998684375287.issue25638@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok, so when you say "horrible for everyone", this is really IronPython and Jython, right? :-) Other runtimes seem to do ok (perhaps not stellar, but ok). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 15:38:33 2015 From: report at bugs.python.org (Brett Cannon) Date: Mon, 16 Nov 2015 20:38:33 +0000 Subject: [issue25638] Verify the etree_parse and etree_iterparse benchmarks are working appropriately In-Reply-To: <1447702883.28.0.950037808414.issue25638@psf.upfronthosting.co.za> Message-ID: <1447706313.46.0.433293303419.issue25638@psf.upfronthosting.co.za> Brett Cannon added the comment: Well, Jython and IronPython obviously did the worst, but even Python 3 didn't do as well as I would have expected, so I still want to double-check the benchmarks to see if it's obvious why CPython 2.7 beats out everyone. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 15:42:43 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 16 Nov 2015 20:42:43 +0000 Subject: [issue25626] Gzip fails for file over 2**32 bytes In-Reply-To: <1447530501.75.0.968129152166.issue25626@psf.upfronthosting.co.za> Message-ID: <1447706563.03.0.744993745069.issue25626@psf.upfronthosting.co.za> Martin Panter added the comment: 3.4 shouldn?t be affected by the gzip regression. In 3.4 the gzip module does not set max_length to limit the decompression size. In 3.4 the underlying zlib module will also raise OverflowError if max_lenth=2**32, and my patch could be applied, but I don?t think it is worth it at this stage. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 15:45:18 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 16 Nov 2015 20:45:18 +0000 Subject: [issue7759] mhlib fails on Btrfs filesystem (test_mhlib failure) In-Reply-To: <1264198934.84.0.705718671648.issue7759@psf.upfronthosting.co.za> Message-ID: <1447706718.4.0.490864560069.issue7759@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yes, what I read, HFS+ counts files. st_ntlink is a number of files and directories + 2 (perhaps for fake "." and ".."). This value never less than 2 + number_of_subdirectories, hence the code should work. Just an optimization has no any effect (as well as on FS where st_ntlink == 1). ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 16:42:09 2015 From: report at bugs.python.org (Roman Kozhemiakin) Date: Mon, 16 Nov 2015 21:42:09 +0000 Subject: [issue25639] open 'PhysicalDriveN' on windows fails (since python 3.5) with OSError: [WinError 1] Incorrect function Message-ID: <1447710129.23.0.746208701925.issue25639@psf.upfronthosting.co.za> New submission from Roman Kozhemiakin: open('\\\\.\\PHYSICALDRIVE1','rb',0) fails since python 3.5 At the end of _io_FileIO___init___impl function _Py_fstat call raise OSError: [WinError 1] Incorrect function _Py_fstat result not used on windows in this place. 440 self->blksize = DEFAULT_BUFFER_SIZE; ---> 441 if (_Py_fstat(self->fd, &fdfstat) < 0) 442 goto error; 443 #if defined(S_ISDIR) && defined(EISDIR) 444 /* On Unix, open will succeed for directories. 445 In Python, there should be no file objects referring to 446 directories, so we need a check. */ 447 if (S_ISDIR(fdfstat.st_mode)) { 448 errno = EISDIR; 449 PyErr_SetFromErrnoWithFilenameObject(PyExc_IOError, nameobj); 450 goto error; 451 } 452 #endif /* defined(S_ISDIR) */ 453 #ifdef HAVE_STRUCT_STAT_ST_BLKSIZE 454 if (fdfstat.st_blksize > 1) 455 self->blksize = fdfstat.st_blksize; 456 #endif /* HAVE_STRUCT_STAT_ST_BLKSIZE */ ---------- components: Library (Lib) messages: 254756 nosy: rokozh priority: normal severity: normal status: open title: open 'PhysicalDriveN' on windows fails (since python 3.5) with OSError: [WinError 1] Incorrect function type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 16:45:11 2015 From: report at bugs.python.org (SilentGhost) Date: Mon, 16 Nov 2015 21:45:11 +0000 Subject: [issue25639] open 'PhysicalDriveN' on windows fails (since python 3.5) with OSError: [WinError 1] Incorrect function In-Reply-To: <1447710129.23.0.746208701925.issue25639@psf.upfronthosting.co.za> Message-ID: <1447710311.12.0.144553997059.issue25639@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- components: +IO, Windows keywords: +3.5regression nosy: +benjamin.peterson, paul.moore, pitrou, steve.dower, stutzbach, tim.golden, zach.ware stage: -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 16:48:00 2015 From: report at bugs.python.org (Matthieu Pepin) Date: Mon, 16 Nov 2015 21:48:00 +0000 Subject: [issue25640] Message.is_attachment() throws exception Message-ID: <1447710480.65.0.915044845124.issue25640@psf.upfronthosting.co.za> New submission from Matthieu Pepin: Message.is_attachment() throws the exception below: File "/usr/lib/python3.5/email/message.py", line 956, in is_attachment return False if c_d is None else c_d.content_disposition == 'attachment' AttributeError: 'str' object has no attribute 'content_disposition' It seems to work fine for me with: return c_d == 'attachment' ---------- components: email messages: 254757 nosy: Matthieu Pepin, barry, r.david.murray priority: normal severity: normal status: open title: Message.is_attachment() throws exception type: crash versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 16:56:25 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 16 Nov 2015 21:56:25 +0000 Subject: [issue25640] Message.is_attachment() throws exception In-Reply-To: <1447710480.65.0.915044845124.issue25640@psf.upfronthosting.co.za> Message-ID: <1447710985.91.0.501464089448.issue25640@psf.upfronthosting.co.za> R. David Murray added the comment: Can you provide a minimum reproducer? It looks like you are somehow managing to use EmailMessage with the compat34 policy, which shouldn't happen unless you work at it, or I overlooked something. Perhaps EmailMessage should disallow setting policy to compat32. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 16:57:02 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 16 Nov 2015 21:57:02 +0000 Subject: [issue25640] Message.is_attachment() throws exception In-Reply-To: <1447710480.65.0.915044845124.issue25640@psf.upfronthosting.co.za> Message-ID: <1447711022.03.0.719085952918.issue25640@psf.upfronthosting.co.za> R. David Murray added the comment: I mean compat32. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 17:09:16 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 16 Nov 2015 22:09:16 +0000 Subject: [issue8823] urllib2 does not catch httplib.BadStatusLine In-Reply-To: <1274881450.55.0.827580135846.issue8823@psf.upfronthosting.co.za> Message-ID: <1447711756.08.0.0983540721507.issue8823@psf.upfronthosting.co.za> Martin Panter added the comment: Issue 13736 also proposes to wrap HTTP client exceptions, although I personally don?t really endorse this. The other option is to fix the documentation: Issue 25633, Issue 22797. ---------- resolution: accepted -> duplicate status: open -> closed superseder: -> urllib.request.urlopen leaks exceptions from socket and httplib.client _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 17:09:20 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 16 Nov 2015 22:09:20 +0000 Subject: [issue25639] open 'PhysicalDriveN' on windows fails (since python 3.5) with OSError: [WinError 1] Incorrect function In-Reply-To: <1447710129.23.0.746208701925.issue25639@psf.upfronthosting.co.za> Message-ID: <1447711760.71.0.553822954202.issue25639@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 17:14:15 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 16 Nov 2015 22:14:15 +0000 Subject: [issue13736] urllib.request.urlopen leaks exceptions from socket and httplib.client In-Reply-To: <1326003740.31.0.0410778534365.issue13736@psf.upfronthosting.co.za> Message-ID: <1447712055.91.0.240155502928.issue13736@psf.upfronthosting.co.za> Martin Panter added the comment: There is another patch in duplicate Issue 8823, which has simpler exception wrapping code, but does not add wrapping of reply exceptions. Personally, I wouldn?t endorse any new wrapping HTTP client exceptions, and even if wrapping more socket OS errors would be consistent, it could be a backwards compatibility problem. I think the best way forward is documentation: Issue 25633, Issue 22797. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 17:17:41 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 16 Nov 2015 22:17:41 +0000 Subject: [issue25633] The documentation for urllib.request should mention http.client.HTTPException In-Reply-To: <1447663371.73.0.839165836135.issue25633@psf.upfronthosting.co.za> Message-ID: <1447712261.09.0.981042626181.issue25633@psf.upfronthosting.co.za> Martin Panter added the comment: Closely related: Issue 22797 proposes documenting some circumstances where ValueError is raised directly. Perhaps you can review and enhance the patch already there. Also related: Issue 13736 proposes to wrap http.client exceptions (which I disagree with), and add extra wrapping for socket.error (which I may agree with for consistency), and document existing ?exception leaks?. Issue 6471 discusses awkwardnesses of getting at the underlying exception that URLError wraps. ---------- nosy: +martin.panter stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 17:23:12 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 16 Nov 2015 22:23:12 +0000 Subject: [issue25638] Verify the etree_parse and etree_iterparse benchmarks are working appropriately In-Reply-To: <1447702883.28.0.950037808414.issue25638@psf.upfronthosting.co.za> Message-ID: <1447712592.98.0.0362894033327.issue25638@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think these histograms would look better with logarithmic scale. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 17:33:12 2015 From: report at bugs.python.org (Brett Cannon) Date: Mon, 16 Nov 2015 22:33:12 +0000 Subject: [issue25638] Verify the etree_parse and etree_iterparse benchmarks are working appropriately In-Reply-To: <1447702883.28.0.950037808414.issue25638@psf.upfronthosting.co.za> Message-ID: <1447713192.13.0.201176317807.issue25638@psf.upfronthosting.co.za> Brett Cannon added the comment: Let's not pollute the issue with a critique of my notebook. You can feel free to email me personally to discuss it if you want, including why I purposefully didn't use a logarithmic scale. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 17:36:40 2015 From: report at bugs.python.org (Matthieu Pepin) Date: Mon, 16 Nov 2015 22:36:40 +0000 Subject: [issue25640] Message.is_attachment() throws exception In-Reply-To: <1447710480.65.0.915044845124.issue25640@psf.upfronthosting.co.za> Message-ID: <1447713400.57.0.432430435841.issue25640@psf.upfronthosting.co.za> Matthieu Pepin added the comment: Ok I think the bug is not where I thought. First, my workaround does not work. Second, I use the following to generate my Message: message_from_string(s, _class=EmailMessage) Maybe the bug is in the parser? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 17:37:27 2015 From: report at bugs.python.org (Matthieu Pepin) Date: Mon, 16 Nov 2015 22:37:27 +0000 Subject: [issue25640] Message.is_attachment() throws exception In-Reply-To: <1447710480.65.0.915044845124.issue25640@psf.upfronthosting.co.za> Message-ID: <1447713447.78.0.911299348248.issue25640@psf.upfronthosting.co.za> Matthieu Pepin added the comment: Yes, I will make a small reproducer. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 17:46:08 2015 From: report at bugs.python.org (alphalfalfa) Date: Mon, 16 Nov 2015 22:46:08 +0000 Subject: [issue25641] urllib/request.py/getproxies_environment() throws "dictionary changed size during iteration" error occasionally Message-ID: <1447713968.83.0.231956831244.issue25641@psf.upfronthosting.co.za> New submission from alphalfalfa: For the following lines of code, "dictionary changed size during iteration" would be thrown when the environment variables change while in iteration. Python-3.5.0/Lib/urllib/request.py 2393 for name, value in os.environ.items(): 2394 name = name.lower() 2395 if value and name[-6:] == '_proxy': 2396 proxies[name[:-6]] = value ---------- components: Library (Lib) messages: 254767 nosy: alphalfalfa priority: normal severity: normal status: open title: urllib/request.py/getproxies_environment() throws "dictionary changed size during iteration" error occasionally versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 17:52:31 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 16 Nov 2015 22:52:31 +0000 Subject: [issue25641] urllib/request.py/getproxies_environment() throws "dictionary changed size during iteration" error occasionally In-Reply-To: <1447713968.83.0.231956831244.issue25641@psf.upfronthosting.co.za> Message-ID: <1447714351.37.0.26727470194.issue25641@psf.upfronthosting.co.za> Martin Panter added the comment: How are you managing to get os.environ to change inside that function? Another thread or garbage collector callback perhaps? My understanding is that os.environ is coupled to the C library?s environment, and that is not thread-safe. ---------- nosy: +martin.panter stage: -> test needed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 18:14:51 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 16 Nov 2015 23:14:51 +0000 Subject: [issue25640] Message.is_attachment() throws exception In-Reply-To: <1447710480.65.0.915044845124.issue25640@psf.upfronthosting.co.za> Message-ID: <1447715691.12.0.415295495066.issue25640@psf.upfronthosting.co.za> R. David Murray added the comment: Ah, yes, that would do it. EmailMessage should definitely throw an error if it gets compat32 as a policy, that would have told you what you were doing "wrong". What you want to be doing is: msg = message_from_string(mystring, policy=default) That will get you an EmailMessage object. Note, however, that you almost never want message_from_string, because real email messages are bytes objects, not strings. string only works if your message is ASCII only. (There's an open issue about documenting this properly...and a big doc revision in the offing.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 18:15:45 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 16 Nov 2015 23:15:45 +0000 Subject: [issue25640] EmailMessage should throw an error if policy is set to compat32 In-Reply-To: <1447710480.65.0.915044845124.issue25640@psf.upfronthosting.co.za> Message-ID: <1447715745.01.0.573776448682.issue25640@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- title: Message.is_attachment() throws exception -> EmailMessage should throw an error if policy is set to compat32 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 18:25:36 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 16 Nov 2015 23:25:36 +0000 Subject: [issue20220] test_datetime, test_tarfile, test_strptime time zone failures In-Reply-To: <1389384273.4.0.330615086279.issue20220@psf.upfronthosting.co.za> Message-ID: <1447716336.25.0.562537257459.issue20220@psf.upfronthosting.co.za> Martin Panter added the comment: The RHEL and SLES buildbots seem to be much happier. (Apart from timeouts in 2.7, which is probably a separate issue.) I also opened a glibc bug: . ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 19:28:48 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 17 Nov 2015 00:28:48 +0000 Subject: [issue25615] Document unsorted behaviour of glob.glob In-Reply-To: <1447410381.17.0.519847126493.issue25615@psf.upfronthosting.co.za> Message-ID: <1447720128.58.0.140993161247.issue25615@psf.upfronthosting.co.za> Martin Panter added the comment: I committed the patch as it was. But normally I do try to keep the number of lines in the diff close to the minimum, even when committing. RST files are like source code and it doesn?t matter if the wrapping is not 100% perfect, because they get turned into HTML or whatever anyway. Plus keeping the diff to a minimum helps when looking through the repository history with annotate or whatever. On the other hand, for doc strings, I think it is best to rewrap them, because that is the wrapping you end up with in pydoc and help(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 19:29:01 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 17 Nov 2015 00:29:01 +0000 Subject: [issue25615] Document unsorted behaviour of glob.glob In-Reply-To: <1447410381.17.0.519847126493.issue25615@psf.upfronthosting.co.za> Message-ID: <1447720141.8.0.889766064929.issue25615@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 19:20:54 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 17 Nov 2015 00:20:54 +0000 Subject: [issue25615] Document unsorted behaviour of glob.glob In-Reply-To: <1447410381.17.0.519847126493.issue25615@psf.upfronthosting.co.za> Message-ID: <20151117002051.21857.34@psf.io> Roundup Robot added the comment: New changeset fa4f0096b719 by Martin Panter in branch '2.7': Issue #25615: Document unsorted behaviour of glob; patch by Dave Jones https://hg.python.org/cpython/rev/fa4f0096b719 New changeset 7ca6a13db0e5 by Martin Panter in branch '3.4': Issue #25615: Document unsorted behaviour of glob; patch by Dave Jones https://hg.python.org/cpython/rev/7ca6a13db0e5 New changeset f928dcb448a9 by Martin Panter in branch '3.5': Issue #25615: Merge glob doc from 3.4 into 3.5 https://hg.python.org/cpython/rev/f928dcb448a9 New changeset a6bc96c2b8be by Martin Panter in branch 'default': Issue #25615: Merge glob doc from 3.5 https://hg.python.org/cpython/rev/a6bc96c2b8be ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 19:37:33 2015 From: report at bugs.python.org (Chris Seto) Date: Tue, 17 Nov 2015 00:37:33 +0000 Subject: [issue25642] Setting maxsize breaks asyncio.JoinableQueue/Queue Message-ID: <1447720653.5.0.538430267197.issue25642@psf.upfronthosting.co.za> New submission from Chris Seto: When maxsize is set on a JoinableQueue/Queue and the queue is full (maxsize <= len(queue)) _put is called rather than __put_internal. __put_internal increments _unfinished_tasks but _put does not. Whenever using maxsize in a Queue calling task_done will almost always cause a ValueError('task_done() called too many times'). ---------- components: asyncio files: test.py messages: 254773 nosy: Chris Seto, gvanrossum, haypo, yselivanov priority: normal severity: normal status: open title: Setting maxsize breaks asyncio.JoinableQueue/Queue type: crash versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file41057/test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 19:38:26 2015 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 17 Nov 2015 00:38:26 +0000 Subject: [issue22555] Tracking issue for adjustments to binary/text boundary handling In-Reply-To: <1412481703.35.0.528069461639.issue22555@psf.upfronthosting.co.za> Message-ID: <1447720706.43.0.273479573351.issue22555@psf.upfronthosting.co.za> Nick Coghlan added the comment: Thanks. I suspect some of the Windows problems are indeed due to bogus assumptions in my draft tests, but at the same time, folks should be able to invoke subprocesses with Unicode values without needing extensive knowledge of platform specific Unicode handling arcana (whether that's *nix or Windows). I've added Victor to the nosy list as well, since he'd previously expressed interest in implementing a cross-platform "force UTF-8" mode for 3.6 (akin to the default behaviour on Mac OS X), and I suspect these proposed test cases will be relevant to such a capability. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 19:40:03 2015 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 17 Nov 2015 00:40:03 +0000 Subject: [issue25593] _sock_connect_cb can be called twice resulting in InvalidStateError In-Reply-To: <1447139794.12.0.288748898255.issue25593@psf.upfronthosting.co.za> Message-ID: <1447720803.93.0.50257949829.issue25593@psf.upfronthosting.co.za> Guido van Rossum added the comment: Thinking about this more I believe it's possible for any of the FD callbacks in selector_events.py to be placed into loop._ready multiple times if the loop is stopped after the FD is ready (and the callback is scheduled) but before the callback is called. In all cases such a scenario results in the same callback (with the same future) being scheduled twice; the first call will call fut.set_result() and then the second call, if the FD is (still, or again) ready, will fail calling fut.set_result() on the same Future. The reason we've only seen reports of this for _sock_connect_cb() is probably that the other calls are all uncommon -- you have to explicitly call loop.sock_accept(), loop.sock_recv(), or loop.sock_sendall(), which is not the usual (or recommended) idiom. Instead, most people use Transports and Protocols, which use a different API, and create_server() doesn't use sock_accept(). But create_connection() *does* call sock_connect(), so that's used by everybody's code. I think the discussed change to stop() to set a flag that is only checked after all the ready for-loop is done might work here -- it guarantees that all I/O callbacks get to run before the selector is polled again. However, it requires that an I/O callback that wants to modify the selector in order to prevent itself from being called must do so itself, not schedule some other call that modifies the selector. That's fine for the set of I/O callbacks I've looked at. I just don't feel comfortable running the ready queue before polling the selector, since a worst-case scenario could starve the selector completely (as I sketched before -- and the proposed modification to stop() doesn't directly change this). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 19:44:43 2015 From: report at bugs.python.org (Chris Seto) Date: Tue, 17 Nov 2015 00:44:43 +0000 Subject: [issue25642] Setting maxsize breaks asyncio.JoinableQueue/Queue In-Reply-To: <1447720653.5.0.538430267197.issue25642@psf.upfronthosting.co.za> Message-ID: <1447721083.38.0.487140820348.issue25642@psf.upfronthosting.co.za> Chris Seto added the comment: Looks to be fixed in python 3.6 ---------- resolution: -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 20:02:09 2015 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 17 Nov 2015 01:02:09 +0000 Subject: [issue25642] Setting maxsize breaks asyncio.JoinableQueue/Queue In-Reply-To: <1447720653.5.0.538430267197.issue25642@psf.upfronthosting.co.za> Message-ID: <1447722129.28.0.46013824416.issue25642@psf.upfronthosting.co.za> Guido van Rossum added the comment: Should also be fixed in the next 3.4/3.5 releases. We rewrote the guts of the Queue class to be much simpler. See https://github.com/python/asyncio (specifically, https://github.com/python/asyncio/commit/872597ba12953849cc6893042fd044073b87f870). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 20:27:33 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 17 Nov 2015 01:27:33 +0000 Subject: [issue25643] Python tokenizer rewriting Message-ID: <1447723653.14.0.424824913135.issue25643@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Here is preliminary patch that refactors the lowest level of Python tokenizer, reading and decoding. It splits the code on smaller simpler functions, decreases the source size by 37 lines, and fixes bugs: issue14811, issue18961, and a number of others. Added tests for most of fixed bugs (except leaks and others hardly reproducible). But the fix for other bugs can be harder, especially for issues with null byte (issue1105770, issue20115). Many bug easily can be fixed if read all Python file in memory instead of reading it line by line. I don't know if it is acceptable. ---------- assignee: serhiy.storchaka components: Interpreter Core files: tokenize_input.patch keywords: patch messages: 254778 nosy: serhiy.storchaka priority: normal severity: normal status: open title: Python tokenizer rewriting type: behavior versions: Python 3.6 Added file: http://bugs.python.org/file41058/tokenize_input.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 21:32:52 2015 From: report at bugs.python.org (Justin Mayfield) Date: Tue, 17 Nov 2015 02:32:52 +0000 Subject: [issue25593] _sock_connect_cb can be called twice resulting in InvalidStateError In-Reply-To: <1447139794.12.0.288748898255.issue25593@psf.upfronthosting.co.za> Message-ID: <1447727572.29.0.316740933753.issue25593@psf.upfronthosting.co.za> Justin Mayfield added the comment: +1 Let me know what I can do to help. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 21:54:09 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 17 Nov 2015 02:54:09 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <1447728849.3.0.621719791571.issue23883@psf.upfronthosting.co.za> Martin Panter added the comment: issue23883_fileinput.v2.patch looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 22:00:11 2015 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 17 Nov 2015 03:00:11 +0000 Subject: [issue25593] _sock_connect_cb can be called twice resulting in InvalidStateError In-Reply-To: <1447727572.29.0.316740933753.issue25593@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: @Justin: Do you want to come up with a PR for the stop() changes? Hopefully including tests (I bet at least one test will fail -- our tests in generally are pretty constraining). On Mon, Nov 16, 2015 at 6:32 PM, Justin Mayfield wrote: > > Justin Mayfield added the comment: > > +1 > > Let me know what I can do to help. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 22:56:20 2015 From: report at bugs.python.org (Jatin Miglani) Date: Tue, 17 Nov 2015 03:56:20 +0000 Subject: [issue25644] Unable to open IDLE on Windows 10 with Python 2.7.10 Message-ID: <1447732580.69.0.0826869384289.issue25644@psf.upfronthosting.co.za> New submission from Jatin Miglani: Hi, Seems like an issue with IDLE on Windows 10 with Python 2.7.10 active Python distribution. I'm able to open IDLE but it crash immediately. Try with deleting .idle.... folder but it couldn't help. Then I moved backed to 2.7.9 version which ultimately helps to get it invoked from machine. Kindly reproduce and check the 2.7.10 distribution with windows 10 64 bit. Thanks Jatin Miglani ---------- components: IDLE messages: 254782 nosy: jatanig priority: normal severity: normal status: open title: Unable to open IDLE on Windows 10 with Python 2.7.10 type: crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 23:20:36 2015 From: report at bugs.python.org (Justin Mayfield) Date: Tue, 17 Nov 2015 04:20:36 +0000 Subject: [issue25593] _sock_connect_cb can be called twice resulting in InvalidStateError In-Reply-To: <1447139794.12.0.288748898255.issue25593@psf.upfronthosting.co.za> Message-ID: <1447734036.55.0.0598110494899.issue25593@psf.upfronthosting.co.za> Justin Mayfield added the comment: You bet. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 01:39:23 2015 From: report at bugs.python.org (Eryk Sun) Date: Tue, 17 Nov 2015 06:39:23 +0000 Subject: [issue25639] open 'PhysicalDriveN' on windows fails (since python 3.5) with OSError: [WinError 1] Incorrect function In-Reply-To: <1447710129.23.0.746208701925.issue25639@psf.upfronthosting.co.za> Message-ID: <1447742363.69.0.138177880196.issue25639@psf.upfronthosting.co.za> Eryk Sun added the comment: As a workaround you can open a file descriptor via os.open: >>> import os >>> fd = os.open(r'\\.\PhysicalDrive0', os.O_RDONLY | os.O_BINARY) >>> os.read(fd, 512)[:8] b'3\xc0\x8e\xd0\xbc\x00|\x8e' > _Py_fstat result not used on windows in this place. While it's pretty much useless, it is possible to open a CRT file descriptor for a directory handle: >>> h = _winapi.CreateFile('C:\\', 0x80000000, 3, 0, 3, 0x02000000, 0) >>> fd = msvcrt.open_osfhandle(h, os.O_RDONLY) >>> open(fd) Traceback (most recent call last): File "", line 1, in IsADirectoryError: [Errno 21] Is a directory: 3 So calling _Py_fstat shouldn't be skipped on Windows. The issue is that a raw disk device doesn't support querying information (IRP_MJ_QUERY_INFORMATION), as shown in this local kernel debugging session: lkd> !object \GLOBAL??\PhysicalDrive0 [...] Target String is '\Device\Harddisk0\DR0' lkd> !object \Device\Harddisk0\DR0 Object: ffffe001c4fa4500 Type: (ffffe001c3d7bd30) Device [...] lkd> !devobj ffffe001c4fa4500 Device object (ffffe001c4fa4500) is for: DR0 \Driver\disk DriverObject ffffe001c4fa3310 [...] lkd> !drvobj \Driver\disk 2 [...] Dispatch routines: [...] [05] IRP_MJ_QUERY_INFORMATION fffff8037251a06c nt!IopInvalidDeviceRequest [06] IRP_MJ_SET_INFORMATION fffff8037251a06c nt!IopInvalidDeviceRequest [...] Specifically WinAPI GetFileInformationByHandle calls the system function NtQueryInformationFile. The system call makes an IRP_MJ_QUERY_INFORMATION I/O request of the driver, which for a raw disk device is handled by IopInvalidDeviceRequest. This fails the request with STATUS_INVALID_DEVICE_REQUEST (0xC0000010), which translates to WinAPI ERROR_INVALID_FUNCTION (0x0001). Possibly in the case of ERROR_INVALID_FUNCTION, FileIO can just call PyErr_Clear and skip the code that uses fdfstat. ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 02:08:26 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 17 Nov 2015 07:08:26 +0000 Subject: [issue25641] urllib/request.py/getproxies_environment() throws "dictionary changed size during iteration" error occasionally In-Reply-To: <1447713968.83.0.231956831244.issue25641@psf.upfronthosting.co.za> Message-ID: <1447744106.82.0.0939139832087.issue25641@psf.upfronthosting.co.za> Raymond Hettinger added the comment: For a simple fix, 2393 should probably read: for name, value in list(os.environ.items()): ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 04:58:58 2015 From: report at bugs.python.org (Justin Mayfield) Date: Tue, 17 Nov 2015 09:58:58 +0000 Subject: [issue25593] _sock_connect_cb can be called twice resulting in InvalidStateError In-Reply-To: <1447139794.12.0.288748898255.issue25593@psf.upfronthosting.co.za> Message-ID: <1447754338.75.0.853387159479.issue25593@psf.upfronthosting.co.za> Justin Mayfield added the comment: Attached patch submission for stop flag proposal. I assume you didn't mean a github PR since the dev docs seem to indicate that is for readonly usage. This passes all the tests on my osx box but it should obviously be run by a lot more folks. ---------- Added file: http://bugs.python.org/file41059/Issue25593_fix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 05:23:09 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 17 Nov 2015 10:23:09 +0000 Subject: [issue25645] Reference leak in test_capi, on "import _pickle" in a subinterpreter Message-ID: <1447755789.28.0.949162336612.issue25645@psf.upfronthosting.co.za> New submission from STINNER Victor: """ [Python-checkins] Daily reference leaks (97e2a6810f7f): sum=10 results for 97e2a6810f7f on branch "default" -------------------------------------------- test_asyncio leaked [0, 0, 3] memory blocks, sum=3 test_capi leaked [1, 1, 1] references, sum=3 test_functools leaked [0, 2, 2] memory blocks, sum=4 Command line was: ['./python', '-m', 'test.regrtest', '-uall', '-R', '3:3:/home/psf-users/antoine/refleaks/reflogBLsY2a', '--timeout', '7200'] """ It looks the leak comes from "import _pickle". The reference leak was introduced by the issue #24164 with the change bc5894a3a0e6. Attached patch should fix it. To validate the patch, run: "./python -m test -R 3:3 test_capi", or "./python -m test -R 3:3 test_leak" with attached "test_leak.py". @Serhiy: Since you wrote the change introduding the leak, could you please review my fix? Thanks. ---------- files: _pickle_partial.patch keywords: patch messages: 254787 nosy: haypo, serhiy.storchaka priority: normal severity: normal status: open title: Reference leak in test_capi, on "import _pickle" in a subinterpreter type: resource usage versions: Python 3.6 Added file: http://bugs.python.org/file41060/_pickle_partial.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 05:23:30 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 17 Nov 2015 10:23:30 +0000 Subject: [issue25645] Reference leak in test_capi, on "import _pickle" in a subinterpreter In-Reply-To: <1447755789.28.0.949162336612.issue25645@psf.upfronthosting.co.za> Message-ID: <1447755810.8.0.577907975947.issue25645@psf.upfronthosting.co.za> Changes by STINNER Victor : Added file: http://bugs.python.org/file41061/test_leak.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 05:31:43 2015 From: report at bugs.python.org (JGoutin) Date: Tue, 17 Nov 2015 10:31:43 +0000 Subject: [issue25646] Distutils and Windows SDK 7.0 / Windows SDK 7.1 / Visual C++ Build Tools 2015 Message-ID: <1447756303.67.0.435034104806.issue25646@psf.upfronthosting.co.za> New submission from JGoutin: Hello, This issue is related to Visual C++ standalone distributions (Without any Visual Studio version installed). Distutils don't properly detect theses compilers. It try to work with "vcvarsall.bat" but this file : - is missing with Visual C++ Build Tools 2015. - don't set correctly the environment with Windows SDK 7.0/7.1 I fixed this issue by modifying "vcvarsall.bat" for redirect to the goods files and set properly the environment. The procedure is detailed here : https://wiki.python.org/moin/WindowsCompilers I have tested this issue with : - Python 3.5 + Visual C++ Tools 2015 - Python 3.4 + Windows SDK 7.1 I have not tested yet (But it work exactly as SDK 7.1): - Python 2.7 + Windows SDK 7.0 I can eventually work to fix this directly on distutils (Or help to fix it). ---------- components: Distutils messages: 254788 nosy: JGoutin, dstufft, eric.araujo priority: normal severity: normal status: open title: Distutils and Windows SDK 7.0 / Windows SDK 7.1 / Visual C++ Build Tools 2015 type: enhancement versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 05:34:44 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 17 Nov 2015 10:34:44 +0000 Subject: [issue20220] test_datetime, test_tarfile, test_strptime time zone failures In-Reply-To: <1447716336.25.0.562537257459.issue20220@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > I also opened a glibc bug: . Wow, great! Thank you. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 05:47:45 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 17 Nov 2015 10:47:45 +0000 Subject: [issue25639] open 'PhysicalDriveN' on windows fails (since python 3.5) with OSError: [WinError 1] Incorrect function In-Reply-To: <1447710129.23.0.746208701925.issue25639@psf.upfronthosting.co.za> Message-ID: <1447757265.53.0.366968700226.issue25639@psf.upfronthosting.co.za> STINNER Victor added the comment: I don't know the physical disk type on Windows. Can you read and write from such "file" type? If no, I don't think that it makes sense to support it in io.FileIO. What do you think? It looks like the file must be opened with specific options, otherwise it doesn't work. See this question on CreateFile(): https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/fa2175fe-02f4-4adb-9cb9-5df3d1122cf6/readfile-works-when-handle-opened-with-drive-letterphysical-drive-symlink-but-not-with-device-path io.FileIO() calls _Py_fstat() for two reasons: 1) raise an error if the path/file descriptor is a directory 2) get the block size _Py_fstat() is implemented with two Windows calls: GetFileType() & GetFileInformationByHandle(). To solve this issue, we need to have a function telling that the path/file descriptor is a physical disk. In this case, we can skip both checks. Documentation on Physical Drivers in CreateFile(): https://msdn.microsoft.com/en-us/library/aa363858%28VS.85%29.aspx#physical_disks_and_volumes ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 06:07:25 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 17 Nov 2015 11:07:25 +0000 Subject: [issue25645] Reference leak in test_capi, on "import _pickle" in a subinterpreter In-Reply-To: <1447755789.28.0.949162336612.issue25645@psf.upfronthosting.co.za> Message-ID: <1447758445.35.0.235355780611.issue25645@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The patch LGTM. Thank you Victor. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 06:15:19 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 17 Nov 2015 11:15:19 +0000 Subject: [issue24164] Support pickling objects with __new__ with keyword arguments with protocol 2+ In-Reply-To: <1431341390.51.0.0928642680419.issue24164@psf.upfronthosting.co.za> Message-ID: <20151117111516.21875.63884@psf.io> Roundup Robot added the comment: New changeset 7adc1d24d05b by Victor Stinner in branch 'default': Closes #25645: Fix a reference leak introduced by change bc5894a3a0e6 of the https://hg.python.org/cpython/rev/7adc1d24d05b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 06:15:19 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 17 Nov 2015 11:15:19 +0000 Subject: [issue25645] Reference leak in test_capi, on "import _pickle" in a subinterpreter In-Reply-To: <1447755789.28.0.949162336612.issue25645@psf.upfronthosting.co.za> Message-ID: <20151117111516.21875.71937@psf.io> Roundup Robot added the comment: New changeset 7adc1d24d05b by Victor Stinner in branch 'default': Closes #25645: Fix a reference leak introduced by change bc5894a3a0e6 of the https://hg.python.org/cpython/rev/7adc1d24d05b ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 06:16:16 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 17 Nov 2015 11:16:16 +0000 Subject: [issue25645] Reference leak in test_capi, on "import _pickle" in a subinterpreter In-Reply-To: <20151117111516.21875.71937@psf.io> Message-ID: STINNER Victor added the comment: > The patch LGTM. Thank you Victor. Thanks for the review Serhiy. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 06:52:43 2015 From: report at bugs.python.org (John Runyon) Date: Tue, 17 Nov 2015 11:52:43 +0000 Subject: [issue24172] Errors in resource.getpagesize module documentation In-Reply-To: <1431498092.42.0.745658320728.issue24172@psf.upfronthosting.co.za> Message-ID: <1447761163.3.0.212982879447.issue24172@psf.upfronthosting.co.za> John Runyon added the comment: This is a duplicate of 20468, which has a patch submitted (over a year ago). ---------- nosy: +jrunyon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 06:54:16 2015 From: report at bugs.python.org (John Runyon) Date: Tue, 17 Nov 2015 11:54:16 +0000 Subject: [issue20468] resource module documentation is incorrect In-Reply-To: <1391208641.83.0.141932054107.issue20468@psf.upfronthosting.co.za> Message-ID: <1447761256.77.0.908079519156.issue20468@psf.upfronthosting.co.za> John Runyon added the comment: *bump*. This flat-out wrong documentation has already misled several people, and has had a proposed patch with no comments for over a year. ---------- nosy: +jrunyon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 06:55:09 2015 From: report at bugs.python.org (Roman Kozhemiakin) Date: Tue, 17 Nov 2015 11:55:09 +0000 Subject: [issue25639] open 'PhysicalDriveN' on windows fails (since python 3.5) with OSError: [WinError 1] Incorrect function In-Reply-To: <1447710129.23.0.746208701925.issue25639@psf.upfronthosting.co.za> Message-ID: <1447761308.99.0.642714829482.issue25639@psf.upfronthosting.co.za> Roman Kozhemiakin added the comment: >I don't know the physical disk type on Windows. Can you read and write from such "file" type? Yes this "files" can be readed and writed (with restriction - size of the data must be a multiple of the sector size) in python 3.4.3 open,read,write,seek - works fine (with raw usb disk) for python 3.5 as workaround I replaced these functions to os.xxxx >2) get the block size st_blksize is not implemented under windows ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 07:02:56 2015 From: report at bugs.python.org (John Runyon) Date: Tue, 17 Nov 2015 12:02:56 +0000 Subject: [issue24256] threading.Timer is not a class In-Reply-To: <1432189781.3.0.318420798275.issue24256@psf.upfronthosting.co.za> Message-ID: <1447761776.62.0.800394418149.issue24256@psf.upfronthosting.co.za> John Runyon added the comment: New proposed patch. I understand not wanting to document an "internal only name", except that in this case it rather needs to be documented. I would strongly prefer Angad's patch to mine because you do, at times, need to know the actual name of the class being used -- and the documentation should not force people to dig through the source code to find that. ---------- Added file: http://bugs.python.org/file41062/timer.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 07:05:09 2015 From: report at bugs.python.org (Vladimir Rutsky) Date: Tue, 17 Nov 2015 12:05:09 +0000 Subject: [issue25647] Return of asyncio.coroutine from asyncio.coroutine don't work in with enabled debug Message-ID: <1447761909.17.0.397190405372.issue25647@psf.upfronthosting.co.za> New submission from Vladimir Rutsky: Return of @asyncio.coroutine-wrapped coroutine object from @asyncio.coroutine-wrapped coroutine fails if asyncio debug is enabled. Consider following example: @asyncio.coroutine def outer_coro(): @asyncio.coroutine def inner_coro(): return 1 return g() result = loop.run_until_complete(outer_coro()) If debug is disabled result will be 1, if debug is enabled, result will be CoroWrapper object. This issue is discussed on asyncio mailing list: https://groups.google.com/forum/?fromgroups#!topic/python-tulip/YFfFxftxxDc Complete example to reproduce this problem is here: https://gist.github.com/rutsky/c72be2edeb1c8256d680 Attaching patch for Python 3.4 branch that fixes this issue and add test for this bug. This issue is not reproduced in Python 3.5, because CoroWrapper is awaitable in Python 3.5 (and in Python 3.4 CoroWrapper is not future or generator). ---------- components: asyncio files: fix_return_of_coro_from_coro.diff keywords: patch messages: 254799 nosy: gvanrossum, haypo, vrutsky, yselivanov priority: normal severity: normal status: open title: Return of asyncio.coroutine from asyncio.coroutine don't work in with enabled debug versions: Python 3.4 Added file: http://bugs.python.org/file41063/fix_return_of_coro_from_coro.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 07:05:47 2015 From: report at bugs.python.org (Vladimir Rutsky) Date: Tue, 17 Nov 2015 12:05:47 +0000 Subject: [issue25647] Return of asyncio.coroutine from asyncio.coroutine doesn't work in with enabled debug In-Reply-To: <1447761909.17.0.397190405372.issue25647@psf.upfronthosting.co.za> Message-ID: <1447761947.54.0.7493484684.issue25647@psf.upfronthosting.co.za> Changes by Vladimir Rutsky : ---------- title: Return of asyncio.coroutine from asyncio.coroutine don't work in with enabled debug -> Return of asyncio.coroutine from asyncio.coroutine doesn't work in with enabled debug _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 07:06:10 2015 From: report at bugs.python.org (Vladimir Rutsky) Date: Tue, 17 Nov 2015 12:06:10 +0000 Subject: [issue25647] Return of asyncio.coroutine from asyncio.coroutine doesn't work with enabled asyncio debug In-Reply-To: <1447761909.17.0.397190405372.issue25647@psf.upfronthosting.co.za> Message-ID: <1447761970.19.0.426947013003.issue25647@psf.upfronthosting.co.za> Changes by Vladimir Rutsky : ---------- title: Return of asyncio.coroutine from asyncio.coroutine doesn't work in with enabled debug -> Return of asyncio.coroutine from asyncio.coroutine doesn't work with enabled asyncio debug _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 07:47:20 2015 From: report at bugs.python.org (Vladimir Rutsky) Date: Tue, 17 Nov 2015 12:47:20 +0000 Subject: [issue25648] asyncio.coroutine fails if asyncio debug mode is enabled and wrapped function don't have "__name__" attribute Message-ID: <1447764440.4.0.175921042664.issue25648@psf.upfronthosting.co.za> New submission from Vladimir Rutsky: In Python 3.4.3 with enabled asyncio debug a function is wrapped using the following code in @asyncio.coroutine: @functools.wraps(func) def wrapper(*args, **kwds): w = CoroWrapper(coro(*args, **kwds), func) if w._source_traceback: del w._source_traceback[-1] w.__name__ = func.__name__ if hasattr(func, '__qualname__'): w.__qualname__ = func.__qualname__ w.__doc__ = func.__doc__ return w The unconditional access to "__name__" and "__doc__" attributes may fail in some circumstances. As this case looks strange and unrealistic I met it in a real application that used mocking in tests. The code there was something like the following: def f(): return "f result" mocked_f = Mock(wraps=f) coro_func = asyncio.coroutine(mocked_f) print(loop.run_until_complete(coro_func())) mocked_f.assert_called_once_with() Here is complete example: https://gist.github.com/rutsky/65cee7728135b05d49c3 This issue is fixed in 95964:957478e95b26 changeset during adding support of async/await syntax, so it is not reproduced in Python 3.5 or 3.4 head, but still reproducible in latest released version of Python 3.4 branch: 3.4.3. So until 3.4.4 is released this issue still may be considered as not fixed. ---------- components: asyncio messages: 254800 nosy: gvanrossum, haypo, vrutsky, yselivanov priority: normal severity: normal status: open title: asyncio.coroutine fails if asyncio debug mode is enabled and wrapped function don't have "__name__" attribute versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 09:38:58 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 17 Nov 2015 14:38:58 +0000 Subject: [issue25646] Distutils and Windows SDK 7.0 / Windows SDK 7.1 / Visual C++ Build Tools 2015 In-Reply-To: <1447756303.67.0.435034104806.issue25646@psf.upfronthosting.co.za> Message-ID: <1447771138.01.0.384461619063.issue25646@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware versions: -Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 10:19:48 2015 From: report at bugs.python.org (Andrew Stormont) Date: Tue, 17 Nov 2015 15:19:48 +0000 Subject: [issue23895] python socket module fails to build on Solaris when -zignore is in LDFLAGS In-Reply-To: <1428586985.69.0.885305793504.issue23895@psf.upfronthosting.co.za> Message-ID: <1447773588.67.0.465602079128.issue23895@psf.upfronthosting.co.za> Andrew Stormont added the comment: Bump. ---------- status: open -> languishing _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 10:20:14 2015 From: report at bugs.python.org (Andrew Stormont) Date: Tue, 17 Nov 2015 15:20:14 +0000 Subject: [issue23895] [PATCH] python socket module fails to build on Solaris when -zignore is in LDFLAGS In-Reply-To: <1428586985.69.0.885305793504.issue23895@psf.upfronthosting.co.za> Message-ID: <1447773614.41.0.790311967797.issue23895@psf.upfronthosting.co.za> Changes by Andrew Stormont : ---------- title: python socket module fails to build on Solaris when -zignore is in LDFLAGS -> [PATCH] python socket module fails to build on Solaris when -zignore is in LDFLAGS _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 10:36:18 2015 From: report at bugs.python.org (Steve Dower) Date: Tue, 17 Nov 2015 15:36:18 +0000 Subject: [issue25646] Distutils and Windows SDK 7.0 / Windows SDK 7.1 / Visual C++ Build Tools 2015 In-Reply-To: <1447756303.67.0.435034104806.issue25646@psf.upfronthosting.co.za> Message-ID: <1447774578.45.0.225603309617.issue25646@psf.upfronthosting.co.za> Steve Dower added the comment: The tools for VS 2015 is a known issue. I let the team know before they released it but it was too late. There'll be an update soon that should work. For Python 3.2 and earlier use http://aka.ms/vcpython27 and setuptools 6 or later. The SDK 7.1 layout doesn't match what distutils expects, so it requires more changes than simple detection. The recommendation is to use the SDK command prompt and set DISTUTILS_USE_SDK=1 before building wheels. (There may be one more env var needed here, I'm on my phone and can't check.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 10:40:59 2015 From: report at bugs.python.org (Steve Dower) Date: Tue, 17 Nov 2015 15:40:59 +0000 Subject: [issue22555] Tracking issue for adjustments to binary/text boundary handling In-Reply-To: <1412481703.35.0.528069461639.issue22555@psf.upfronthosting.co.za> Message-ID: <1447774859.41.0.465291235398.issue22555@psf.upfronthosting.co.za> Steve Dower added the comment: The thing about bogus assumptions is that Python should paper over those anyway. I can guarantee there's production code out there with the same assumptions. How do we make this work? No idea in the context of the bytes/str filename convention differences. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 11:28:05 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 17 Nov 2015 16:28:05 +0000 Subject: [issue25629] Move set fill/used updates out of set_insert_clean() In-Reply-To: <1447618667.35.0.632647105996.issue25629@psf.upfronthosting.co.za> Message-ID: <20151117162801.14357.76212@psf.io> Roundup Robot added the comment: New changeset 23d0cae3f8a1 by Raymond Hettinger in branch 'default': Issue #25629: Move set fill/used updates out of inner loop https://hg.python.org/cpython/rev/23d0cae3f8a1 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 11:28:22 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 17 Nov 2015 16:28:22 +0000 Subject: [issue25629] Move set fill/used updates out of set_insert_clean() In-Reply-To: <1447618667.35.0.632647105996.issue25629@psf.upfronthosting.co.za> Message-ID: <1447777702.44.0.588520208341.issue25629@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 12:07:40 2015 From: report at bugs.python.org (Brett Cannon) Date: Tue, 17 Nov 2015 17:07:40 +0000 Subject: [issue25649] Come up with a good way to handle module aliasing Message-ID: <1447780060.32.0.735153163812.issue25649@psf.upfronthosting.co.za> New submission from Brett Cannon: If you look at things like https://github.com/kennethreitz/requests/issues/2870 and https://pythonhosted.org/six/#module-six.moves you start to notice that users do on occasion have a need to alias module names. It might be worth thinking through what that might entail and provide a solution. Historically it has been done with a meta path importer which catches the import for some old module name, imports the real name, and then sets sys.modules under the alternative name before returning that the import was successful. It's a little tricky to get right, though, since you essentially have to pause an import while another one is going on, make sure you wait to the last minute to do the sys.modules aliasing to make sure no object swap handled from underneath you. I also have not thought through the best way to do this with module specs., but maybe there is a better way. There's also making sure locking is handled properly. The reason this might be useful to have in importlib is it would help facilitate module renamings. If you set it up so that it isn't hard to turn on with mappings of old name to new along with whether you want to raise an ImportWarning about the aliasing then others may find it useful. ---------- components: Library (Lib) messages: 254805 nosy: brett.cannon priority: normal severity: normal stage: test needed status: open title: Come up with a good way to handle module aliasing type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 12:14:31 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 17 Nov 2015 17:14:31 +0000 Subject: [issue25649] Come up with a good way to handle module aliasing In-Reply-To: <1447780060.32.0.735153163812.issue25649@psf.upfronthosting.co.za> Message-ID: <1447780471.46.0.694449743172.issue25649@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 12:15:47 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 17 Nov 2015 17:15:47 +0000 Subject: [issue25649] Come up with a good way to handle module aliasing In-Reply-To: <1447780060.32.0.735153163812.issue25649@psf.upfronthosting.co.za> Message-ID: <1447780547.82.0.396418242551.issue25649@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: Another example is the six.moves module, though I haven't looked at its implementation approach. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 12:22:56 2015 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 17 Nov 2015 17:22:56 +0000 Subject: [issue25643] Python tokenizer rewriting In-Reply-To: <1447723653.14.0.424824913135.issue25643@psf.upfronthosting.co.za> Message-ID: <1447780976.1.0.26475801649.issue25643@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 12:32:23 2015 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 17 Nov 2015 17:32:23 +0000 Subject: [issue25648] asyncio.coroutine fails if asyncio debug mode is enabled and wrapped function don't have "__name__" attribute In-Reply-To: <1447764440.4.0.175921042664.issue25648@psf.upfronthosting.co.za> Message-ID: <1447781543.08.0.788242093289.issue25648@psf.upfronthosting.co.za> Yury Selivanov added the comment: > So until 3.4.4 is released this issue still may be considered as not fixed. Since this issue is fixed in the repo, and will be shipped in the upcoming 3.5.1 and 3.4.4, I'd suggest to close this issue -- there is nothing to be done here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 12:41:18 2015 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 17 Nov 2015 17:41:18 +0000 Subject: [issue25648] asyncio.coroutine fails if asyncio debug mode is enabled and wrapped function don't have "__name__" attribute In-Reply-To: <1447764440.4.0.175921042664.issue25648@psf.upfronthosting.co.za> Message-ID: <1447782078.59.0.348900988066.issue25648@psf.upfronthosting.co.za> Guido van Rossum added the comment: Fixed in repo is good enough to close an issue. ---------- resolution: -> duplicate status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 12:42:47 2015 From: report at bugs.python.org (Brett Cannon) Date: Tue, 17 Nov 2015 17:42:47 +0000 Subject: [issue25643] Python tokenizer rewriting In-Reply-To: <1447723653.14.0.424824913135.issue25643@psf.upfronthosting.co.za> Message-ID: <1447782167.79.0.0366618815189.issue25643@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 12:59:00 2015 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 17 Nov 2015 17:59:00 +0000 Subject: [issue25612] nested try..excepts don't work correctly for generators In-Reply-To: <1447361959.0.0.839122121456.issue25612@psf.upfronthosting.co.za> Message-ID: <1447783140.65.0.734581363903.issue25612@psf.upfronthosting.co.za> Yury Selivanov added the comment: Can someone work with me on fixing this issue? I think it's important to ship 3.5.1 with this resolved (and 3.4.4 FWIW). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 13:18:01 2015 From: report at bugs.python.org (JGoutin) Date: Tue, 17 Nov 2015 18:18:01 +0000 Subject: [issue25646] Distutils and Windows SDK 7.0 / Windows SDK 7.1 / Visual C++ Build Tools 2015 In-Reply-To: <1447756303.67.0.435034104806.issue25646@psf.upfronthosting.co.za> Message-ID: <1447784281.94.0.124593028939.issue25646@psf.upfronthosting.co.za> JGoutin added the comment: For SDK 7.1, with "DISTUTILS_USE_SDK=1" (And "MSSdk=1"), I still have the problem. The error is on "include", "lib", "libpath", "path" environment variables which are not set by "vcvarsall.bat" (And are difficult to set manually). I looked on "msvc9compiler.py" file, I see that DISTUTILS_USE_SDK set the names for some compiler executables but not these variables. A solution should be to call "SetEnv.cmd" in place of "vcvarsall.bat" if SDK is installed and if environment variables listed above are missing even after the call of "vcvarsall.bat" (Or if "vcvarsall.bat" is missing). "SetEnv.cmd" properly set the environment and I successfully compiled files after launched it. I can do this change and commit it. This will add fully automatic compatibility for SDK 6.1/7.0/7.1, so all possibles version for VC++2008 and 2010 (Is it also possible to add "vcbuildtools.bat" for VC++ Build Tools 2015, but you say it's already fixed for it.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 13:36:23 2015 From: report at bugs.python.org (Emanuel Barry) Date: Tue, 17 Nov 2015 18:36:23 +0000 Subject: [issue25650] Mismatching documentation <=> behaviour for typing.Any Message-ID: <1447785383.67.0.0503638677753.issue25650@psf.upfronthosting.co.za> New submission from Emanuel Barry: The docstring for typing.Any specifically says "- Any object is an instance of Any."; in practice however it's not actually the case, as isinstance(x, Any) raises a TypeError. AnyMeta makes this behaviour seem intentional, however the official documentation seems to be a bit vague on that one too -- https://docs.python.org/3/library/typing.html#the-any-type makes no mention of 'isinstance', but just the next paragraph mirrors the docstring, in 'Any object is an instance of Any'. I personally believe this is a behaviour error and the docs are correct, as that seems the most logical conclusion. Should this be fixed for 3.5.1? ---------- components: Library (Lib) messages: 254811 nosy: ebarry priority: normal severity: normal status: open title: Mismatching documentation <=> behaviour for typing.Any versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 13:52:18 2015 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 17 Nov 2015 18:52:18 +0000 Subject: [issue25612] nested try..excepts don't work correctly for generators In-Reply-To: <1447783140.65.0.734581363903.issue25612@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: You might have to ping python-dev. But in terms of priorities I think it's not a blocker -- it's been broken for quite some time now, and it's a fairly odd corner of the language. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 13:58:28 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Tue, 17 Nov 2015 18:58:28 +0000 Subject: [issue25485] Add a context manager to telnetlib.Telnet In-Reply-To: <1445883619.21.0.032521861016.issue25485@psf.upfronthosting.co.za> Message-ID: <1447786708.36.0.823294653179.issue25485@psf.upfronthosting.co.za> St?phane Wirtel added the comment: Should I develop a mock telnet server for the unittest ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 14:52:56 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 17 Nov 2015 19:52:56 +0000 Subject: [issue25485] Add a context manager to telnetlib.Telnet In-Reply-To: <1445883619.21.0.032521861016.issue25485@psf.upfronthosting.co.za> Message-ID: <1447789976.54.0.557270011801.issue25485@psf.upfronthosting.co.za> R. David Murray added the comment: The existing tests seem to have at least some infrastructure that would apply here, so figuring out how to use/extend that is better than writing new code, I'd say. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 16:36:40 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 17 Nov 2015 21:36:40 +0000 Subject: [issue25612] nested try..excepts don't work correctly for generators In-Reply-To: <1447361959.0.0.839122121456.issue25612@psf.upfronthosting.co.za> Message-ID: <1447796200.64.0.675233296293.issue25612@psf.upfronthosting.co.za> Martin Panter added the comment: Regarding the second bug, did you consider that the exception thrown to the generator can already have __context__ set? try: try: raise ValueError("Context outside of generator") except ValueError as ex: raise SubError() from ex except SubError as ex: coro.throw(ex) # ex.__context__ is a ValueError I guess either one context could trump the other, or we could to follow the chain of contexts and append the other chain at the end. Both these ideas seem a bit ugly though. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 17:07:01 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 17 Nov 2015 22:07:01 +0000 Subject: [issue20468] resource module documentation is incorrect In-Reply-To: <1391208641.83.0.141932054107.issue20468@psf.upfronthosting.co.za> Message-ID: <1447798021.68.0.11013839654.issue20468@psf.upfronthosting.co.za> Martin Panter added the comment: Python?s getrusage() calls the C-level getrusage() function. Man pages for reference: http://man7.org/linux/man-pages/man2/getrusage.2.html https://www.freebsd.org/cgi/man.cgi?query=getrusage&sektion=2 https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man2/getrusage.2.html I find ?kilobytes? ambiguous, since it probably means ?kibibytes?, multiples of 1024 bytes, rather than 1000 bytes. Maybe it would be best to just say the unit varies by platform, and let the user check the manuals themself. I agree about dropping the text from getpagesize() though. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 17:20:07 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 17 Nov 2015 22:20:07 +0000 Subject: [issue24172] Errors in resource.getpagesize module documentation In-Reply-To: <1431498092.42.0.745658320728.issue24172@psf.upfronthosting.co.za> Message-ID: <1447798807.28.0.225967997757.issue24172@psf.upfronthosting.co.za> Martin Panter added the comment: The documentation already says to consult the getrusage(2) man page. Regarding the getpagesize() API, Python?s implementation actually falls back to Posix?s sysconf(). Perhaps it should prefer sysconf() over getpagesize(), but that would be a separate issue. Anyway I will commit the important half of the Issue 20468?s patch, so I think we can close this. ---------- nosy: +martin.panter resolution: -> duplicate stage: needs patch -> resolved status: open -> closed superseder: -> resource module documentation is incorrect versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 17:43:22 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 17 Nov 2015 22:43:22 +0000 Subject: [issue20468] resource module documentation is incorrect In-Reply-To: <1391208641.83.0.141932054107.issue20468@psf.upfronthosting.co.za> Message-ID: <20151117224319.14357.11051@psf.io> Roundup Robot added the comment: New changeset 5e8b06ac7c97 by Martin Panter in branch '3.4': Issue #20468: Remove incorrect information about maxrss and page size https://hg.python.org/cpython/rev/5e8b06ac7c97 New changeset 1579de0b72f6 by Martin Panter in branch '3.5': Issue #20468: Merge getpagesize doc from 3.4 into 3.5 https://hg.python.org/cpython/rev/1579de0b72f6 New changeset 007dfc0ef1be by Martin Panter in branch 'default': Issue #20468: Merge getpagesize doc from 3.5 https://hg.python.org/cpython/rev/007dfc0ef1be New changeset 58d017d70563 by Martin Panter in branch '2.7': Issue #20468: Remove incorrect information about maxrss and page size https://hg.python.org/cpython/rev/58d017d70563 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 17:59:46 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 17 Nov 2015 22:59:46 +0000 Subject: [issue20468] resource module documentation is incorrect In-Reply-To: <1391208641.83.0.141932054107.issue20468@psf.upfronthosting.co.za> Message-ID: <1447801186.33.0.801862856419.issue20468@psf.upfronthosting.co.za> Martin Panter added the comment: I committed the text removal for getpagesize(). For the getrusage() table, I wonder if it is good enough as it already is. Otherwise, it opens questions about the units for all the other fields, and which platforms they are supported on. ---------- versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 18:20:01 2015 From: report at bugs.python.org (Mouse) Date: Tue, 17 Nov 2015 23:20:01 +0000 Subject: [issue25495] binascii documentation incorrect In-Reply-To: <1445987417.55.0.122139453671.issue25495@psf.upfronthosting.co.za> Message-ID: <1447802401.67.0.98311322486.issue25495@psf.upfronthosting.co.za> Mouse added the comment: Status...? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 18:27:24 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 17 Nov 2015 23:27:24 +0000 Subject: [issue25612] nested try..excepts don't work correctly for generators In-Reply-To: <1447796200.64.0.675233296293.issue25612@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > Can someone work with me on fixing this issue? I think it's important to ship 3.5.1 with this resolved (and 3.4.4 FWIW). It don't consider this issue as a blocker for Python 3.5.1. This release already contains a *lot* of bugfixes! It's important to get it as soon as possible. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 18:36:15 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 17 Nov 2015 23:36:15 +0000 Subject: [issue25612] nested try..excepts don't work correctly for generators In-Reply-To: <1447361959.0.0.839122121456.issue25612@psf.upfronthosting.co.za> Message-ID: <1447803375.04.0.450532302556.issue25612@psf.upfronthosting.co.za> Martin Panter added the comment: Thinking about the __context__ thing some more, I guess it might make sense for __context__ to be overwritten by the generator context. The same way it gets overwritten when you execute ?raise? inside an exception handler. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 18:52:34 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 17 Nov 2015 23:52:34 +0000 Subject: [issue25589] test_ascii_formatd fails on Mac when built with Intel compiler In-Reply-To: <1447093853.5.0.154282338345.issue25589@psf.upfronthosting.co.za> Message-ID: <1447804354.33.0.715179504286.issue25589@psf.upfronthosting.co.za> R. David Murray added the comment: We've figured out that the difference is the optimization level. Without --with-pydebug, I can reproduce the failure. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 19:00:32 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 18 Nov 2015 00:00:32 +0000 Subject: [issue14911] generator.throw() documentation inaccurate In-Reply-To: <1337943736.85.0.146138312281.issue14911@psf.upfronthosting.co.za> Message-ID: <1447804832.03.0.781667481662.issue14911@psf.upfronthosting.co.za> Martin Panter added the comment: I can?t really comment on the 2.7 version, because I?m not too familiar with Python 2 exceptions. For Python 3, is there any reason to bless the None, tuple or non-exception cases as the exception ?value? argument? IMO these just make things too complicated without any benefit. Changes I would make to the patch: * Only mention that ?value? can be omitted, or it can be an instance of the class specified by ?type?. Drop mentioning the None option, and the single or tuple constructor argument options. It looks like the tuple option actually gets expanded to multiple constructor arguments?! * Mention that if ?value? is passed, its traceback could be lost * Drop the example, unless someone can come up with a concise and realistic example * Unify with definition for coroutines * Change the doc string(s) to match the argument names, but don?t bother copying the full definition text ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 19:52:06 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 18 Nov 2015 00:52:06 +0000 Subject: [issue5784] raw deflate format and zlib module In-Reply-To: <1240006221.86.0.263428051867.issue5784@psf.upfronthosting.co.za> Message-ID: <1447807926.72.0.191120215975.issue5784@psf.upfronthosting.co.za> Martin Panter added the comment: Looking at the current zlib module source code, I confirmed that wbits is passed directly to the deflateInit2(windowBits) and inflateInit2(windowBits) parameters. So the following modes could also be added to the documentation for decompression: * Zero: automatically determine size from zlib header * 32 + logarithm: automatically accept either a zlib or gzip header Also, the compressobj() doc string is out of date. It mentions 8?15 but none of the other options. Paul: Perhaps it would be better to say ?wbits? corresponds to the format of the stream, rather than mentioning just the window size as currently proposed. Then hopefully the reader would look to see what value is needed for the raw Deflate format. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 20:34:52 2015 From: report at bugs.python.org (Omar Diab) Date: Wed, 18 Nov 2015 01:34:52 +0000 Subject: [issue18848] In unittest.TestResult .startTestRun() and .stopTestRun() methods don't work In-Reply-To: <1377586130.68.0.700857287739.issue18848@psf.upfronthosting.co.za> Message-ID: <1447810492.89.0.625871066666.issue18848@psf.upfronthosting.co.za> Omar Diab added the comment: I found out about this while writing my own test runner, and investigated it in an answer to a StackOverflow question here: https://stackoverflow.com/questions/32920025/how-do-i-use-unittest-testresult/33770125#33770125 The startTestRun() method is supposed to be called at the beginning of a test run. That mostly works, but if you run a TestCase.run() method?or TestSuite.run(), because it just calls TestCase.run()?it will only call that method if you don't provide a TestResult instance. That means the lifecycle method is useless in those cases, because the default TestResult.startTestRun() method is a no-op. This is how unittest.TestCase.run() starts: def run(self, result=None): orig_result = result if result is None: result = self.defaultTestResult() startTestRun = getattr(result, 'startTestRun', None) if startTestRun is not None: startTestRun() # ... The branch for calling startTestRun() is inside the `if result is None` check, making it never get called with an implementation of startTestRun(). This is currently mitigatable by just calling startTestRun() manually. But the documentation makes it seem like this lifecycle method should be called automatically, when it is not. ---------- nosy: +Omar Diab _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 21:34:13 2015 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 18 Nov 2015 02:34:13 +0000 Subject: [issue25651] Confusing output for TestCase.subTest(0) Message-ID: <1447814053.14.0.516761369725.issue25651@psf.upfronthosting.co.za> New submission from Ezio Melotti: When a single positional argument is passed to subTest(), if the argument is false, its value won't be displayed in the output -- () will appear instead: >>> import unittest >>> class NumbersTest(unittest.TestCase): ... def test_odd(self): ... for i in range(4): ... with self.subTest(i): # single positional arg ... self.assertNotEqual(i%2, 0) ... >>> unittest.main(exit=False) ====================================================================== FAIL: test_odd (__main__.NumbersTest) () ---------------------------------------------------------------------- Traceback (most recent call last): File "", line 5, in test_odd AssertionError: 0 == 0 ====================================================================== FAIL: test_odd (__main__.NumbersTest) [2] ---------------------------------------------------------------------- Traceback (most recent call last): File "", line 5, in test_odd AssertionError: 0 == 0 ---------------------------------------------------------------------- Ran 1 test in 0.001s FAILED (failures=2) This is because subTest() accepts a positional "msg" arg, passes it to _SubTest (Lib/unittest/case.py:515), and then _SubTest checks using "if self._message:" (Lib/unittest/case.py:1400). I think it would be better to check the message against a sentinel value instead. ---------- components: Library (Lib) keywords: easy messages: 254827 nosy: ezio.melotti, michael.foord, pitrou, rbcollins priority: normal severity: normal stage: test needed status: open title: Confusing output for TestCase.subTest(0) type: behavior versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 21:59:12 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 18 Nov 2015 02:59:12 +0000 Subject: [issue23200] Clarify max_length and flush() for zlib decompression In-Reply-To: <1420766781.53.0.179588350228.issue23200@psf.upfronthosting.co.za> Message-ID: <20151118025909.4679.32162@psf.io> Roundup Robot added the comment: New changeset 106c49edbb12 by Martin Panter in branch '2.7': Issue #23200: Document that max_length=0 is not supported https://hg.python.org/cpython/rev/106c49edbb12 New changeset 660bdfaada64 by Martin Panter in branch '3.4': Issue #23200: Document that max_length=0 is not supported https://hg.python.org/cpython/rev/660bdfaada64 New changeset d64bb25cf797 by Martin Panter in branch '3.5': Issue #23200: Merge zlib doc from 3.4 into 3.5 https://hg.python.org/cpython/rev/d64bb25cf797 New changeset cdd403dd82cb by Martin Panter in branch 'default': Issue #23200: Merge zlib doc from 3.5 https://hg.python.org/cpython/rev/cdd403dd82cb ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 23:42:25 2015 From: report at bugs.python.org (Ethan Furman) Date: Wed, 18 Nov 2015 04:42:25 +0000 Subject: [issue25594] enum instance attribute access possible In-Reply-To: <1447144067.5.0.526378354242.issue25594@psf.upfronthosting.co.za> Message-ID: <1447821745.03.0.044603478396.issue25594@psf.upfronthosting.co.za> Ethan Furman added the comment: Changed the wording slightly to indicate that looking up members on other members is a bad idea. ---------- Added file: http://bugs.python.org/file41064/issue25594.stoneleaf.04.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 00:16:09 2015 From: report at bugs.python.org (Jonathan Goble) Date: Wed, 18 Nov 2015 05:16:09 +0000 Subject: [issue25652] collections.UserString.__rmod__() raises NameError Message-ID: <1447823769.89.0.495006915909.issue25652@psf.upfronthosting.co.za> New submission from Jonathan Goble: In an instance of collections.UserString, any call to the __rmod__() method will raise NameError, due to the undefined "args" name in the method. ---------- components: Library (Lib) messages: 254830 nosy: Jonathan Goble, rhettinger priority: normal severity: normal status: open title: collections.UserString.__rmod__() raises NameError type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 01:03:04 2015 From: report at bugs.python.org (Armin Rigo) Date: Wed, 18 Nov 2015 06:03:04 +0000 Subject: [issue25653] ctypes+callbacks+fork+selinux = crash Message-ID: <1447826584.36.0.973987165664.issue25653@psf.upfronthosting.co.za> New submission from Armin Rigo: Ctypes uses libffi's `ffi_closure_alloc()`, which has a bug that make existing applications obscurely crash in one situation: if we are running on SELinux, making use of callbacks, and forking. This is because `ffi_closure_alloc()` will detect that it is running on SELinux and use an alternative way to allocate memory for the callbacks. It does that because selinux won't let a process mmap() any anonymous read-write-execute memory (at least in some settings; but libffi always uses the workaround if selinux is detected). The workaround is to create a temporary file and mmap() it twice (at randomly different addresses), once as a read-write mapping and once as a read-execute mapping. However, the internal structure of libffi requires that this mapping be MAP_SHARED (we can't easily first build the memory content, then write it to the temporary file and mmap() that fixed content in executable memory). The problem with this is that if the process forks, this memory is shared. If one of the two processes then frees the callback, the memory becomes garbage in the other process. The problem was reported a few times at various places already, but not in this bug tracker. See: https://sourceware.org/ml/libffi-discuss/2009/msg00320.html https://bugzilla.redhat.com/show_bug.cgi?id=531233 https://bugzilla.redhat.com/show_bug.cgi?id=707944 I am adding this issue to Python's bug tracker because, while in theory a libffi issue, it seems that Python is one of the very few libffi users that actually frees callbacks in this way. I don't have a solution for either libffi or ctypes, though. My own recommendation would be to stop using ``ffi_closure_alloc()`` and let the application either work (on selinux without deny_execmem) or cleanly trigger an error (on selinux with deny_execmem). For reference, the issue was reported to CFFI's bug tracker about python-cryptography 1.0: it uses cffi's version of callbacks, whose implementation is close to ctypes', except not using ``ffi_closure_alloc()`` and so hitting the original selinux error instead of a crash. The file https://bitbucket.org/cffi/cffi/raw/default/c/malloc_closure.h inside CFFI comes from an older version of ctypes which (by chance in this case) does not call ``ffi_closure_alloc()``. ---------- components: ctypes messages: 254831 nosy: arigo priority: normal severity: normal status: open title: ctypes+callbacks+fork+selinux = crash type: crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 01:38:56 2015 From: report at bugs.python.org (Jonathan Goble) Date: Wed, 18 Nov 2015 06:38:56 +0000 Subject: [issue25652] collections.UserString.__rmod__() raises NameError In-Reply-To: <1447823769.89.0.495006915909.issue25652@psf.upfronthosting.co.za> Message-ID: <1447828736.74.0.00872108846604.issue25652@psf.upfronthosting.co.za> Jonathan Goble added the comment: c06b2480766d appears to be the offending changeset. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 01:49:03 2015 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 18 Nov 2015 06:49:03 +0000 Subject: [issue25652] collections.UserString.__rmod__() raises NameError In-Reply-To: <1447823769.89.0.495006915909.issue25652@psf.upfronthosting.co.za> Message-ID: <1447829343.98.0.861921671491.issue25652@psf.upfronthosting.co.za> Xiang Zhang added the comment: It seems this is a typo. The args should be self.data. And since unicodeobject doesn't support __rmod__, at least I think we should str(format) or remove __rmod__ totally. I attach a patch. ---------- nosy: +xiang.zhang Added file: http://bugs.python.org/file41065/collections.UserString _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 02:13:48 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 18 Nov 2015 07:13:48 +0000 Subject: [issue25654] test_multiprocessing_spawn ResourceWarning with -Werror Message-ID: <1447830828.22.0.981390741581.issue25654@psf.upfronthosting.co.za> New submission from Martin Panter: Running the test suite with -Werror enabled causes test_multiprocessing_spawn to print out lots of unhandled errors from the garbage collector, and one of these causes a test failure. It looks like there are lots of files that should be explicitly closed rather than leaving them for the garbage collector. Also, one error occurred _after_ the test command had exiting. That can?t be a good thing, though I have never used the multiprocessing module so maybe this is unavoidable. $ ./python -Werror -m unittest -v test.test_multiprocessing_spawn . . . ====================================================================== FAIL: test_sys_exit (test.test_multiprocessing_spawn.WithProcessesTestSubclassingProcess) ---------------------------------------------------------------------- Traceback (most recent call last): File "/media/disk/home/proj/python/cpython/Lib/test/_test_multiprocessing.py", line 483, in test_sys_exit self.assertEqual(f.read().rstrip(), str(reason)) AssertionError: "[1, 2, 3]\nException ignored in: <_io.Fi[136 chars]-8'>" != '[1, 2, 3]' - [1, 2, 3] ? - + [1, 2, 3]- Exception ignored in: <_io.FileIO name='/dev/null' mode='rb' closefd=True> - ResourceWarning: unclosed file <_io.TextIOWrapper name='/dev/null' mode='r' encoding='UTF-8'> ---------------------------------------------------------------------- Ran 265 tests in 151.904s FAILED (failures=1, skipped=15) [Exit 1] $ Exception ignored in: <_io.FileIO name='/dev/null' mode='rb' closefd=True> ResourceWarning: unclosed file <_io.TextIOWrapper name='/dev/null' mode='r' encoding='UTF-8'> ---------- components: Tests messages: 254834 nosy: martin.panter priority: normal severity: normal status: open title: test_multiprocessing_spawn ResourceWarning with -Werror type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 02:19:37 2015 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 18 Nov 2015 07:19:37 +0000 Subject: [issue25652] collections.UserString.__rmod__() raises NameError In-Reply-To: <1447823769.89.0.495006915909.issue25652@psf.upfronthosting.co.za> Message-ID: <1447831177.6.0.0949209950822.issue25652@psf.upfronthosting.co.za> Xiang Zhang added the comment: Quite sorry for making some mistakes. unicodeobject does get a __radd__ method. It is added by addoperators though I cannot see it in PyNumberMethods. Now I think just fixing the typo is enough. ---------- Added file: http://bugs.python.org/file41066/collections.UserString1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 02:44:01 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 18 Nov 2015 07:44:01 +0000 Subject: =?utf-8?q?=5Bissue23200=5D_Deprecate_the_zlib_decompressor=E2=80=99s_flus?= =?utf-8?q?h=28=29_method?= In-Reply-To: <1420766781.53.0.179588350228.issue23200@psf.upfronthosting.co.za> Message-ID: <1447832641.32.0.29445730655.issue23200@psf.upfronthosting.co.za> Martin Panter added the comment: See Issue 224981 (bug) and Issue 403373 (patch) about the Z_SYNC_FLUSH change (the numbers in the commit message are different and do not work). I committed my doc change to 2.7 and 3.4+, which leaves the main problem of what to do about flush(). I propose deprecate-flush.patch for 3.6, which deprecates this method. I ran the test suite with -Werror, so I hopefully got all the instances of flush() in the library. ---------- components: +Library (Lib) -Documentation title: Clarify max_length and flush() for zlib decompression -> Deprecate the zlib decompressor?s flush() method versions: +Python 3.6 -Python 3.4 Added file: http://bugs.python.org/file41067/deprecate-flush.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 03:07:07 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 18 Nov 2015 08:07:07 +0000 Subject: =?utf-8?q?=5Bissue23200=5D_Deprecate_the_zlib_decompressor=E2=80=99s_flus?= =?utf-8?q?h=28=29_method?= In-Reply-To: <1420766781.53.0.179588350228.issue23200@psf.upfronthosting.co.za> Message-ID: <1447834027.59.0.372822408092.issue23200@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Besides unconsumed_tail there is an internal buffer. Even if flush() is no longer needed in the zlib decompresser (I don't know), I doubt about bz2 and lzma. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 03:37:03 2015 From: report at bugs.python.org (never-eat-yellow-snow) Date: Wed, 18 Nov 2015 08:37:03 +0000 Subject: [issue25655] Python errors related to failures loading DLL's lack information Message-ID: <1447835823.22.0.872666546521.issue25655@psf.upfronthosting.co.za> New submission from never-eat-yellow-snow: Currently you get errors like this: ImportError: DLL load failed: The specified procedure could not be found. ImportError: DLL load failed: The specified module could not be found. It would be nice to include more information, at least the name of the dll which could not be loaded. Maybe also the name of the (dependent) dll which could not be found. Currently, I use ProcessMonitor to debug which dll could not be found, because the error message is lacking important information. Note: I tagged the two versions I use, but probably all python versions are affected by this issue. ---------- components: Windows messages: 254838 nosy: never-eat-yellow-snow, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Python errors related to failures loading DLL's lack information type: enhancement versions: Python 2.7, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 03:39:46 2015 From: report at bugs.python.org (Chris Withers) Date: Wed, 18 Nov 2015 08:39:46 +0000 Subject: [issue25532] infinite loop when running inspect.unwrap over unittest.mock.call In-Reply-To: <1446421817.99.0.495650724157.issue25532@psf.upfronthosting.co.za> Message-ID: <1447835986.71.0.323669034496.issue25532@psf.upfronthosting.co.za> Chris Withers added the comment: Cool, what needs to happen for __wrapped__ in to be blacklisted in call? Separately, inspect.unwrap probably needs to use something less fragile than a set of ids to track whether it's stuck in a loop. What is the actual usecase for __wrapped__ how deeply nested can those realistically expected to be? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 03:39:47 2015 From: report at bugs.python.org (Marc Schlaich) Date: Wed, 18 Nov 2015 08:39:47 +0000 Subject: [issue10128] multiprocessing.Pool throws exception with __main__.py In-Reply-To: <1287268913.13.0.756366299299.issue10128@psf.upfronthosting.co.za> Message-ID: <1447835987.51.0.463830459886.issue10128@psf.upfronthosting.co.za> Marc Schlaich added the comment: Please see my latest comments to https://github.com/pypa/pip/issues/1891. tl;dr It is related to the -m switch as pip's wheel launcher does PYTHONPATH=script.exe python -m __main__ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 04:28:50 2015 From: report at bugs.python.org (Eryk Sun) Date: Wed, 18 Nov 2015 09:28:50 +0000 Subject: [issue25653] ctypes+callbacks+fork+selinux = crash In-Reply-To: <1447826584.36.0.973987165664.issue25653@psf.upfronthosting.co.za> Message-ID: <1447838930.13.0.863397597986.issue25653@psf.upfronthosting.co.za> Changes by Eryk Sun : ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 06:05:21 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 18 Nov 2015 11:05:21 +0000 Subject: =?utf-8?q?=5Bissue23200=5D_Deprecate_the_zlib_decompressor=E2=80=99s_flus?= =?utf-8?q?h=28=29_method?= In-Reply-To: <1420766781.53.0.179588350228.issue23200@psf.upfronthosting.co.za> Message-ID: <1447844721.63.0.0218206463663.issue23200@psf.upfronthosting.co.za> Martin Panter added the comment: For the bz2 and lzma modules, neither decompressor classes have a flush() method, only the compressors. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 06:13:20 2015 From: report at bugs.python.org (Dmitry Andreychuk) Date: Wed, 18 Nov 2015 11:13:20 +0000 Subject: [issue23661] Setting a exception side_effect on a mock from create_autospec does not work In-Reply-To: <1426293940.15.0.253058774664.issue23661@psf.upfronthosting.co.za> Message-ID: <1447845200.75.0.254093267909.issue23661@psf.upfronthosting.co.za> Dmitry Andreychuk added the comment: python 3.4.3 is also affected. Is it possible to fix this in branch 3.4? ---------- nosy: +and versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 07:20:11 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 18 Nov 2015 12:20:11 +0000 Subject: [issue25654] test_multiprocessing_spawn ResourceWarning with -Werror In-Reply-To: <1447830828.22.0.981390741581.issue25654@psf.upfronthosting.co.za> Message-ID: <1447849211.72.0.295500270263.issue25654@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: sys.stdin is set to open(os.devnull) in multiprocessing.forkserer and multiprocessing.process (see issue5313). At shutdown stage sys.std* streams are restored to sys.__std*__. Here the resource warning is emitted. An example that demonstrates similar issue: $ ./python -We -c 'import sys; sys.stdin = open("/dev/null")' Exception ignored in: <_io.FileIO name='/dev/null' mode='rb' closefd=True> ResourceWarning: unclosed file <_io.TextIOWrapper name='/dev/null' mode='r' encoding='UTF-8'> A workaround is to set sys.__stdin__ as well as sys.stdin. Now a resource warning is no longer emitted at the stage of restoring standard streams, but it can be randomly emitted at the stage of clearing sys dict (depending on the order of deallocating stdin and stderr). The question is why a resource warning is not emitted in normal case, with standard stdin. Proposed patch closes sys.__stdin__ and set it to sys.stdin in multiprocessing, makes standard streams cleanup at shutdown more reliable, and fixes two tests that set sys.stderr. ---------- components: +Interpreter Core, Library (Lib) keywords: +patch nosy: +jnoller, pitrou, serhiy.storchaka stage: -> patch review versions: +Python 2.7, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file41068/cleanup_std_streams.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 09:04:58 2015 From: report at bugs.python.org (Tomer) Date: Wed, 18 Nov 2015 14:04:58 +0000 Subject: [issue25656] multiprocessing.dummy: pool.map hangs on empty list Message-ID: <1447855498.22.0.263851728204.issue25656@psf.upfronthosting.co.za> New submission from Tomer: Hi, In multiprocessing.dummy module I noticed when you send a zero-length iterator to pool.map it hang forever, Code example: import urllib2 from multiprocessing.dummy import Pool as ThreadPool def start_multithreading_urlopen(threads_num): pool = ThreadPool(threads_num) results = pool.map(urllib2.urlopen, []) pool.close() pool.join() # hang here print results I think it related to Issue6433 that was fixed on multiprocessing module with simple length check ---------- components: Library (Lib) messages: 254844 nosy: tomer70 priority: normal severity: normal status: open title: multiprocessing.dummy: pool.map hangs on empty list type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 09:48:48 2015 From: report at bugs.python.org (serge-sans-paille) Date: Wed, 18 Nov 2015 14:48:48 +0000 Subject: [issue25657] virtualenv's activate does not update LD_LIBRARY_PATH Message-ID: <1447858128.82.0.165586856524.issue25657@psf.upfronthosting.co.za> New submission from serge-sans-paille: My use cas of virtual env was the following: 1. create a virtual env 2. install a third party shared library and its python wrapper 3. import the wrapper that itself loads the shared library The problem is that the shared library gets install into /lib (which is a normal behavior) but virtualenv's activate does not update LD_LIBRARY_PATH A possible fix would be to add the following lines into virtualenv's activate: ``` if [ -n "$_OLD_VIRTUAL_LD_LIBRARY_PATH" ] ; then PATH="$_OLD_VIRTUAL_LD_LIBRARY_PATH" export LD_LIBRARY_PATH unset _OLD_VIRTUAL_LD_LIBRARY_PATH fi ``` and a bit later ``` _OLD_VIRTUAL_LD_LIBRARY_PATH="$LD_LIBRARY_PATH" LD_LIBRARY_PATH="$VIRTUAL_ENV/lib:$LD_LIBRARY_PATH" export LD_LIBRARY_PATH ``` in a simialr manner to what is done with `PATH` ---------- messages: 254845 nosy: serge-sans-paille priority: normal severity: normal status: open title: virtualenv's activate does not update LD_LIBRARY_PATH type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 10:43:25 2015 From: report at bugs.python.org (Chris Hogan) Date: Wed, 18 Nov 2015 15:43:25 +0000 Subject: [issue25589] test_ascii_formatd fails on Mac when built with Intel compiler In-Reply-To: <1447093853.5.0.154282338345.issue25589@psf.upfronthosting.co.za> Message-ID: <1447861405.3.0.716446469282.issue25589@psf.upfronthosting.co.za> Changes by Chris Hogan : ---------- resolution: not a bug -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 10:50:16 2015 From: report at bugs.python.org (Ed Schouten) Date: Wed, 18 Nov 2015 15:50:16 +0000 Subject: [issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX Message-ID: <1447861816.88.0.632584646231.issue25658@psf.upfronthosting.co.za> New submission from Ed Schouten: While trying to port Python over to a new platform (CloudABI), I noticed a couple of compiler errors in PyThread_create_key(), PyThread_delete_key(), PyThread_delete_key_value() and PyThread_set_key_value() caused by fact that pthread_key_t is converted to an integer (and vice versa) POSIX doesn't seem to require that pthread_key_t is an integer or any other arithmetic type: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_types.h.html Old revisions of the standard did require pthread_t to be an arithmetic type, but this requirement was dropped later on. In my opinion we should strongly consider changing the API, so that we can treat the key created by pthread_key_create() or returned by TlsAlloc() as an opaque type. ---------- components: Interpreter Core messages: 254846 nosy: EdSchouten priority: normal severity: normal status: open title: PyThread assumes pthread_key_t is an integer, which is against POSIX versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 10:50:45 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 18 Nov 2015 15:50:45 +0000 Subject: [issue25304] Add run_coroutine_threadsafe() to asyncio In-Reply-To: <1443885833.8.0.0767295795531.issue25304@psf.upfronthosting.co.za> Message-ID: <1447861845.95.0.638362101929.issue25304@psf.upfronthosting.co.za> R. David Murray added the comment: I think the 'versionchanged' should say "3.4.4, 3.5.1". We've already had one user confused by the fact that it isn't in 3.5.0. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 11:23:02 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 18 Nov 2015 16:23:02 +0000 Subject: [issue25652] collections.UserString.__rmod__() raises NameError In-Reply-To: <1447823769.89.0.495006915909.issue25652@psf.upfronthosting.co.za> Message-ID: <1447863782.71.0.962198983306.issue25652@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 11:44:18 2015 From: report at bugs.python.org (Jeff Ramnani) Date: Wed, 18 Nov 2015 16:44:18 +0000 Subject: [issue24725] test_socket testFDPassEmpty fails on OS X 10.11 DP with "Cannot allocate memory" In-Reply-To: <1437896131.77.0.341264720465.issue24725@psf.upfronthosting.co.za> Message-ID: <1447865058.86.0.127970085759.issue24725@psf.upfronthosting.co.za> Jeff Ramnani added the comment: I'm still getting these test failures on OS X 10.11.1. Has a radar been filed with Apple? I'd submit one, but I don't know enough about the issue to create a good bug report. In the meantime, I'm attaching a patch to skip these tests as was done in issue #12958. ---------- keywords: +patch nosy: +jramnani Added file: http://bugs.python.org/file41069/issue-24725.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 11:56:26 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 18 Nov 2015 16:56:26 +0000 Subject: [issue25655] Python errors related to failures loading DLL's lack information In-Reply-To: <1447835823.22.0.872666546521.issue25655@psf.upfronthosting.co.za> Message-ID: <1447865786.59.0.648954099168.issue25655@psf.upfronthosting.co.za> Steve Dower added the comment: I don't know that we can necessarily provide correct information for those errors as it depends where they actually fail. If we're simply passing on an error from the loader, then there's very little we can do. We may be able to make an educated guess based on our context, but there's a fairly high chance we'll guess wrong in some cases and make them more difficult to debug (unless you know that the error is only a guess, in which case you're back to procmon or Dependency Walker). You're right that all versions are affected, however I think improving these diagnostics is only within scope for 3.5 and 3.6 at this stage. ---------- versions: +Python 3.5, Python 3.6 -Python 2.7, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 12:45:43 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 18 Nov 2015 17:45:43 +0000 Subject: [issue25304] Add run_coroutine_threadsafe() to asyncio In-Reply-To: <1443885833.8.0.0767295795531.issue25304@psf.upfronthosting.co.za> Message-ID: <1447868743.43.0.0225264829036.issue25304@psf.upfronthosting.co.za> Yury Selivanov added the comment: Good catch! Fixed in https://hg.python.org/cpython/rev/b34c42e46e7b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 12:57:16 2015 From: report at bugs.python.org (Ely Spears) Date: Wed, 18 Nov 2015 17:57:16 +0000 Subject: [issue25659] ctypes.Array.from_buffer segmentation fault when trying to create from array.array Message-ID: <1447869436.37.0.609997226839.issue25659@psf.upfronthosting.co.za> New submission from Ely Spears: I'm trying to find a way to create a ctypes array from the underlying memory buffer exposed by an array.array object. The ctypes.Array.from_buffer function isn't documented, but I did find the source code in _ctypes.c around line 497. It's not clear to me where the problem might be. Code to reproduce it below: import array, ctypes a1 = array.array('l') a1.fromlist(range(10)) ctypes.Array.from_buffer(a1) #Segfault ---------- components: ctypes messages: 254851 nosy: spearsem at gmail.com priority: normal severity: normal status: open title: ctypes.Array.from_buffer segmentation fault when trying to create from array.array type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 14:12:10 2015 From: report at bugs.python.org (Mark Bordas) Date: Wed, 18 Nov 2015 19:12:10 +0000 Subject: [issue15564] cgi.FieldStorage should not call read_multi on files In-Reply-To: <1344245506.28.0.499641288303.issue15564@psf.upfronthosting.co.za> Message-ID: <1447873930.15.0.997120664467.issue15564@psf.upfronthosting.co.za> Mark Bordas added the comment: Was this ever addressed or resolved? I just ran into this bug and it looks like there's a solution, but was never fixed? ---------- nosy: +Mark Bordas versions: +Python 2.7 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 14:17:44 2015 From: report at bugs.python.org (Eryk Sun) Date: Wed, 18 Nov 2015 19:17:44 +0000 Subject: [issue25659] ctypes.Array.from_buffer segmentation fault when trying to create from array.array In-Reply-To: <1447869436.37.0.609997226839.issue25659@psf.upfronthosting.co.za> Message-ID: <1447874264.7.0.548804167734.issue25659@psf.upfronthosting.co.za> Eryk Sun added the comment: You have to subclass ctypes.Array with a _type_ and _length_. But ctypes types also implement sequence repetition (*) to facilitate creating array types. For example: import array, ctypes a1 = array.array('l') a1.fromlist(range(10)) c1 = (ctypes.c_long * 10).from_buffer(a1) >>> c1[:] [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> c1[0] = 42 >>> a1[0] 42 That said, it's way too easy to segfault this. Why not simply fail the call in this case? e.g. StgDictObject *dict = PyType_stgdict(type); if (!dict) { PyErr_SetString(PyExc_TypeError, "abstract class"); return NULL; } ---------- nosy: +eryksun versions: +Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 14:31:36 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 18 Nov 2015 19:31:36 +0000 Subject: [issue25612] nested try..excepts don't work correctly for generators In-Reply-To: <1447361959.0.0.839122121456.issue25612@psf.upfronthosting.co.za> Message-ID: <1447875096.74.0.403370213334.issue25612@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Thinking about the __context__ thing some more, I guess it might make sense for __context__ to be overwritten by the generator context. The same way it gets overwritten when you execute ?raise? inside an exception handler. Not sure I understand what you're saying here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 14:58:50 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 18 Nov 2015 19:58:50 +0000 Subject: [issue25660] tabs don't work correctly in python repl Message-ID: <1447876730.91.0.918964104484.issue25660@psf.upfronthosting.co.za> New submission from Yury Selivanov: When Python is compiled with readline, repeatedly pressing key in repl breaks the repl prompt. Below is what I see when I hit 4 times. yury at ysmac ~/dev/py/cpython $ ./python.exe Python 3.5.0+ (3.5:4ae62ddf7bc7+, Nov 18 2015, 14:52:57) [GCC 4.2.1 Compatible Apple LLVM 7.0.0 (clang-700.1.76)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> >>> >>> >>> Reproducible when Python is built from source on latest OS X. Works OK when installed from MacPorts. Further, if I add PyOS_ReadlineFunctionPointer = PyOS_StdioReadline; in PyOS_Readline in myreadline.c, everything works as expected, so I think this is a readline bug. ---------- components: Interpreter Core messages: 254855 nosy: r.david.murray, serhiy.storchaka, yselivanov priority: high severity: normal status: open title: tabs don't work correctly in python repl versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 15:14:30 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 18 Nov 2015 20:14:30 +0000 Subject: [issue25660] tabs don't work correctly in python repl In-Reply-To: <1447876730.91.0.918964104484.issue25660@psf.upfronthosting.co.za> Message-ID: <1447877670.91.0.815382644813.issue25660@psf.upfronthosting.co.za> R. David Murray added the comment: This was reported (on twitter) by David Beazly as well, as applying to the OSX downloaded from python.org. It works fine on linux for me. Is it readline-version dependent, or a bug in the readline shipped with OSX? ---------- components: +Macintosh nosy: +ned.deily, ronaldoussoren type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 16:13:27 2015 From: report at bugs.python.org (Blake Hilliard) Date: Wed, 18 Nov 2015 21:13:27 +0000 Subject: [issue25661] tokenize.untokenize does not maintain the order of tabbed indentations and leading spaces Message-ID: <1447881207.88.0.934848299376.issue25661@psf.upfronthosting.co.za> New submission from Blake Hilliard: Here's a simple test case that shows the bug: # python Python 2.7.9 (default, Apr 2 2015, 14:49:18) [GCC 4.9.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import StringIO, tokenize >>> code = "if False:\n\tx=3\n \ty=3\n" >>> g = list(tokenize.generate_tokens(StringIO.StringIO(code).readline)) >>> assert tokenize.untokenize(g) == code Traceback (most recent call last): File "", line 1, in AssertionError This is very similar to: https://bugs.python.org/issue20387 I'm using the patch that was provided to fix that bug, but with the patch this slightly different test case still fails. On the last line of "code" from my example, where the line begins with a single space then a tab, the untokenized string reverses the order, and the tab precedes the space. This generates code that will throw an IndentationError if run. ---------- components: Library (Lib) messages: 254857 nosy: Blake Hilliard priority: normal severity: normal status: open title: tokenize.untokenize does not maintain the order of tabbed indentations and leading spaces type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 17:22:02 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 18 Nov 2015 22:22:02 +0000 Subject: [issue25612] nested try..excepts don't work correctly for generators In-Reply-To: <1447361959.0.0.839122121456.issue25612@psf.upfronthosting.co.za> Message-ID: <1447885322.18.0.299336827973.issue25612@psf.upfronthosting.co.za> Martin Panter added the comment: I was making an analogy between how the ?raise? statement works, and how the throw() method could work. In this example, there are three exception objects (MainError, SubError, and ValueError). I was suggesting that it is okay for the context to be set to the MainError instance, because that is how the analogous version using a ?raise? statement works. def main(): try: raise MainError("Context inside generator") except MainError: yield # __context__ could be changed to MainError coro = main() coro.send(None) try: try: raise ValueError("Context outside of generator") except ValueError: raise SubError() except SubError as ex: coro.throw(ex) # __context__ is ValueError # raise analogy: try: try: raise ValueError("Context outside of generator") except ValueError as ex: raise SubError() except SubError as ex: saved = ex # __context__ is ValueError try: raise MainError("Context inside generator") except MainError: raise saved # Changes __context__ to MainError === Sorry I?m not really familiar with the code to quickly propose a patch or review your change though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 17:27:23 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 18 Nov 2015 22:27:23 +0000 Subject: [issue25660] tabs don't work correctly in python repl In-Reply-To: <1447876730.91.0.918964104484.issue25660@psf.upfronthosting.co.za> Message-ID: <1447885643.41.0.0184249973313.issue25660@psf.upfronthosting.co.za> Martin Panter added the comment: Is this related to the BSD editline library (libedit), or is the actual Gnu Readline library being used? Apparently you can check for "libedit" in readline.__doc__ to tell the difference. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 17:36:51 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 18 Nov 2015 22:36:51 +0000 Subject: [issue25660] tabs don't work correctly in python repl In-Reply-To: <1447876730.91.0.918964104484.issue25660@psf.upfronthosting.co.za> Message-ID: <1447886211.11.0.0775638452681.issue25660@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Is this related to the BSD editline library (libedit), or is the actual Gnu Readline library being used? Apparently you can check for "libedit" in readline.__doc__ to tell the difference. Great suggestion. So on my machine, macports version (no bug) is built against readline; manual build from source -- libedit. So apparently, this is a libedit thing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 17:46:01 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 18 Nov 2015 22:46:01 +0000 Subject: [issue25637] Move non-collections-related ABCs out of collections.abc In-Reply-To: <1447701682.74.0.653642972551.issue25637@psf.upfronthosting.co.za> Message-ID: <1447886761.83.0.490308164035.issue25637@psf.upfronthosting.co.za> Yury Selivanov added the comment: > I guess is the objection of putting concrete ABCs in the abc module is that the abc module contains the actual code to implement ABCs and not ABCs themselves. I think it's a rather weak objection. Having some basic (and fundamental!) ABCs defined along with ABCMeta won't hurt. > Personally I would be fine with a submodule within abc like abc.interfaces. > Personally I'm starting to warm to the idea of sticking ABCs in proper packages as e.g. functools.abc for Callable; namespaces are one honking great idea after all. :) It will be hard to find proper namespace for things like Hashable and Awaitable. That's why I like the idea of putting them in the top-level 'abc' module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 18:07:58 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 18 Nov 2015 23:07:58 +0000 Subject: [issue20387] tokenize/untokenize roundtrip fails with tabs In-Reply-To: <1390603875.19.0.598751073352.issue20387@psf.upfronthosting.co.za> Message-ID: <1447888078.53.0.599013829684.issue20387@psf.upfronthosting.co.za> Martin Panter added the comment: It seems the problem with tabs in the indentation is fixed. Can we close this? For the problem with tabs between tokens in a line, I think that would be better handled in separate report. But I suspect it is at worst a documentation problem. You can?t guarantee that you can reconstruct the exact source based off just the tokenized tokens. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 19:03:26 2015 From: report at bugs.python.org (Chesqa Yen) Date: Thu, 19 Nov 2015 00:03:26 +0000 Subject: [issue25662] _tkinter.TclError: bad event type or keysym "Alt" Message-ID: <1447891406.93.0.234833254631.issue25662@psf.upfronthosting.co.za> New submission from Chesqa Yen: For a while now my python IDLE has not been working, mostly due to me trying and failing to reconfigure the button assignment to tailor me. Now when i try to open idle it does not open. I tried using some sites for help (http://www.gossamer-threads.com/lists/python/bugs/901999) which had a similar error however, even with a new config file it still wasn't working. Please could I get some help as I need python running on my laptop to do my university coursework. I've attached a file with the error message from cmd.exe and will paste it again; C:\Users\Francesca>C:\Users\Francesca\AppData\Local\Programs\Python\Python35-32\ Lib\idlelib\idle.py Traceback (most recent call last): File "C:\Users\Francesca\AppData\Local\Programs\Python\Python35-32\Lib\idlelib \idle.py", line 11, in idlelib.PyShell.main() File "C:\Users\Francesca\AppData\Local\Programs\Python\Python35-32\Lib\idlelib \PyShell.py", line 1560, in main shell = flist.open_shell() File "C:\Users\Francesca\AppData\Local\Programs\Python\Python35-32\Lib\idlelib \PyShell.py", line 320, in open_shell self.pyshell = PyShell(self) File "C:\Users\Francesca\AppData\Local\Programs\Python\Python35-32\Lib\idlelib \PyShell.py", line 867, in __init__ OutputWindow.__init__(self, flist, None, None) File "C:\Users\Francesca\AppData\Local\Programs\Python\Python35-32\Lib\idlelib \OutputWindow.py", line 16, in __init__ EditorWindow.__init__(self, *args) File "C:\Users\Francesca\AppData\Local\Programs\Python\Python35-32\Lib\idlelib \EditorWindow.py", line 167, in __init__ self.apply_bindings() File "C:\Users\Francesca\AppData\Local\Programs\Python\Python35-32\Lib\idlelib \EditorWindow.py", line 1097, in apply_bindings text.event_add(event, *keylist) File "C:\Users\Francesca\AppData\Local\Programs\Python\Python35-32\Lib\idlelib \MultiCall.py", line 374, in event_add widget.event_add(self, virtual, seq) File "C:\Users\Francesca\AppData\Local\Programs\Python\Python35-32\Lib\tkinter \__init__.py", line 1503, in event_add self.tk.call(args) _tkinter.TclError: bad event type or keysym "Alt" ---------- components: IDLE files: error file.txt messages: 254863 nosy: ronixx priority: normal severity: normal status: open title: _tkinter.TclError: bad event type or keysym "Alt" type: crash versions: Python 3.5 Added file: http://bugs.python.org/file41070/error file.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 19:06:41 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 19 Nov 2015 00:06:41 +0000 Subject: [issue25654] test_multiprocessing_spawn ResourceWarning with -Werror In-Reply-To: <1447830828.22.0.981390741581.issue25654@psf.upfronthosting.co.za> Message-ID: <1447891601.49.0.152469898407.issue25654@psf.upfronthosting.co.za> Martin Panter added the comment: Perhaps we don?t normally see a warning because stdin normally has closefd=False set? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 19:16:58 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 19 Nov 2015 00:16:58 +0000 Subject: [issue25626] Gzip fails for file over 2**32 bytes In-Reply-To: <1447530501.75.0.968129152166.issue25626@psf.upfronthosting.co.za> Message-ID: <1447892218.36.0.148446634269.issue25626@psf.upfronthosting.co.za> Martin Panter added the comment: I am inclined to commit my patch to get this fixed in the upcoming 3.5.1 release, unless anyone thinks that could be a problem. ---------- components: +Extension Modules _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 19:20:37 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 19 Nov 2015 00:20:37 +0000 Subject: [issue25660] tabs don't work correctly in python repl In-Reply-To: <1447876730.91.0.918964104484.issue25660@psf.upfronthosting.co.za> Message-ID: <1447892437.6.0.103220817302.issue25660@psf.upfronthosting.co.za> Martin Panter added the comment: David Beazley?s description of the bug: ?hitting tab inserts spaces and a carriage return at the same time.? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 19:37:18 2015 From: report at bugs.python.org (Chesqa Yen) Date: Thu, 19 Nov 2015 00:37:18 +0000 Subject: [issue25662] _tkinter.TclError: bad event type or keysym "Alt" In-Reply-To: <1447891406.93.0.234833254631.issue25662@psf.upfronthosting.co.za> Message-ID: <1447893438.25.0.268063421914.issue25662@psf.upfronthosting.co.za> Chesqa Yen added the comment: Under the users .idlerc folder: C:\Users\Francesca\.idlerc edit config-extensions.cfg in notepad (don't select always open with) The code should look like this: [CodeContext] visible = False [ScriptBinding_cfgBindings] run-module = So edited mine to be like this as it was changed to and idle was working again! ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 19:37:53 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 19 Nov 2015 00:37:53 +0000 Subject: [issue25660] tabs don't work correctly in python repl In-Reply-To: <1447876730.91.0.918964104484.issue25660@psf.upfronthosting.co.za> Message-ID: <1447893473.36.0.0398438093957.issue25660@psf.upfronthosting.co.za> Martin Panter added the comment: Applying my patch at Issue 13501, then building with ?autoreconf && ./configure --with-readline=editline?, I can reproduce the funny tab behaviour on Linux. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 19:53:07 2015 From: report at bugs.python.org (Jason R. Coombs) Date: Thu, 19 Nov 2015 00:53:07 +0000 Subject: [issue20387] tokenize/untokenize roundtrip fails with tabs In-Reply-To: <1390603875.19.0.598751073352.issue20387@psf.upfronthosting.co.za> Message-ID: <1447894387.06.0.43348028211.issue20387@psf.upfronthosting.co.za> Changes by Jason R. Coombs : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 20:03:47 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 19 Nov 2015 01:03:47 +0000 Subject: [issue23441] rlcompleter: tab on empty prefix => insert spaces In-Reply-To: <1423650104.74.0.902857510979.issue23441@psf.upfronthosting.co.za> Message-ID: <1447895027.56.0.406157362715.issue23441@psf.upfronthosting.co.za> Martin Panter added the comment: The fix here doesn?t work perfectly with the Editline (libedit) version of Readline; see Issue 25660. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 20:18:17 2015 From: report at bugs.python.org (Larry Hastings) Date: Thu, 19 Nov 2015 01:18:17 +0000 Subject: [issue25612] nested try..excepts don't work correctly for generators In-Reply-To: <1447361959.0.0.839122121456.issue25612@psf.upfronthosting.co.za> Message-ID: <1447895897.54.0.659363836179.issue25612@psf.upfronthosting.co.za> Larry Hastings added the comment: I don't plan to hold up 3.5.1 for this. ---------- priority: release blocker -> normal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 20:32:33 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 19 Nov 2015 01:32:33 +0000 Subject: [issue25660] tabs don't work correctly in python repl In-Reply-To: <1447876730.91.0.918964104484.issue25660@psf.upfronthosting.co.za> Message-ID: <1447896753.08.0.0148359770413.issue25660@psf.upfronthosting.co.za> Martin Panter added the comment: I think this might just be a side effect of the way we abuse the tab completer to insert a literal tab (Issue 23441, revision 82ccdf2df5ac). If I change the code to insert the letter T instead of tabs: if not text.strip('T'): if state == 0: return text + 'T' else: return None I see this behaviour: * Manually type three Ts * Press Tab once, a fourth T is added nicely * Press Tab a second time, it beeps and displays a completion list with a single item, and then completes my line to five Ts * Pressing Tab again repeats the beep, completion list, and appending a T Illustration: >>> TTTT <== Typed T three times, then Tab twice TTTTT <== Completion list from second Tab press >>> TTTTT TTTTTT >>> TTTTTT ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 20:53:09 2015 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 19 Nov 2015 01:53:09 +0000 Subject: [issue10128] multiprocessing.Pool throws exception with __main__.py In-Reply-To: <1287268913.13.0.756366299299.issue10128@psf.upfronthosting.co.za> Message-ID: <1447897989.33.0.359293533923.issue10128@psf.upfronthosting.co.za> Nick Coghlan added the comment: Thanks for the investigation Marc. I'd been hesitant to backport the mitigation patch in #10845 to 2.7.x, (as it *does* represent a behavioural change), but if that code path is currently hitting an assert statement anyway, it seems reasonable to make the change for 2.7.11+ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 21:14:21 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 19 Nov 2015 02:14:21 +0000 Subject: [issue25663] Make rlcompleter avoid duplicate global names Message-ID: <1447899261.09.0.497189339865.issue25663@psf.upfronthosting.co.za> New submission from Martin Panter: When playing with the Editline alternative to Readline, I noticed that ?global? name completions can include duplicates: >>> No None NotADirectoryError( NotImplementedError( None NotImplemented >>> None None None It completed my line to ?None?, but if you hit Tab again, it lists two duplicate options both identical to what I already have. The reason is that ?None? is both a reserved keyword, and a member of the builtins module. My patch avoids adding extra completions if a name has already been added. It also prioritizes the global namespace over builtins, so that say if you alias ?int? to a non-callable, it is no longer listed with an opening bracket ?(? suffix. Earlier behaviour: >>> int = 81 >>> in in input( int int( Now: >>> in in input( int ---------- components: Library (Lib) files: global-dupes.patch keywords: patch messages: 254873 nosy: martin.panter priority: normal severity: normal stage: patch review status: open title: Make rlcompleter avoid duplicate global names type: behavior versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file41071/global-dupes.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 21:41:28 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 19 Nov 2015 02:41:28 +0000 Subject: [issue19217] Calling assertEquals for moderately long list takes too long In-Reply-To: <1381410286.72.0.514206486634.issue19217@psf.upfronthosting.co.za> Message-ID: <1447900888.74.0.385805523857.issue19217@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 21:59:57 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 19 Nov 2015 02:59:57 +0000 Subject: [issue10845] test_multiprocessing failure under Windows In-Reply-To: <1294309581.41.0.731804987161.issue10845@psf.upfronthosting.co.za> Message-ID: <20151119025953.31759.54085@psf.io> Roundup Robot added the comment: New changeset 5d88c1d413b9 by Nick Coghlan in branch '2.7': Close #10128: don't rerun __main__.py in multiprocessing https://hg.python.org/cpython/rev/5d88c1d413b9 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 21:59:57 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 19 Nov 2015 02:59:57 +0000 Subject: [issue10128] multiprocessing.Pool throws exception with __main__.py In-Reply-To: <1287268913.13.0.756366299299.issue10128@psf.upfronthosting.co.za> Message-ID: <20151119025953.31759.94118@psf.io> Roundup Robot added the comment: New changeset 5d88c1d413b9 by Nick Coghlan in branch '2.7': Close #10128: don't rerun __main__.py in multiprocessing https://hg.python.org/cpython/rev/5d88c1d413b9 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 22:08:11 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 19 Nov 2015 03:08:11 +0000 Subject: [issue25533] Make pkgutil.iter_modules() yield built-in modules In-Reply-To: <1446462853.43.0.928344730721.issue25533@psf.upfronthosting.co.za> Message-ID: <1447902491.23.0.411223484207.issue25533@psf.upfronthosting.co.za> Martin Panter added the comment: I did some work on adding support for frozen modules, but I got stuck. The low level is fine: >>> pprint(sys.get_frozen_modules()) # (name, ispkg) pairs (('_frozen_importlib', False), ('_frozen_importlib_external', False), ('__hello__', False), ('__phello__', True), ('__phello__.spam', False)) >>> print("\n".join(map(repr, pkgutil.iter_modules(builtins=True)))) (, '_ast', False) . . . (, 'zipimport', False) (, '_frozen_importlib', False) (, '_frozen_importlib_external', False) (, '__hello__', False) (, '__phello__', True) . . . (FileFinder('.'), 'python-config', False) . . . But the current __hello__ and __phello__ modules print stuff when you import them, which messes with walk_packages(), pydoc, etc: $ ./python -m pydoc -k pkgutil Hello world! Hello world! Hello world! pkgutil - Utilities to support packages. test.test_pkgutil When I stopped these frozen modules from printing on import (as in my current patch), I found this broke the test suite. In particular, test_importlib.frozen.test_loader relies on the printouts to test what gets executed when importing frozen modules. So I am not sure the best way to continue if I am to add support for frozen modules to iter_modules(). Another problem was that there is no way to list submodules of a frozen package unless you know the package?s name. Currently, iter_modules() only sees a path list, which is empty for __phello__. However, I was able to add a special case to walk_packages(None) to include frozen submodules. Some questions: 1. Do people think the general idea of enhancing iter_modules() is worthwhile? 2. Should I try harder to solve the problem with running frozen modules, or is it sensible to just leave out the frozen module support? ---------- Added file: http://bugs.python.org/file41072/iter-builtin-frozen.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 22:12:03 2015 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 19 Nov 2015 03:12:03 +0000 Subject: [issue25472] Typing: Specialized subclasses of generics cannot be unpickled In-Reply-To: <1445742573.23.0.0225018159767.issue25472@psf.upfronthosting.co.za> Message-ID: <1447902723.18.0.351345892356.issue25472@psf.upfronthosting.co.za> Guido van Rossum added the comment: Update: I have not forgotten this, but it's a tough case and I haven't made much progress. I don't think I'll make the deadline for 3.5.1. ---------- assignee: -> gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 23:36:55 2015 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 19 Nov 2015 04:36:55 +0000 Subject: [issue25659] ctypes.Array.from_buffer segmentation fault when trying to create from array.array In-Reply-To: <1447869436.37.0.609997226839.issue25659@psf.upfronthosting.co.za> Message-ID: <1447907815.88.0.141534260639.issue25659@psf.upfronthosting.co.za> Changes by Xiang Zhang <18518281186 at 126.com>: ---------- nosy: +xiang.zhang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 00:01:57 2015 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 19 Nov 2015 05:01:57 +0000 Subject: [issue25472] Typing: Specialized subclasses of generics cannot be unpickled In-Reply-To: <1445742573.23.0.0225018159767.issue25472@psf.upfronthosting.co.za> Message-ID: <1447909317.58.0.452395230215.issue25472@psf.upfronthosting.co.za> Guido van Rossum added the comment: Actually, I just found an embarrassingly simple fix: diff --git a/src/typing.py b/src/typing.py index d900036..49c4a06 100644 --- a/src/typing.py +++ b/src/typing.py @@ -981,7 +981,7 @@ class GenericMeta(TypingMeta, abc.ABCMeta): "Cannot substitute %s for %s in %s" % (_type_repr(new), _type_repr(old), self)) - return self.__class__(self.__name__, self.__bases__, + return self.__class__(self.__name__, (self,) + self.__bases__, dict(self.__dict__), parameters=params, origin=self, I'll go check this in now, together with a test. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 00:14:08 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 19 Nov 2015 05:14:08 +0000 Subject: [issue25472] Typing: Specialized subclasses of generics cannot be unpickled In-Reply-To: <1445742573.23.0.0225018159767.issue25472@psf.upfronthosting.co.za> Message-ID: <20151119051405.4667.15098@psf.io> Roundup Robot added the comment: New changeset 1d37f7dbbb37 by Guido van Rossum in branch '3.5': Issue #25472: In B[], insert B in front of __bases__, to make the __dict__ descriptor work. https://hg.python.org/cpython/rev/1d37f7dbbb37 New changeset 63c261185fc7 by Guido van Rossum in branch 'default': Issue #25472: In B[], insert B in front of __bases__, to make the __dict__ descriptor work. (Merge 3.5->3.6) https://hg.python.org/cpython/rev/63c261185fc7 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 00:20:46 2015 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 19 Nov 2015 05:20:46 +0000 Subject: [issue25472] Typing: Specialized subclasses of generics cannot be unpickled In-Reply-To: <1445742573.23.0.0225018159767.issue25472@psf.upfronthosting.co.za> Message-ID: <1447910446.42.0.452138277057.issue25472@psf.upfronthosting.co.za> Guido van Rossum added the comment: Thanks for the report! Made it before the 3.5.1 (rc1) deadline. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 00:36:22 2015 From: report at bugs.python.org (Zephor Wu) Date: Thu, 19 Nov 2015 05:36:22 +0000 Subject: [issue25664] Unexpected UnicodeDecodeError in logging module Message-ID: <1447911382.32.0.466398267316.issue25664@psf.upfronthosting.co.za> New submission from Zephor Wu: # coding=utf-8 import logging logger = logging.getLogger(u'??') logger.error(u'??') # these code will get an unexpected error # because getLogger encode the unicode to utf-8 while _log don't # see line 474 in logging/__init__.py # my suggestion is to keep the encoding in logging same with python2 with unicode ---------- components: Library (Lib) messages: 254881 nosy: zephor priority: normal severity: normal status: open title: Unexpected UnicodeDecodeError in logging module versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 00:39:03 2015 From: report at bugs.python.org (Zephor Wu) Date: Thu, 19 Nov 2015 05:39:03 +0000 Subject: [issue25664] Unexpected UnicodeDecodeError in logging module In-Reply-To: <1447911382.32.0.466398267316.issue25664@psf.upfronthosting.co.za> Message-ID: <1447911543.54.0.235744648285.issue25664@psf.upfronthosting.co.za> Changes by Zephor Wu : ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 02:20:43 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 19 Nov 2015 07:20:43 +0000 Subject: [issue25663] Make rlcompleter avoid duplicate global names In-Reply-To: <1447899261.09.0.497189339865.issue25663@psf.upfronthosting.co.za> Message-ID: <1447917643.68.0.0495489952374.issue25663@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 02:57:07 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 19 Nov 2015 07:57:07 +0000 Subject: [issue25663] Make rlcompleter avoid duplicate global names In-Reply-To: <1447899261.09.0.497189339865.issue25663@psf.upfronthosting.co.za> Message-ID: <1447919827.84.0.976832879983.issue25663@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Nice work. An alternative approach is to make "matches" a dict. And instead of if match not in seen: seen.add(word) matches.append(match) use just matches[word] = match I don't know what approach is better. Added other minor comments on Rietveld. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 03:06:26 2015 From: report at bugs.python.org (Ashwini Chaudhary) Date: Thu, 19 Nov 2015 08:06:26 +0000 Subject: [issue25665] typing.NamedTuple instances are not picklable. Message-ID: <1447920386.58.0.359968299873.issue25665@psf.upfronthosting.co.za> New submission from Ashwini Chaudhary: Currently namedtuple(https://hg.python.org/cpython/file/3.5/Lib/collections/__init__.py#l418) sets the `__module__` attribute by looking up `__name__` in calling frame's globals. As in the case of `typing.NamedTuple` it is always going to be 'typing' pickle will raise an error. Instead of this `typing.NamedTuple` should override the `__module__` attribute itself because it has info about the actual caller frame. Something like this should work fine: ``` def NamedTuple(typename, fields): fields = [(n, t) for n, t in fields] cls = collections.namedtuple(typename, [n for n, t in fields]) cls._field_types = dict(fields) try: cls.__module__ = sys._getframe(1).f_globals.get('__name__', '__main__') except (AttributeError, ValueError): pass return cls ``` Related: http://stackoverflow.com/q/33796490/846892 ---------- components: Library (Lib) messages: 254883 nosy: montysinngh priority: normal severity: normal status: open title: typing.NamedTuple instances are not picklable. versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 03:08:18 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 19 Nov 2015 08:08:18 +0000 Subject: [issue25626] Gzip fails for file over 2**32 bytes In-Reply-To: <1447530501.75.0.968129152166.issue25626@psf.upfronthosting.co.za> Message-ID: <1447920498.27.0.604237216091.issue25626@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could you please add tests for other two functions? And tests for the gzip module? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 03:17:24 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 19 Nov 2015 08:17:24 +0000 Subject: [issue25665] typing.NamedTuple instances are not picklable. In-Reply-To: <1447920386.58.0.359968299873.issue25665@psf.upfronthosting.co.za> Message-ID: <1447921044.47.0.118261366512.issue25665@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +gvanrossum, rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 03:26:50 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 19 Nov 2015 08:26:50 +0000 Subject: [issue25654] test_multiprocessing_spawn ResourceWarning with -Werror In-Reply-To: <1447830828.22.0.981390741581.issue25654@psf.upfronthosting.co.za> Message-ID: <1447921610.01.0.136200537325.issue25654@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Good point! The question is whether we want to see resource warnings when override standard streams with open files (usually without closefd=False)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 03:27:58 2015 From: report at bugs.python.org (Luke Erlacher) Date: Thu, 19 Nov 2015 08:27:58 +0000 Subject: [issue12346] Python source code build fails with old mercurial In-Reply-To: <1308212064.93.0.160132143903.issue12346@psf.upfronthosting.co.za> Message-ID: <1447921678.33.0.833958293545.issue12346@psf.upfronthosting.co.za> Luke Erlacher added the comment: This is not fixed in 2.7.10. ---------- nosy: +Luke Erlacher _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 03:34:26 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 19 Nov 2015 08:34:26 +0000 Subject: [issue25626] Gzip fails for file over 2**32 bytes In-Reply-To: <1447530501.75.0.968129152166.issue25626@psf.upfronthosting.co.za> Message-ID: <1447922066.91.0.0361186334131.issue25626@psf.upfronthosting.co.za> Martin Panter added the comment: Okay. For the gzip module, I cannot easily test this myself. Quickly looking at other cases, I guess it would look something like this, but I need to spend some time understanging the bigmemtest decorator properly: @unittest.skipIf(sys.maxsize < _4G, "Requires non-32-bit system") @test.support.bigmemtest(_4G, 1, dry_run=False) def test_large_read(self, size): ... data = reader.read(size) # Should not raise OverflowError self.assertEqual(data, b"data") ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 03:45:10 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 19 Nov 2015 08:45:10 +0000 Subject: [issue25654] test_multiprocessing_spawn ResourceWarning with -Werror In-Reply-To: <1447830828.22.0.981390741581.issue25654@psf.upfronthosting.co.za> Message-ID: <1447922710.42.0.319750457764.issue25654@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: You can commit your patch right now (it shouldn't make things worse), and continue to work on additional tests. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 03:57:47 2015 From: report at bugs.python.org (Ashwini Chaudhary) Date: Thu, 19 Nov 2015 08:57:47 +0000 Subject: [issue25665] typing.NamedTuple instances are not picklable. In-Reply-To: <1447920386.58.0.359968299873.issue25665@psf.upfronthosting.co.za> Message-ID: <1447923467.29.0.183486438077.issue25665@psf.upfronthosting.co.za> Ashwini Chaudhary added the comment: Attached patch. ---------- keywords: +patch Added file: http://bugs.python.org/file41073/issue25665.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 04:00:33 2015 From: report at bugs.python.org (jon orebro) Date: Thu, 19 Nov 2015 09:00:33 +0000 Subject: [issue25666] Python unexpectedly ignores a signal after fork Message-ID: <1447923633.78.0.317393195352.issue25666@psf.upfronthosting.co.za> New submission from jon orebro: Description: I found a slight problem with signal handling. It seems that if you have a signal handler setup for a signal, right after a fork the child ignores that signal for a short time. This is regardless of what the signal handler is setup to do. This can cause hangs if the parent immediately kills and then waits for the child. Since the timeframe is small, in practice this only happens sometimes (se example). There might be a reason for this behavour, but in that case I think it should me mentioned in the docs. What I expected: I expected the child to, at any point in time, either do the default action for the signal (terminate in this case), or to run the signal handler. What happens: It ignores the signal for a short while. Tested versions: Python 2.7.6 Python 3.4.0 ---------- assignee: docs at python components: Documentation, Interpreter Core files: example.py messages: 254890 nosy: docs at python, jon orebro priority: normal severity: normal status: open title: Python unexpectedly ignores a signal after fork type: behavior versions: Python 2.7, Python 3.4 Added file: http://bugs.python.org/file41074/example.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 04:28:28 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 19 Nov 2015 09:28:28 +0000 Subject: [issue25626] Gzip fails for file over 2**32 bytes In-Reply-To: <1447530501.75.0.968129152166.issue25626@psf.upfronthosting.co.za> Message-ID: <1447925308.76.0.542593052725.issue25626@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: You can commit your patch right now (it shouldn't make things worse) and add new tests later. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 04:49:18 2015 From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=) Date: Thu, 19 Nov 2015 09:49:18 +0000 Subject: [issue20438] inspect: Deprecate getfullargspec? In-Reply-To: <1391014813.06.0.594760406572.issue20438@psf.upfronthosting.co.za> Message-ID: <1447926558.1.0.888661922804.issue20438@psf.upfronthosting.co.za> Vedran ?a?i? added the comment: > Also, it is worth noting, that Signature API does not provide 100% of functionality that deprecated APIs have. It is important to do a soft deprecation of outdated APIs in 3.5 to gather users feedback, and improve Signature object. Well, here is a feedback about lost functionality. inspect.getcallargs had a very nice property that it automatically bound the first argument to the instance of bound methods. It seems I have no general way to do it with Signature.bind. Of course I can put arguments['self'] = method.__self__ afterwards, but theoretically, the argument doesn't have to be called 'self'. And anyway, I would like something that works seamlessly with bound methods and ordinary functions. ---------- nosy: +Vedran.?a?i? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 05:18:04 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 19 Nov 2015 10:18:04 +0000 Subject: [issue25654] test_multiprocessing_spawn ResourceWarning with -Werror In-Reply-To: <1447830828.22.0.981390741581.issue25654@psf.upfronthosting.co.za> Message-ID: <1447928284.92.0.833890639299.issue25654@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is an alternative patch that uses closefd=False. ---------- Added file: http://bugs.python.org/file41075/multiprocessing_no_close_fd.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 05:35:04 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 19 Nov 2015 10:35:04 +0000 Subject: [issue25664] Unexpected UnicodeDecodeError in logging module In-Reply-To: <1447911382.32.0.466398267316.issue25664@psf.upfronthosting.co.za> Message-ID: <1447929304.12.0.212716499278.issue25664@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 06:17:57 2015 From: report at bugs.python.org (JGoutin) Date: Thu, 19 Nov 2015 11:17:57 +0000 Subject: [issue25646] Distutils and Windows SDK 7.0 / Windows SDK 7.1 / Visual C++ Build Tools 2015 In-Reply-To: <1447756303.67.0.435034104806.issue25646@psf.upfronthosting.co.za> Message-ID: <1447931877.92.0.969646249555.issue25646@psf.upfronthosting.co.za> JGoutin added the comment: Hello, I modified "msvc9compiler.py" with following changes : - Add automatic compatibility with standalone VC++ compilers from Windows SDK 7.1. (Not for 6.1/7.0, because that finally don't work as good as it seem on first view and there is already MSVC++ for Python 2.7). - Changed error when "include", "lib", "libpath" or "path" environment variable is missing to be more clear. - Modified some comments and strings to not specify exclusively VS2008 (This file is also compatible with more recent VS and that was not really clear before) - Remove "gen_preprocess_options" from import because it was unused. - Fixed PEP8. The file was tested with SDK7.1 on a Cython compilation + a Pip install from source on Python 3.4 and seem to work perfectly. Ps: Forget my previous comment on VS2015, I didn't see that code for it was moved on "_msvccompiler.py". I'll wait the official release for the fix on Visual C++ Build Tools 2015 (Which is, anyway, only in technical preview since october) ---------- versions: +Python 3.3, Python 3.4 -Python 2.7, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file41076/msvc9compiler.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 08:32:53 2015 From: report at bugs.python.org (Jason R. Coombs) Date: Thu, 19 Nov 2015 13:32:53 +0000 Subject: [issue25667] Supply dual-stack (IPv4/IPv6) socket bind routine Message-ID: <1447939973.83.0.965937708444.issue25667@psf.upfronthosting.co.za> New submission from Jason R. Coombs: When binding to a socket for creating a service, the socket API provides a mechanism for selecting only IPv4 or IPv6, but the simple operation of binding to all interfaces in a dual-stack environment is not easy, as is revealed in issue20215 and issue24209, but also in third-party packages. I ran into this during the implementation of aiosmtpd (https://gitlab.com/python-smtpd-hackers/aiosmtpd). As a long time maintainer of CherryPy, I've enjoyed the [dual stack support](https://bitbucket.org/cherrypy/cherrypy/src/536a9cb66e91de92502e766b2b0cf53d1cb5cb4a/cherrypy/wsgiserver/wsgiserver2.py?at=default&fileviewer=file-view-default#wsgiserver2.py-2007:2020) there. I propose the Python stdlib provide a routine to facilitate this need more generally, and then invoke that implementation to address these other use-cases. As it is a new feature, a backports package should be created to supply the same functionality for older Pythons. Would this effort require a PEP? Is there a good place for such a routine (maybe socketserver)? Any other thoughts? ---------- components: Library (Lib) messages: 254895 nosy: jason.coombs priority: normal severity: normal status: open title: Supply dual-stack (IPv4/IPv6) socket bind routine versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 09:22:53 2015 From: report at bugs.python.org (Florent Viard) Date: Thu, 19 Nov 2015 14:22:53 +0000 Subject: [issue25668] Deadlock in logging caused by a possible race condition with "format" Message-ID: <1447942973.46.0.788007678714.issue25668@psf.upfronthosting.co.za> New submission from Florent Viard: When an user, use logging, to try to display an object that uses some threading locks, there could be a race condition and the logging module will deadlock. So, any thread that will try to use logging, will then be stuck forever. Please see the following test case that is a simplification of a case that I have encountered. I'm able to reproduce the issue on python 3.4.3, and python 2.7.9. But, based on the code, I think that all versions are affected. Basically, I try to log a variable that is like a property or the __unicode__ function of an object. But this value will not be calculated before entering the "logging.warning" code but in the "self.format" of the logging handler. This self.format is called under the umbrella of the big lock of "logging". So, if function to get my variable value involve taking another lock and then performing a logging call. There is great chances that another thread also took the variable lock between the time that I took the logging lock and before it take the variable lock. So, the first thread will wait for the variable lock but will have the logging lock. But the other thread will have the variable lock but will wait the logging lock. Traceback of the current situation: # ThreadID: 140410437482240 File: "/usr/lib/python2.7/threading.py", line 783, in __bootstrap self.__bootstrap_inner() File: "/usr/lib/python2.7/threading.py", line 810, in __bootstrap_inner self.run() File: "/usr/lib/python2.7/threading.py", line 763, in run self.__target(*self.__args, **self.__kwargs) File: "testcase-bug-python-deadlock-logging.py", line 37, in second_thread my_db.log_pid() File: "testcase-bug-python-deadlock-logging.py", line 24, in log_pid logging.warning(u"my_db pid is: %s", u"1234") File: "/usr/lib/python2.7/logging/__init__.py", line 1604, in warning root.warning(msg, *args, **kwargs) File: "/usr/lib/python2.7/logging/__init__.py", line 1164, in warning self._log(WARNING, msg, args, **kwargs) File: "/usr/lib/python2.7/logging/__init__.py", line 1271, in _log self.handle(record) File: "/usr/lib/python2.7/logging/__init__.py", line 1281, in handle self.callHandlers(record) File: "/usr/lib/python2.7/logging/__init__.py", line 1321, in callHandlers hdlr.handle(record) File: "/usr/lib/python2.7/logging/__init__.py", line 747, in handle self.acquire() File: "/usr/lib/python2.7/logging/__init__.py", line 698, in acquire self.lock.acquire() File: "/usr/lib/python2.7/threading.py", line 173, in acquire rc = self.__block.acquire(blocking) # ThreadID: 140410445874944 File: "/usr/lib/python2.7/threading.py", line 783, in __bootstrap self.__bootstrap_inner() File: "/usr/lib/python2.7/threading.py", line 810, in __bootstrap_inner self.run() File: "/usr/lib/python2.7/threading.py", line 763, in run self.__target(*self.__args, **self.__kwargs) File: "testcase-bug-python-deadlock-logging.py", line 31, in first_thread logging.warning(u"My slow pid is: %s", my_db) File: "/usr/lib/python2.7/logging/__init__.py", line 1604, in warning root.warning(msg, *args, **kwargs) File: "/usr/lib/python2.7/logging/__init__.py", line 1164, in warning self._log(WARNING, msg, args, **kwargs) File: "/usr/lib/python2.7/logging/__init__.py", line 1271, in _log self.handle(record) File: "/usr/lib/python2.7/logging/__init__.py", line 1281, in handle self.callHandlers(record) File: "/usr/lib/python2.7/logging/__init__.py", line 1321, in callHandlers hdlr.handle(record) File: "/usr/lib/python2.7/logging/__init__.py", line 749, in handle self.emit(record) File: "/usr/lib/python2.7/logging/__init__.py", line 851, in emit msg = self.format(record) File: "/usr/lib/python2.7/logging/__init__.py", line 724, in format return fmt.format(record) File: "/usr/lib/python2.7/logging/__init__.py", line 464, in format record.message = record.getMessage() File: "/usr/lib/python2.7/logging/__init__.py", line 328, in getMessage msg = msg % self.args File: "testcase-bug-python-deadlock-logging.py", line 17, in __unicode__ with db_lock: File: "/usr/lib/python2.7/threading.py", line 173, in acquire rc = self.__block.acquire(blocking) ---------- components: Library (Lib) files: testcase-bug-python-deadlock-logging.py messages: 254896 nosy: fviard priority: normal severity: normal status: open title: Deadlock in logging caused by a possible race condition with "format" type: crash versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file41077/testcase-bug-python-deadlock-logging.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 09:29:12 2015 From: report at bugs.python.org (Florent Viard) Date: Thu, 19 Nov 2015 14:29:12 +0000 Subject: [issue25668] Deadlock in logging caused by a possible race condition with "format" In-Reply-To: <1447942973.46.0.788007678714.issue25668@psf.upfronthosting.co.za> Message-ID: <1447943352.93.0.00473626885752.issue25668@psf.upfronthosting.co.za> Florent Viard added the comment: Looking at the code, this issue makes sense in logging/__init__.py (+738): def handle(self, record): """ Conditionally emit the specified logging record. Emission depends on filters which may have been added to the handler. Wrap the actual emission of the record with acquisition/release of the I/O thread lock. Returns whether the filter passed the record for emission. """ rv = self.filter(record) if rv: self.acquire() try: self.emit(record) finally: self.release() return rv Than, in the "emit()" of whatever handler used, there is first: msg = self.format(record) In my opinion, a possible fix would be to change this code to something like: rv = self.filter(record) if rv: record.formatted_msg = self.format(record) self.acquire() try: self.emit(record) finally: self.release() return rv And then, change all the "emit()" of log handlers from: msg = self.format(record) to msg = record.processed_msg By not modifying the "msg" and "args" parameters of the record, all the code that would have reimplemented the standard log handler will still be working fine (even if they will still be at risk of encountering the deadlock) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 09:42:42 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 19 Nov 2015 14:42:42 +0000 Subject: [issue25666] Python unexpectedly ignores a signal after fork In-Reply-To: <1447923633.78.0.317393195352.issue25666@psf.upfronthosting.co.za> Message-ID: <1447944162.09.0.0909725767639.issue25666@psf.upfronthosting.co.za> R. David Murray added the comment: Are you sure this is a python issue and not an OS issue? That is, does an equivalent C program work correctly? Since the operation is a fork, I don't think there's anything that python does that would cause the signal to be ignored. The comment block in the example code here: https://www.win.tue.nl/~aeb/linux/lk/lk-5.html makes me think that the signal getting ignored is a possibility at the OS level, though it isn't explicitly clear. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 09:46:37 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 19 Nov 2015 14:46:37 +0000 Subject: [issue20438] inspect: Deprecate getfullargspec? In-Reply-To: <1391014813.06.0.594760406572.issue20438@psf.upfronthosting.co.za> Message-ID: <1447944397.26.0.681260968854.issue20438@psf.upfronthosting.co.za> R. David Murray added the comment: Please open a new issue for that observation/request. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 09:52:32 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 19 Nov 2015 14:52:32 +0000 Subject: [issue25667] Supply dual-stack (IPv4/IPv6) socket bind routine In-Reply-To: <1447939973.83.0.965937708444.issue25667@psf.upfronthosting.co.za> Message-ID: <1447944752.55.0.221382231.issue25667@psf.upfronthosting.co.za> R. David Murray added the comment: I don't think it should require a PEP, it looks like a fairly straightforward small enhancement. What is the reason to not put it in the socket module? ---------- nosy: +r.david.murray stage: -> needs patch type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 09:58:40 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 19 Nov 2015 14:58:40 +0000 Subject: [issue25668] Deadlock in logging caused by a possible race condition with "format" In-Reply-To: <1447942973.46.0.788007678714.issue25668@psf.upfronthosting.co.za> Message-ID: <1447945120.69.0.800906467393.issue25668@psf.upfronthosting.co.za> R. David Murray added the comment: But not doing the format until the last moment is part of the design of logging (as low overhead as possible unless a message is actually emitted). I suspect you are just going to have to pre-calculate that variable if you want to log it. Let's see what Vinay thinks, though :) ---------- nosy: +r.david.murray, vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 09:59:24 2015 From: report at bugs.python.org (Nathan Herring) Date: Thu, 19 Nov 2015 14:59:24 +0000 Subject: [issue25669] unittest.assertEqual() on un-equal types inheriting from collections.Mapping Message-ID: <1447945164.43.0.781001179378.issue25669@psf.upfronthosting.co.za> New submission from Nathan Herring: We have some code that generates objects that inherit from Mapping that are not nearly as straightforward to instantiate in a test. It's much easier to have something like the follows: foo = ? # some collections.Mapping subtype self.assertEqual({'key': 'value'}, foo) unittest/case.py's _baseAssertEqual will print out both sides and let me do visual inspection, but I'd prefer it if it knew both sides supported Mapping and in the != case, performed an analog of assertDictEqual so I could just get the keys/values that were mismatched, especially in the cases of large dictionaries. ---------- components: Tests messages: 254902 nosy: Nathan Herring priority: normal severity: normal status: open title: unittest.assertEqual() on un-equal types inheriting from collections.Mapping type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 10:11:04 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 19 Nov 2015 15:11:04 +0000 Subject: [issue25670] ast.NodeTransformer: remove duplicate getattr() Message-ID: <1447945864.74.0.854545532845.issue25670@psf.upfronthosting.co.za> New submission from STINNER Victor: ast.NodeTransformer.generic_visit() calls getattr() whereas iter_fields() already returns the attribute. The getattr() is useless, attached patch removes it. Sadly, it looks like test_ast doesn't test this class at all :-( The class is tested *indirectly* by test_inspect. ---------- files: node_transformer.patch keywords: patch messages: 254903 nosy: haypo priority: normal severity: normal status: open title: ast.NodeTransformer: remove duplicate getattr() type: performance versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file41078/node_transformer.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 10:12:01 2015 From: report at bugs.python.org (Nathan Herring) Date: Thu, 19 Nov 2015 15:12:01 +0000 Subject: [issue25669] unittest.assertEqual() on un-equal types inheriting from collections.Mapping In-Reply-To: <1447945164.43.0.781001179378.issue25669@psf.upfronthosting.co.za> Message-ID: <1447945921.87.0.82045913773.issue25669@psf.upfronthosting.co.za> Nathan Herring added the comment: FWIW, it's also pretty easy to write self.assertEqual({'key': 'value'}, dict(foo)) and get the right behavior, but it'd be nice if it was done automagically by type checking. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 10:21:36 2015 From: report at bugs.python.org (Florent Viard) Date: Thu, 19 Nov 2015 15:21:36 +0000 Subject: [issue25668] Deadlock in logging caused by a possible race condition with "format" In-Reply-To: <1447942973.46.0.788007678714.issue25668@psf.upfronthosting.co.za> Message-ID: <1447946496.73.0.927988575247.issue25668@psf.upfronthosting.co.za> Florent Viard added the comment: I understand that it should have been the reason of this. But in my opinion, it is very bad to possibly have calculations and user space arbitrary operations inside the logging lock. If you look at my proposition, you can do the format after the filter, but just before acquiring the lock. As most handlers start by calling the self.format() soon in the "emit()", I don't expect a big difference. I'm not entirely sure that it is a good solution, but I think that the issue is pretty bad. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 10:24:50 2015 From: report at bugs.python.org (Nathan West) Date: Thu, 19 Nov 2015 15:24:50 +0000 Subject: [issue25671] Fix venv activate.fish to maintain $status Message-ID: <1447946690.19.0.336666934208.issue25671@psf.upfronthosting.co.za> New submission from Nathan West: Many fish_prompts use display the $status (fish's equivalent to $?) somewhere in the prompt. Currently, venv's activate.fish overwrites and wraps the user's fish_prompt, the wrapping doesn't preserve this $status. This patch ensures that the $status is correctly restored before invoking the user's fish_prompt. This is based on my similar work in virtualenv, at https://github.com/pypa/virtualenv/pull/799 ---------- components: Library (Lib) files: patch.diff keywords: patch messages: 254906 nosy: Lucretiel priority: normal severity: normal status: open title: Fix venv activate.fish to maintain $status type: enhancement versions: Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file41079/patch.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 10:30:30 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 19 Nov 2015 15:30:30 +0000 Subject: [issue25668] Deadlock in logging caused by a possible race condition with "format" In-Reply-To: <1447942973.46.0.788007678714.issue25668@psf.upfronthosting.co.za> Message-ID: <1447947030.2.0.125939711812.issue25668@psf.upfronthosting.co.za> R. David Murray added the comment: Using the lock to cover as little as possible makes sense, but there may be a reason format is covered by the lock. I don't know the code well enough to say, we'll have to wait for Vinay. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 11:17:23 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 19 Nov 2015 16:17:23 +0000 Subject: [issue25665] typing.NamedTuple instances are not picklable. In-Reply-To: <1447920386.58.0.359968299873.issue25665@psf.upfronthosting.co.za> Message-ID: <20151119161720.31739.34656@psf.io> Roundup Robot added the comment: New changeset 33df0056c148 by Guido van Rossum in branch '3.5': Issue #25665: Make NamedTuple picklable. https://hg.python.org/cpython/rev/33df0056c148 New changeset 8a32d44b8359 by Guido van Rossum in branch 'default': Issue #25665: Make NamedTuple picklable. (Merge 3.5->3.6) https://hg.python.org/cpython/rev/8a32d44b8359 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 11:21:49 2015 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 19 Nov 2015 16:21:49 +0000 Subject: [issue25665] typing.NamedTuple instances are not picklable. In-Reply-To: <1447920386.58.0.359968299873.issue25665@psf.upfronthosting.co.za> Message-ID: <1447950109.11.0.34073637879.issue25665@psf.upfronthosting.co.za> Guido van Rossum added the comment: Fixed it! Thanks for the report *and* the patch. I wrote a different test though. ---------- assignee: -> gvanrossum resolution: -> fixed status: open -> closed versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 11:22:43 2015 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 19 Nov 2015 16:22:43 +0000 Subject: [issue25593] _sock_connect_cb can be called twice resulting in InvalidStateError In-Reply-To: <1447139794.12.0.288748898255.issue25593@psf.upfronthosting.co.za> Message-ID: <1447950162.99.0.34410790703.issue25593@psf.upfronthosting.co.za> Guido van Rossum added the comment: I'm going to fix up the patch and apply it so this can make 3.5.1 rc1. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 11:32:25 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 19 Nov 2015 16:32:25 +0000 Subject: [issue25670] ast.NodeTransformer: remove duplicate getattr() In-Reply-To: <1447945864.74.0.854545532845.issue25670@psf.upfronthosting.co.za> Message-ID: <1447950745.05.0.167303914714.issue25670@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, the getattr() is as old as the Lib/ast.py module: change 7d824fd131ad. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 12:02:21 2015 From: report at bugs.python.org (Davin Potts) Date: Thu, 19 Nov 2015 17:02:21 +0000 Subject: [issue25654] test_multiprocessing_spawn ResourceWarning with -Werror In-Reply-To: <1447830828.22.0.981390741581.issue25654@psf.upfronthosting.co.za> Message-ID: <1447952541.49.0.92776219245.issue25654@psf.upfronthosting.co.za> Davin Potts added the comment: Note issue21779 has been around for quite some time with its own patch specifically for multiprocessing, making its tests more robust. I am hesitant to embrace the patch suggested here. ---------- nosy: +davin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 12:29:31 2015 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 19 Nov 2015 17:29:31 +0000 Subject: [issue25593] _sock_connect_cb can be called twice resulting in InvalidStateError In-Reply-To: <1447139794.12.0.288748898255.issue25593@psf.upfronthosting.co.za> Message-ID: <1447954171.65.0.230620530615.issue25593@psf.upfronthosting.co.za> Guido van Rossum added the comment: Here's a better patch. - Renamed _stopped to _stopping. - Restore test_utils.run_once() and add a test for it. - Change logic so if _stopping is True upon entering run_forever(), it will run once. Please try it out!! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 12:29:50 2015 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 19 Nov 2015 17:29:50 +0000 Subject: [issue25593] _sock_connect_cb can be called twice resulting in InvalidStateError In-Reply-To: <1447139794.12.0.288748898255.issue25593@psf.upfronthosting.co.za> Message-ID: <1447954190.49.0.724271969442.issue25593@psf.upfronthosting.co.za> Guido van Rossum added the comment: Here's the file. ---------- Added file: http://bugs.python.org/file41080/issue25593_revised.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 12:57:40 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 19 Nov 2015 17:57:40 +0000 Subject: [issue25654] test_multiprocessing_spawn ResourceWarning with -Werror In-Reply-To: <1447830828.22.0.981390741581.issue25654@psf.upfronthosting.co.za> Message-ID: <1447955860.56.0.587181957597.issue25654@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Oh, I forgot about issue21779. And there was at least yet one duplicate issue23827. Thanks for the reminder Davin. The patch in issue21779 fixes only symptoms, makes failed test more lenient. I prefer to got rid of resource warnings at all. ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 12:58:27 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 19 Nov 2015 17:58:27 +0000 Subject: [issue21779] test_multiprocessing_spawn fails when ran with -Werror In-Reply-To: <1402932904.12.0.0907209632693.issue21779@psf.upfronthosting.co.za> Message-ID: <1447955907.18.0.863429336538.issue21779@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Proposed patch cures only the symptom, the failure of one rigid test. A warning still is emitted in applications that use multiprocessing. Closed in favor of duplicate issue25654 with patches that are intended to fix the cause of warnings. In any case thank you for your contribution Davin. ---------- resolution: -> duplicate stage: patch review -> resolved status: open -> closed superseder: -> test_multiprocessing_spawn ResourceWarning with -Werror _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 13:13:43 2015 From: report at bugs.python.org (Brett Cannon) Date: Thu, 19 Nov 2015 18:13:43 +0000 Subject: [issue25533] Make pkgutil.iter_modules() yield built-in modules In-Reply-To: <1446462853.43.0.928344730721.issue25533@psf.upfronthosting.co.za> Message-ID: <1447956823.0.0.519082832588.issue25533@psf.upfronthosting.co.za> Brett Cannon added the comment: I say let it go and make sure the docs clearly document that only modules found off of sys.path are supported. Otherwise I would look at why walk_packages() and pydoc feel the need to import every module and if import simply needs to be tweaked to support this use case better (if at all). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 13:17:07 2015 From: report at bugs.python.org (Cory Benfield) Date: Thu, 19 Nov 2015 18:17:07 +0000 Subject: [issue25672] Unconditionally set SSL_MODE_RELEASE_BUFFERS Message-ID: <1447957027.04.0.0951767236546.issue25672@psf.upfronthosting.co.za> New submission from Cory Benfield: Originally raised by Ben Bangert on the python-dev mailing list. It turns out that OpenSSL has a mode setting, SSL_MODE_RELEASE_BUFFERS, that can be set by a call to SSK_CTX_set_mode. This mode can potentially reduce connection overhead by nearly 18kB *per connection*, a reduction of something like 60%. Further, this does not change the behaviour of OpenSSL in any meaningful way. For this reason, we should unconditionally set this mode on all SSL Context objects we create. I'm happy to submit a patch to the standard library that will do this. ---------- components: Library (Lib) messages: 254918 nosy: Lukasa priority: normal severity: normal status: open title: Unconditionally set SSL_MODE_RELEASE_BUFFERS versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 13:20:06 2015 From: report at bugs.python.org (Cory Benfield) Date: Thu, 19 Nov 2015 18:20:06 +0000 Subject: [issue25672] Unconditionally set SSL_MODE_RELEASE_BUFFERS In-Reply-To: <1447957027.04.0.0951767236546.issue25672@psf.upfronthosting.co.za> Message-ID: <1447957206.43.0.0576774321996.issue25672@psf.upfronthosting.co.za> Cory Benfield added the comment: Oh, one further requirement: we should *not* set this mode for OpenSSL releases 1.x through 1.0.1g, which have a NULL pointer dereference vulnerability (CVE 2014-0198). Thanks to Marc-Andre Lemburg for spotting this. See also: https://www.rapid7.com/db/vulnerabilities/http-openssl-cve-2014-0198 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 13:22:20 2015 From: report at bugs.python.org (Ethan Furman) Date: Thu, 19 Nov 2015 18:22:20 +0000 Subject: [issue25672] set SSL_MODE_RELEASE_BUFFERS In-Reply-To: <1447957027.04.0.0951767236546.issue25672@psf.upfronthosting.co.za> Message-ID: <1447957340.34.0.332018603225.issue25672@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +alex, christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou title: Unconditionally set SSL_MODE_RELEASE_BUFFERS -> set SSL_MODE_RELEASE_BUFFERS _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 13:34:52 2015 From: report at bugs.python.org (kehlert) Date: Thu, 19 Nov 2015 18:34:52 +0000 Subject: [issue25673] unittest assertLessEqual not working properly with lists Message-ID: <1447958092.38.0.804432580848.issue25673@psf.upfronthosting.co.za> New submission from kehlert: I attached a file that explains the issue. Basically, assertLessEqual only seems to compare the first elements of the two lists and ignores the others. Thus a test can pass when it shouldn't. ---------- files: example.py messages: 254920 nosy: kehlert priority: normal severity: normal status: open title: unittest assertLessEqual not working properly with lists versions: Python 3.4 Added file: http://bugs.python.org/file41081/example.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 13:40:49 2015 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 19 Nov 2015 18:40:49 +0000 Subject: [issue25593] _sock_connect_cb can be called twice resulting in InvalidStateError In-Reply-To: <1447139794.12.0.288748898255.issue25593@psf.upfronthosting.co.za> Message-ID: <1447958449.73.0.0317999191059.issue25593@psf.upfronthosting.co.za> Guido van Rossum added the comment: New patch. Update test_utils.run_once() to use the recommended idiom. On second thought I don't like issuing a warning when stop() is called before the loop runs -- a warning seems overkill for something so minor. But I'm okay with no longer recommending the idiom. ---------- Added file: http://bugs.python.org/file41082/issue25593_revised_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 13:44:14 2015 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 19 Nov 2015 18:44:14 +0000 Subject: [issue25673] unittest assertLessEqual not working properly with lists In-Reply-To: <1447958092.38.0.804432580848.issue25673@psf.upfronthosting.co.za> Message-ID: <1447958654.58.0.987471667275.issue25673@psf.upfronthosting.co.za> Ezio Melotti added the comment: This is how comparison works for sequences and it's not a bug: >>> a = [1, 2] >>> b = [2, 1] >>> a <= b True >>> a = [2, 1] >>> b = [1, 2] >>> a <= b False See https://docs.python.org/3/tutorial/datastructures.html#comparing-sequences-and-other-types ---------- nosy: +ezio.melotti resolution: -> not a bug stage: -> resolved status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 13:45:46 2015 From: report at bugs.python.org (Justin Mayfield) Date: Thu, 19 Nov 2015 18:45:46 +0000 Subject: [issue25593] _sock_connect_cb can be called twice resulting in InvalidStateError In-Reply-To: <1447139794.12.0.288748898255.issue25593@psf.upfronthosting.co.za> Message-ID: <1447958746.2.0.52395944255.issue25593@psf.upfronthosting.co.za> Justin Mayfield added the comment: I should have commented more on the run_once removal. The depiction given in its docstring seemed inconsistent with the new way stop works and I found no callers, so it seemed like it was best left out to avoid confusion. No worries though, I didn't get to know that test module very well before messing with it. It just came up in my scan for stop() callers. Looks good, I've applied to a 3.5.0 build and will include it in my testing from now on. Thanks Guido. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 13:51:52 2015 From: report at bugs.python.org (Justin Mayfield) Date: Thu, 19 Nov 2015 18:51:52 +0000 Subject: [issue25593] _sock_connect_cb can be called twice resulting in InvalidStateError In-Reply-To: <1447139794.12.0.288748898255.issue25593@psf.upfronthosting.co.za> Message-ID: <1447959112.59.0.526131508773.issue25593@psf.upfronthosting.co.za> Justin Mayfield added the comment: Ha, email race. Regarding rev 2, the updated docstring and scheduled stop looks good along with alleviating the confusion I mentioned. I'm not sure about your warning comment; Perhaps that's a patch I didn't lay eyes on. Cheers. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 13:53:46 2015 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 19 Nov 2015 18:53:46 +0000 Subject: [issue25593] _sock_connect_cb can be called twice resulting in InvalidStateError In-Reply-To: <1447959112.59.0.526131508773.issue25593@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: No, I mentioned the idea of a warning in the thread on the python-tulip mailing list, but decided not to do it after all. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 14:04:20 2015 From: report at bugs.python.org (Justin Mayfield) Date: Thu, 19 Nov 2015 19:04:20 +0000 Subject: [issue25593] _sock_connect_cb can be called twice resulting in InvalidStateError In-Reply-To: <1447139794.12.0.288748898255.issue25593@psf.upfronthosting.co.za> Message-ID: <1447959860.49.0.916874970236.issue25593@psf.upfronthosting.co.za> Justin Mayfield added the comment: I see. Seems like good discussion over there. I joined up. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 14:34:08 2015 From: report at bugs.python.org (Cory Benfield) Date: Thu, 19 Nov 2015 19:34:08 +0000 Subject: [issue25672] set SSL_MODE_RELEASE_BUFFERS In-Reply-To: <1447957027.04.0.0951767236546.issue25672@psf.upfronthosting.co.za> Message-ID: <1447961648.88.0.137715876026.issue25672@psf.upfronthosting.co.za> Cory Benfield added the comment: Ok, I've just uploaded an initial draft of the patch for review. ---------- keywords: +patch Added file: http://bugs.python.org/file41083/ssl.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 14:47:33 2015 From: report at bugs.python.org (Jun Wang) Date: Thu, 19 Nov 2015 19:47:33 +0000 Subject: [issue25634] Add a dedicated subclass for attribute missing errors In-Reply-To: <1447666799.36.0.119700754928.issue25634@psf.upfronthosting.co.za> Message-ID: <1447962453.62.0.824994067342.issue25634@psf.upfronthosting.co.za> Jun Wang added the comment: I think this is a common problem while using both __getattr__ and descriptor/property. A descriptor example: class Descriptor(): def __get__(self, instance, owner=None): raise AttributeError('Implicitly suppressed') class A(): d = Descriptor() def __getattr__(self, name): return 'default' print(A().d) Without descriptor, unexpected AttributeError could only come from overriding __getattribute__, which is a rare case, although still an imperfection. But in descriptor/property, AttributeError which is too general just occurs frequently like in normal method. Surely any modification would break the backward compatibility, although I wonder how often it is used of raising AttributeError purposely, maybe in __getattribute__, to call __getattr__, instead of explicitly calling __getattr__. In my understanding this is the only case that will be affected. "An unexpected exception should not result in subtly altered behaviour, but should cause a noisy and easily-debugged traceback. "?from PEP479 About the implementation, maybe something like "RuntimeError: descriptor raised AttributeError" simulating PEP479. Or in my lay opinion, the best solution is: add object.__getattr__, with the only behavior of raising AttributeError; when normal attribute lookup fails, object.__getattribute__ calls __getattr__ explicitly; __getattr__ not triggered by AttributeError anymore. I know little about the CPython implementation, so I might be completely wrong. However this seems deserving more detailed discussion. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 14:56:57 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 19 Nov 2015 19:56:57 +0000 Subject: [issue25634] Add a dedicated subclass for attribute missing errors In-Reply-To: <1447666799.36.0.119700754928.issue25634@psf.upfronthosting.co.za> Message-ID: <1447963017.55.0.271526923008.issue25634@psf.upfronthosting.co.za> R. David Murray added the comment: The more detailed discussion should happen on python-ideas. I'm going to close this for now, but if there's a consensus there about what action to take this issue could be reopened. (Or a new one created, whatever makes the most sense at that time.) ---------- resolution: -> later stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 15:05:31 2015 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 19 Nov 2015 20:05:31 +0000 Subject: [issue25593] _sock_connect_cb can be called twice resulting in InvalidStateError In-Reply-To: <1447139794.12.0.288748898255.issue25593@psf.upfronthosting.co.za> Message-ID: <1447963531.52.0.301103607067.issue25593@psf.upfronthosting.co.za> Guido van Rossum added the comment: OK, here's another revision of the patch, setting the timeout passed to the selector to 0 when the loop is pre-stopped. ---------- Added file: http://bugs.python.org/file41084/issue25593_revised_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 15:10:28 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 19 Nov 2015 20:10:28 +0000 Subject: [issue25660] tabs don't work correctly in python repl In-Reply-To: <1447876730.91.0.918964104484.issue25660@psf.upfronthosting.co.za> Message-ID: <1447963828.59.0.0534086590911.issue25660@psf.upfronthosting.co.za> Yury Selivanov added the comment: Attached is a patch that uses different logic for tabulation. Instead of returning '\t' from the completion callback, it instead calls explicit readline API: "readline.insert_text('\t'); readline.redisplay()" Please review. ---------- keywords: +patch Added file: http://bugs.python.org/file41085/rlcompleter.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 15:12:34 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 19 Nov 2015 20:12:34 +0000 Subject: [issue23441] rlcompleter: tab on empty prefix => insert spaces In-Reply-To: <1423650104.74.0.902857510979.issue23441@psf.upfronthosting.co.za> Message-ID: <1447963954.35.0.034238902398.issue23441@psf.upfronthosting.co.za> Yury Selivanov added the comment: Please see my patch for Issue 25660 -- instead of returning '\t' from the completion function, I use readline API to modify the input buffer directly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 15:22:02 2015 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 19 Nov 2015 20:22:02 +0000 Subject: [issue25593] _sock_connect_cb can be called twice resulting in InvalidStateError In-Reply-To: <1447139794.12.0.288748898255.issue25593@psf.upfronthosting.co.za> Message-ID: <1447964522.38.0.644448309464.issue25593@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 15:22:38 2015 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 19 Nov 2015 20:22:38 +0000 Subject: [issue25593] _sock_connect_cb can be called twice resulting in InvalidStateError In-Reply-To: <1447139794.12.0.288748898255.issue25593@psf.upfronthosting.co.za> Message-ID: <1447964558.19.0.551522307347.issue25593@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 15:37:42 2015 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 19 Nov 2015 20:37:42 +0000 Subject: [issue25593] _sock_connect_cb can be called twice resulting in InvalidStateError In-Reply-To: <1447139794.12.0.288748898255.issue25593@psf.upfronthosting.co.za> Message-ID: <1447965462.82.0.161379984109.issue25593@psf.upfronthosting.co.za> Guido van Rossum added the comment: OK, another revision, keep the mock selector. ---------- Added file: http://bugs.python.org/file41086/issue25593_revised_4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 15:46:16 2015 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 19 Nov 2015 20:46:16 +0000 Subject: [issue25593] _sock_connect_cb can be called twice resulting in InvalidStateError In-Reply-To: <1447139794.12.0.288748898255.issue25593@psf.upfronthosting.co.za> Message-ID: <1447965976.87.0.769566625125.issue25593@psf.upfronthosting.co.za> Guido van Rossum added the comment: Whoops. Hopefully this one's right. ---------- Added file: http://bugs.python.org/file41087/issue25593_revised_5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 15:53:43 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 19 Nov 2015 20:53:43 +0000 Subject: [issue25670] ast.NodeTransformer: remove duplicate getattr() In-Reply-To: <1447945864.74.0.854545532845.issue25670@psf.upfronthosting.co.za> Message-ID: <1447966423.57.0.666244696944.issue25670@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM! ---------- assignee: -> haypo components: +Library (Lib) nosy: +serhiy.storchaka stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 16:34:47 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 19 Nov 2015 21:34:47 +0000 Subject: [issue25593] _sock_connect_cb can be called twice resulting in InvalidStateError In-Reply-To: <1447139794.12.0.288748898255.issue25593@psf.upfronthosting.co.za> Message-ID: <20151119213444.105911.34793@psf.io> Roundup Robot added the comment: New changeset 9b3144716d17 by Guido van Rossum in branch '3.4': Issue #25593: Change semantics of EventLoop.stop(). https://hg.python.org/cpython/rev/9b3144716d17 New changeset 158cc5701488 by Guido van Rossum in branch '3.5': Issue #25593: Change semantics of EventLoop.stop(). (Merge 3.4->3.5) https://hg.python.org/cpython/rev/158cc5701488 New changeset 2ebe03a94f8f by Guido van Rossum in branch 'default': Issue #25593: Change semantics of EventLoop.stop(). (Merge 3.5->3.6) https://hg.python.org/cpython/rev/2ebe03a94f8f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 16:35:55 2015 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 19 Nov 2015 21:35:55 +0000 Subject: [issue25593] _sock_connect_cb can be called twice resulting in InvalidStateError In-Reply-To: <1447139794.12.0.288748898255.issue25593@psf.upfronthosting.co.za> Message-ID: <1447968954.99.0.289840184436.issue25593@psf.upfronthosting.co.za> Guido van Rossum added the comment: Hopefully this is it! ---------- assignee: -> gvanrossum resolution: later -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 16:38:08 2015 From: report at bugs.python.org (Tomer) Date: Thu, 19 Nov 2015 21:38:08 +0000 Subject: [issue25656] multiprocessing.dummy: pool.map hangs on empty list In-Reply-To: <1447855498.22.0.263851728204.issue25656@psf.upfronthosting.co.za> Message-ID: <1447969088.31.0.546892714136.issue25656@psf.upfronthosting.co.za> Changes by Tomer : ---------- nosy: +jnoller, sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 16:54:38 2015 From: report at bugs.python.org (David Bolen) Date: Thu, 19 Nov 2015 21:54:38 +0000 Subject: [issue25674] test_ssl (test_algorithms) failures on bolen-ubuntu slaves: sha256.tbs-internet.com unknown host Message-ID: <1447970078.37.0.506919207401.issue25674@psf.upfronthosting.co.za> New submission from David Bolen: It appears that the test host (sha256.tbs-internet.com) used by test_algorithms in test_ssl.py no longer exists. It was showing up as a certificate failure in the test because it ended up falling back to a resolv.conf search path which yielded a host that did do SSL but obviously with the wrong certificate. db3l at buildbot-ubuntu:~$ host sha256.tbs-internet.com Host sha256.tbs-internet.com not found: 3(NXDOMAIN) db3l at buildbot-ubuntu:~/tmp/python3.x/Lib/test$ dig +short ns tbs-internet.com NS1.tbs-internet.com. maj.pitux.com. ns2.atdynet.com. nsc.pitux.com. db3l at buildbot-ubuntu:~/tmp/python3.x/Lib/test$ dig @ns1.tbs-internet.com sha256.tbs-internet.com ; <<>> DiG 9.9.5-3ubuntu0.5-Ubuntu <<>> @ns1.tbs-internet.com sha256.tbs-internet.com ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 25154 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;sha256.tbs-internet.com. IN A ;; AUTHORITY SECTION: tbs-internet.com. 3600 IN SOA ovh12.tbs-internet.com. hostmaster.tbs-internet.com. 2015110705 21600 3600 2419200 3600 ;; Query time: 93 msec ;; SERVER: 2001:41d0:8:380d::1#53(2001:41d0:8:380d::1) ;; WHEN: Thu Nov 19 16:51:58 EST 2015 ;; MSG SIZE rcvd: 105 What I can't yet understand is why this is not causing issues on other slaves. I suppose some might be skipping the test if SNI was not supported, but surely not all of them? ---------- components: Tests messages: 254938 nosy: db3l, zach.ware priority: normal severity: normal status: open title: test_ssl (test_algorithms) failures on bolen-ubuntu slaves: sha256.tbs-internet.com unknown host type: behavior versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 16:56:01 2015 From: report at bugs.python.org (Ezequiel Alfie) Date: Thu, 19 Nov 2015 21:56:01 +0000 Subject: [issue25675] doc for BaseEventLoop.run_in_executor() says its a coroutine, but it is not Message-ID: <1447970161.65.0.436017258107.issue25675@psf.upfronthosting.co.za> New submission from Ezequiel Alfie: Doc says: coroutine BaseEventLoop.run_in_executor(executor, func, *args) ...... This method is a coroutine. However, inspecting the code, I find that this function is not a coroutine. Also this function returns a Future instance, this fact should be mentioned in the doc. ---------- components: asyncio messages: 254939 nosy: ealfie, gvanrossum, haypo, yselivanov priority: normal severity: normal status: open title: doc for BaseEventLoop.run_in_executor() says its a coroutine, but it is not type: enhancement versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 17:01:24 2015 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 19 Nov 2015 22:01:24 +0000 Subject: [issue25675] doc for BaseEventLoop.run_in_executor() says its a coroutine, but it is not In-Reply-To: <1447970161.65.0.436017258107.issue25675@psf.upfronthosting.co.za> Message-ID: <1447970484.46.0.410319845911.issue25675@psf.upfronthosting.co.za> Changes by Guido van Rossum : ---------- keywords: +easy priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 17:02:49 2015 From: report at bugs.python.org (Nicolas Demarchi) Date: Thu, 19 Nov 2015 22:02:49 +0000 Subject: [issue25675] doc for BaseEventLoop.run_in_executor() says its a coroutine, but it is not In-Reply-To: <1447970161.65.0.436017258107.issue25675@psf.upfronthosting.co.za> Message-ID: <1447970569.09.0.593905928526.issue25675@psf.upfronthosting.co.za> Changes by Nicolas Demarchi : ---------- nosy: +gilgamezh _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 17:24:30 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 19 Nov 2015 22:24:30 +0000 Subject: [issue18620] multiprocessing page leaves out important part of Pool example In-Reply-To: <1375389044.82.0.349700607179.issue18620@psf.upfronthosting.co.za> Message-ID: <1447971870.27.0.89719859742.issue18620@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: docs at python -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 17:36:59 2015 From: report at bugs.python.org (Richard Tupper) Date: Thu, 19 Nov 2015 22:36:59 +0000 Subject: [issue25676] Bug Message-ID: <1447972619.43.0.147160136943.issue25676@psf.upfronthosting.co.za> New submission from Richard Tupper: resolved ---------- components: Windows files: Garcinia Cambogia Free Trial UK.html messages: 254940 nosy: omskinbourbe1977, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Bug type: enhancement versions: Python 2.6 Added file: http://bugs.python.org/file41088/Garcinia Cambogia Free Trial UK.html _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 17:43:00 2015 From: report at bugs.python.org (David Bolen) Date: Thu, 19 Nov 2015 22:43:00 +0000 Subject: [issue25674] test_ssl (test_algorithms) failures on bolen-ubuntu slaves: sha256.tbs-internet.com unknown host In-Reply-To: <1447970078.37.0.506919207401.issue25674@psf.upfronthosting.co.za> Message-ID: <1447972980.41.0.917854927452.issue25674@psf.upfronthosting.co.za> David Bolen added the comment: Ah, it appears that the transient_internet context manager in the test causes it to be skipped if the host is unknown. So mine was just "lucky" in that it fell back to connecting somewhere else. I've removed my resolver search path on bolen-ubuntu which will resolve the test failures on that slave, but I presume test_algorithms is never being run by anyone at this point. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 17:43:18 2015 From: report at bugs.python.org (Zachary Ware) Date: Thu, 19 Nov 2015 22:43:18 +0000 Subject: [issue25676] Bug In-Reply-To: <1447972619.43.0.147160136943.issue25676@psf.upfronthosting.co.za> Message-ID: <1447972998.64.0.240790778898.issue25676@psf.upfronthosting.co.za> Changes by Zachary Ware : Removed file: http://bugs.python.org/file41088/Garcinia Cambogia Free Trial UK.html _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 17:45:27 2015 From: report at bugs.python.org (Zachary Ware) Date: Thu, 19 Nov 2015 22:45:27 +0000 Subject: [issue25676] Spam In-Reply-To: <1447972619.43.0.147160136943.issue25676@psf.upfronthosting.co.za> Message-ID: <1447973127.86.0.48858230967.issue25676@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- components: -Windows resolution: -> not a bug stage: -> resolved status: open -> closed title: Bug -> Spam type: enhancement -> versions: -Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 17:47:37 2015 From: report at bugs.python.org (Zachary Ware) Date: Thu, 19 Nov 2015 22:47:37 +0000 Subject: [issue25674] test_ssl (test_algorithms) failures on bolen-ubuntu slaves: sha256.tbs-internet.com unknown host In-Reply-To: <1447970078.37.0.506919207401.issue25674@psf.upfronthosting.co.za> Message-ID: <1447973257.01.0.430505258732.issue25674@psf.upfronthosting.co.za> Zachary Ware added the comment: So the mystery of that buildbot is solved, but I think that test needs some work. ---------- keywords: +buildbot nosy: +alex, christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 18:12:43 2015 From: report at bugs.python.org (tzickel) Date: Thu, 19 Nov 2015 23:12:43 +0000 Subject: [issue25083] Python can sometimes create incorrect .pyc files In-Reply-To: <1442143572.78.0.211523310189.issue25083@psf.upfronthosting.co.za> Message-ID: <1447974763.52.0.70669940551.issue25083@psf.upfronthosting.co.za> tzickel added the comment: Meador Inge any other questions regarding the issue ? I can't believe 2.7.11 is coming out soon, and nobody is taking this issue seriously enough... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 18:30:01 2015 From: report at bugs.python.org (Brett Cannon) Date: Thu, 19 Nov 2015 23:30:01 +0000 Subject: [issue25083] Python can sometimes create incorrect .pyc files In-Reply-To: <1442143572.78.0.211523310189.issue25083@psf.upfronthosting.co.za> Message-ID: <1447975801.53.0.886379742452.issue25083@psf.upfronthosting.co.za> Brett Cannon added the comment: As I said previously, tzickel, this is an edge case in Python 2.7 which means it has a low priority for most core developers. Realize that we are also working towards a Python 3.5.1 release and a 3.4.4 release as well (which will be the first and last bugfix release for those feature releases, respectively). Compare that to Python 2.7 which probably has 10 more bugfix releases and where this issue has now existed for five years and this is the first report for it, meaning we are not rushing to get it done with other pressing issues to work on. I realize it's serious to *you*, but that unfortunately doesn't translate it to it being as important to everyone else so please be patient. If this is still an issue for you then consider deleting all of your .pyc files and switching off bytecode file generation: https://docs.python.org/2/library/sys.html#sys.dont_write_bytecode . ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 19:41:08 2015 From: report at bugs.python.org (Steve Harris) Date: Fri, 20 Nov 2015 00:41:08 +0000 Subject: [issue23788] test_urllib2_localnet.test_bad_address fails: OSError not raised by urlopen In-Reply-To: <1427458701.93.0.881295834482.issue23788@psf.upfronthosting.co.za> Message-ID: <1447980068.87.0.591843352537.issue23788@psf.upfronthosting.co.za> Steve Harris added the comment: I experienced the same problem on my system: OS: Xubuntu/Linux 12.04 $ uname -a Linux ives 3.2.0-94-generic #134-Ubuntu SMP Fri Nov 6 18:17:08 UTC 2015 i686 i686 i386 GNU/Linux $ gcc --version gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 ================================================= In response to your last request, here's what I get: $ ./python Python 3.5.0 (default, Nov 19 2015, 17:12:32) [GCC 4.6.3] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import socket >>> socket.create_connection(("sadflkjsasf.i.nvali.d.", 80)) >>> ================================================= And: $ cat /etc/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 127.0.0.1 search domain.actdsltmp ================================================= My ISP is Verizon. Hope this is help ---------- nosy: +Steve Harris _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 20:53:04 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 20 Nov 2015 01:53:04 +0000 Subject: [issue9504] signal.signal/signal.alarm not working as expected In-Reply-To: <1280910836.88.0.645209486589.issue9504@psf.upfronthosting.co.za> Message-ID: <1447984384.58.0.341970449453.issue9504@psf.upfronthosting.co.za> Martin Panter added the comment: With Python?s current technique for signal handling, I think there is always going to be a window where a signal can arrive at the low level after checking the Python flag and before starting a blocking call. If you need to robustly handle a signal maybe it is better to use set_signal_fd() and select() or something. I haven?t looked at the patch closely, but it sounds like it could reduce the size of the window. This would make interactive signals like SIGINT more reliable, so it may be worthwhile. It probably needs properly reviewing in light of the recent EINTR (PEP 457) changes though. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 20:58:19 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 20 Nov 2015 01:58:19 +0000 Subject: [issue25666] Python unexpectedly ignores a signal after fork In-Reply-To: <1447923633.78.0.317393195352.issue25666@psf.upfronthosting.co.za> Message-ID: <1447984699.59.0.414435601246.issue25666@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a modified version of the script that is not a slow fork bomb. In the original, if time.sleep(600) fails to be interrupted, the children end up continuing the loop and forking more children. I tried Python 3.5, 2.7 and 3.4. I am seeing the signal completely ignored (at the Python level), not just ignored ?for a short while?. Here is a sample output: $ python3 example.py Python handler called Parent waiting for child Got exit status 0x0000 === Parent waiting for child Child: 0 Child: 1 Child: 2 Child: 3 Child: 4 Child: 5 Got exit status 0x0100 David may be right that it is an OS thing, though it does not seem likely IMO. It needs more investigation or expert knowledge. But I would like to point out that even if the bug of the signal being completely ignored is fixed, the code still has a race condition. The signal could arrive in the window between when Python checks for signals and when it calls sleep(). Then the signal will be ignored until sleep() has returned. If you need this code to be robust, I suggest looking at set_signal_fd() and select(). ---------- nosy: +martin.panter versions: +Python 3.5, Python 3.6 Added file: http://bugs.python.org/file41089/example.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 20:59:53 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 20 Nov 2015 01:59:53 +0000 Subject: [issue9504] signal.signal/signal.alarm not working as expected In-Reply-To: <1280910836.88.0.645209486589.issue9504@psf.upfronthosting.co.za> Message-ID: <1447984793.44.0.348658615321.issue9504@psf.upfronthosting.co.za> Martin Panter added the comment: Sorry, EINTR changes were PEP 475. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 21:39:36 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 20 Nov 2015 02:39:36 +0000 Subject: [issue25583] os.makedirs with exist_ok=True raises PermissionError on Windows 7^ In-Reply-To: <1446993273.85.0.222873165522.issue25583@psf.upfronthosting.co.za> Message-ID: <20151120023932.18204.60686@psf.io> Roundup Robot added the comment: New changeset 05d6ddf2b7c2 by Martin Panter in branch '3.4': Issue #25583: Avoid incorrect errors raised by os.makedirs(exist_ok=True) https://hg.python.org/cpython/rev/05d6ddf2b7c2 New changeset 515f76bf1254 by Martin Panter in branch '3.5': Issue #25583: Merge makedirs fix from 3.4 into 3.5 https://hg.python.org/cpython/rev/515f76bf1254 New changeset f0ad5067879b by Martin Panter in branch 'default': Issue #25583: Merge makedirs fix from 3.5 https://hg.python.org/cpython/rev/f0ad5067879b New changeset 6ec093f78266 by Martin Panter in branch 'default': Issue #25583: Add news to 3.6 section https://hg.python.org/cpython/rev/6ec093f78266 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 22:47:36 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 20 Nov 2015 03:47:36 +0000 Subject: [issue25583] os.makedirs with exist_ok=True raises PermissionError on Windows 7^ In-Reply-To: <1446993273.85.0.222873165522.issue25583@psf.upfronthosting.co.za> Message-ID: <1447991256.53.0.453043195491.issue25583@psf.upfronthosting.co.za> Martin Panter added the comment: None of the Windows buildbots are failing my particular test. There are other failures, but they look unrelated, so I am calling this fixed. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 00:50:56 2015 From: report at bugs.python.org (Michael Layzell) Date: Fri, 20 Nov 2015 05:50:56 +0000 Subject: [issue25677] Syntax error caret confused by indentation Message-ID: <1447998656.06.0.471632717786.issue25677@psf.upfronthosting.co.za> New submission from Michael Layzell: It appears that syntax errors generated by checking the AST will get confused by indentation and place the caret incorrectly. With no indentation: === 1 + 1 = 2 === File "/Users/mlayzell/test.py", line 1 1 + 1 = 2 ^ SyntaxError: can't assign to operator === With 4 spaces of indentation: === if True: 1 + 1 = 2 === File "/Users/mlayzell/test.py", line 2 1 + 1 = 2 ^ SyntaxError: can't assign to operator === As you can see, the caret appears to be placed randomly in the middle of the second statement, apparently offset (probably by the 4 space indentation). The above examples were run with Python3.5 on Mac OS X 10.10.4, though my somewhat-recent trunk clone exhibits the same problems. ---------- components: Interpreter Core messages: 254951 nosy: Michael Layzell priority: normal severity: normal status: open title: Syntax error caret confused by indentation type: behavior versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 01:16:09 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 20 Nov 2015 06:16:09 +0000 Subject: [issue25669] unittest.assertEqual() on un-equal types inheriting from collections.Mapping In-Reply-To: <1447945164.43.0.781001179378.issue25669@psf.upfronthosting.co.za> Message-ID: <1448000169.49.0.647625859314.issue25669@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 01:21:49 2015 From: report at bugs.python.org (irdb) Date: Fri, 20 Nov 2015 06:21:49 +0000 Subject: [issue7676] IDLE shell shouldn't use TABs In-Reply-To: <1263213381.47.0.181451927584.issue7676@psf.upfronthosting.co.za> Message-ID: <1448000509.78.0.166731683621.issue7676@psf.upfronthosting.co.za> Changes by irdb : ---------- nosy: +irdb _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 02:16:26 2015 From: report at bugs.python.org (SilentGhost) Date: Fri, 20 Nov 2015 07:16:26 +0000 Subject: [issue20898] Missing 507 response description In-Reply-To: <1394637244.26.0.361164120424.issue20898@psf.upfronthosting.co.za> Message-ID: <1448003786.72.0.929469933846.issue20898@psf.upfronthosting.co.za> SilentGhost added the comment: Re msg233465: it doesn't seem like a particularly good justification to remove something that is not hurting anyone. The problem now is that because http.HTTPStatus is an enumeration, it cannot be extended, therefore when someone encounters these non-standard codes, the only option is to just use the integers. I trust what Demian is saying, that there might be some clashing between the non-standard codes, but until it's shown to be a problem removing real-world use cases just actively reduces usefulness of the library. For comparison, the module that is actually used by people includes the whole lot https://github.com/kennethreitz/requests/blob/master/requests/status_codes.py ---------- nosy: +SilentGhost _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 02:37:40 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 20 Nov 2015 07:37:40 +0000 Subject: [issue25672] set SSL_MODE_RELEASE_BUFFERS In-Reply-To: <1447957027.04.0.0951767236546.issue25672@psf.upfronthosting.co.za> Message-ID: <1448005060.86.0.0541212954655.issue25672@psf.upfronthosting.co.za> Benjamin Peterson added the comment: It might be better to do a runtime OpenSSL version check in case someone upgrades or downgrades to an vulnerable version without recompiling Python. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 02:51:16 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 20 Nov 2015 07:51:16 +0000 Subject: [issue25670] ast.NodeTransformer: remove duplicate getattr() In-Reply-To: <1447945864.74.0.854545532845.issue25670@psf.upfronthosting.co.za> Message-ID: <20151120075113.14359.17130@psf.io> Roundup Robot added the comment: New changeset 7789f338447f by Victor Stinner in branch '3.5': Issue #25670: Remove duplicate getattr() from ast.NodeTransformer https://hg.python.org/cpython/rev/7789f338447f New changeset 2d90f4b27743 by Victor Stinner in branch 'default': Merge 3.5 (issue #25670) https://hg.python.org/cpython/rev/2d90f4b27743 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 03:11:42 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 20 Nov 2015 08:11:42 +0000 Subject: [issue25626] Gzip fails for file over 2**32 bytes In-Reply-To: <1447530501.75.0.968129152166.issue25626@psf.upfronthosting.co.za> Message-ID: <1448007102.78.0.587038406343.issue25626@psf.upfronthosting.co.za> Martin Panter added the comment: Actually it did make an existing bug a bit worse. The bug is triggered with valid sizes greater than LONG_MAX, due to an exception not being cleared, and my change made this bug more dramatic, turning the OverflowError into a crash. This new patch should fix that. I?m now looking at adding the other tests that require allocating lots of memory. ---------- Added file: http://bugs.python.org/file41090/zlib-size_t.2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 03:20:00 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 20 Nov 2015 08:20:00 +0000 Subject: [issue25670] ast.NodeTransformer: remove duplicate getattr() In-Reply-To: <1447945864.74.0.854545532845.issue25670@psf.upfronthosting.co.za> Message-ID: <1448007600.56.0.479455469566.issue25670@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 03:27:56 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 20 Nov 2015 08:27:56 +0000 Subject: [issue25557] Optimize LOAD_NAME bytecode In-Reply-To: <1446718279.47.0.148828829851.issue25557@psf.upfronthosting.co.za> Message-ID: <20151120082753.36879.63160@psf.io> Roundup Robot added the comment: New changeset c35d65c9ded3 by Victor Stinner in branch 'default': Issue #25557: Refactor _PyDict_LoadGlobal() https://hg.python.org/cpython/rev/c35d65c9ded3 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 03:28:57 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 20 Nov 2015 08:28:57 +0000 Subject: [issue25557] Optimize LOAD_NAME bytecode In-Reply-To: <1446718279.47.0.148828829851.issue25557@psf.upfronthosting.co.za> Message-ID: <1448008137.37.0.601867172564.issue25557@psf.upfronthosting.co.za> STINNER Victor added the comment: Since LOAD_NAME is rare, I don't think that it's worth to optimize it. I pushed a partial version of pydict_loadname-2.patch to add comments to the code. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 03:40:40 2015 From: report at bugs.python.org (Sven Berkvens-Matthijsse) Date: Fri, 20 Nov 2015 08:40:40 +0000 Subject: [issue25678] int() from a buffer reads past the buffer boundaries Message-ID: <1448008840.02.0.961643049915.issue25678@psf.upfronthosting.co.za> New submission from Sven Berkvens-Matthijsse: Calling int() or long() on a buffer() object in Python 2.7 does not do the right thing. The following code snippet: buf = buffer("123test", 1, 2) print buf print int(buf) does not do what I would expect (that it print "23" twice). Instead, it prints "23" once and then throws an exception: ValueError: invalid literal for int() with base 10: '23test' This is caused by Objects/abstract.c function int_from_string(), which gets passed the length of the string but does not actually use that information to limit what part is parsed from the string. It only uses it to check for embedded NUL bytes. The real culprit is probably PyInt_FromString() which does not take a length indicator. ---------- components: Interpreter Core messages: 254958 nosy: svenberkvens priority: normal severity: normal status: open title: int() from a buffer reads past the buffer boundaries type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 03:58:24 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 20 Nov 2015 08:58:24 +0000 Subject: [issue25557] Optimize LOAD_NAME bytecode In-Reply-To: <1446718279.47.0.148828829851.issue25557@psf.upfronthosting.co.za> Message-ID: <1448009904.6.0.511304739497.issue25557@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thanks Victor. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 03:59:33 2015 From: report at bugs.python.org (Cory Benfield) Date: Fri, 20 Nov 2015 08:59:33 +0000 Subject: [issue25672] set SSL_MODE_RELEASE_BUFFERS In-Reply-To: <1447957027.04.0.0951767236546.issue25672@psf.upfronthosting.co.za> Message-ID: <1448009973.77.0.0670831913694.issue25672@psf.upfronthosting.co.za> Cory Benfield added the comment: Good idea Benjamin. I've uploaded a second patch that adjusts the check to be a runtime one, rather than a compiled one. ---------- Added file: http://bugs.python.org/file41091/ssl2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 04:07:10 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 20 Nov 2015 09:07:10 +0000 Subject: [issue25669] unittest.assertEqual() on un-equal types inheriting from collections.Mapping In-Reply-To: <1447945164.43.0.781001179378.issue25669@psf.upfronthosting.co.za> Message-ID: <1448010430.71.0.721442920778.issue25669@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: rhettinger -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 04:07:22 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 20 Nov 2015 09:07:22 +0000 Subject: [issue25669] unittest.assertEqual() on un-equal types inheriting from collections.Mapping In-Reply-To: <1447945164.43.0.781001179378.issue25669@psf.upfronthosting.co.za> Message-ID: <1448010442.45.0.95142333018.issue25669@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- versions: +Python 3.6 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 04:12:51 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Fri, 20 Nov 2015 09:12:51 +0000 Subject: [issue25672] set SSL_MODE_RELEASE_BUFFERS In-Reply-To: <1447957027.04.0.0951767236546.issue25672@psf.upfronthosting.co.za> Message-ID: <1448010771.08.0.361627637764.issue25672@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: The release buffer mode bugs were fixed in 1.0.0m and 1.0.1h: https://openssl.org/news/vulnerabilities.html#y2014 CVE-2014-0198 (OpenSSL advisory) 21st April 2014: A flaw in the do_ssl3_write function can allow remote attackers to cause a denial of service via a NULL pointer dereference. This flaw only affects OpenSSL 1.0.0 and 1.0.1 where SSL_MODE_RELEASE_BUFFERS is enabled, which is not the default and not common. Fixed in OpenSSL 1.0.1h (Affected 1.0.1g, 1.0.1f, 1.0.1e, 1.0.1d, 1.0.1c, 1.0.1b, 1.0.1a, 1.0.1) Fixed in OpenSSL 1.0.0m (Affected 1.0.0l, 1.0.0k, 1.0.0j, 1.0.0i, 1.0.0g, 1.0.0f, 1.0.0e, 1.0.0d, 1.0.0c, 1.0.0b, 1.0.0a, 1.0.0) CVE-2010-5298 (OpenSSL advisory) 8th April 2014: A race condition in the ssl3_read_bytes function can allow remote attackers to inject data across sessions or cause a denial of service. This flaw only affects multithreaded applications using OpenSSL 1.0.0 and 1.0.1, where SSL_MODE_RELEASE_BUFFERS is enabled, which is not the default and not common. Fixed in OpenSSL 1.0.1h (Affected 1.0.1g, 1.0.1f, 1.0.1e, 1.0.1d, 1.0.1c, 1.0.1b, 1.0.1a, 1.0.1) Fixed in OpenSSL 1.0.0m (Affected 1.0.0l, 1.0.0k, 1.0.0j, 1.0.0i, 1.0.0g, 1.0.0f, 1.0.0e, 1.0.0d, 1.0.0c, 1.0.0b, 1.0.0a, 1.0.0) PS: OpenSSL normally doesn't issue betas. All their releases are final. The numbering scheme is a bit weird - perhaps they'll change to a more common one with 1.1 (this will have a beta cycle): https://openssl.org/policies/releasestrat.html ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 04:13:31 2015 From: report at bugs.python.org (Novice Live) Date: Fri, 20 Nov 2015 09:13:31 +0000 Subject: [issue25679] Fix typo in Doc/reference/executionmodel.rst Message-ID: <1448010811.87.0.415617545534.issue25679@psf.upfronthosting.co.za> New submission from Novice Live: > 4. Execution model > 4.1. Structure of a programm You see. ---------- assignee: docs at python components: Documentation files: executionmodel-typo.patch keywords: patch messages: 254962 nosy: docs at python, n0vicelive priority: normal severity: normal status: open title: Fix typo in Doc/reference/executionmodel.rst Added file: http://bugs.python.org/file41092/executionmodel-typo.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 04:45:44 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 20 Nov 2015 09:45:44 +0000 Subject: [issue25626] Gzip fails for file over 2**32 bytes In-Reply-To: <1447530501.75.0.968129152166.issue25626@psf.upfronthosting.co.za> Message-ID: <1448012744.53.0.465814958463.issue25626@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ah, I found yet one bug. >>> zlib.decompress(zlib.compress(b'abcd'), 0, sys.maxsize+1) Traceback (most recent call last): File "", line 1, in SystemError: Negative size passed to PyBytes_FromStringAndSize There are similar bugs in decompressor's methods decompress() and flush() but it is hard to reproduce them. The maximal length value should be bounded not only with UINT_MAX, but with PY_SSIZE_T_MAX too. I would merge sval and uval into one variable of type Py_ssize_t. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 05:45:32 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 20 Nov 2015 10:45:32 +0000 Subject: [issue25678] int() from a buffer reads past the buffer boundaries In-Reply-To: <1448008840.02.0.961643049915.issue25678@psf.upfronthosting.co.za> Message-ID: <1448016332.16.0.399852766742.issue25678@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This is similar to issue24802. The patch for issue24802 was not backported to 2.7 because affected functions don't accept memoryview in Python 2. Now we have an example, and can backport that patch. ---------- nosy: +martin.panter, serhiy.storchaka stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 05:52:24 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 20 Nov 2015 10:52:24 +0000 Subject: [issue25669] unittest.assertEqual() on un-equal types inheriting from collections.Mapping In-Reply-To: <1447945164.43.0.781001179378.issue25669@psf.upfronthosting.co.za> Message-ID: <1448016744.58.0.933611627671.issue25669@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +ezio.melotti, michael.foord, rbcollins _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 06:05:40 2015 From: report at bugs.python.org (JGoutin) Date: Fri, 20 Nov 2015 11:05:40 +0000 Subject: [issue25646] Distutils and Windows SDK 7.0 / Windows SDK 7.1 / Visual C++ Build Tools 2015 In-Reply-To: <1447756303.67.0.435034104806.issue25646@psf.upfronthosting.co.za> Message-ID: <1448017540.88.0.465310938983.issue25646@psf.upfronthosting.co.za> JGoutin added the comment: I updated the file. I did some new tests with cross compilation and I see that the "libpath" environment variable may be missing in some case. Fortunately, this one is not used in the following of the code. So I set it as optional result for "query_vcvarsall". ---------- Added file: http://bugs.python.org/file41093/msvc9compiler.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 06:10:00 2015 From: report at bugs.python.org (Cory Benfield) Date: Fri, 20 Nov 2015 11:10:00 +0000 Subject: [issue25672] set SSL_MODE_RELEASE_BUFFERS In-Reply-To: <1447957027.04.0.0951767236546.issue25672@psf.upfronthosting.co.za> Message-ID: <1448017800.19.0.946147791129.issue25672@psf.upfronthosting.co.za> Cory Benfield added the comment: Thanks for the updated info Marc-Andre. Yeah, while generally speaking OpenSSL doesn't ship betas, it does provide them as tarballs. I have a beta of 1.0.2 floating around somewhere on my machine that I was using for ALPN testing back in 2014, and so I can speak from personal experience and say that people do actually work with betas sometimes. On this issue (defending ourselves from a CVE) my instinct is to be conservative. However, we should allow later patch releases of OpenSSL 1.0.0 to have this optimisation if they're safe. Therefore, I've uploaded a new patch that does allow for 1.0.0m and later to use this optimisation too. It makes the conditional a little more complex, but c'est la vie. ---------- Added file: http://bugs.python.org/file41094/ssl3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 06:11:47 2015 From: report at bugs.python.org (Eryk Sun) Date: Fri, 20 Nov 2015 11:11:47 +0000 Subject: [issue25678] int() from a buffer reads past the buffer boundaries In-Reply-To: <1448008840.02.0.961643049915.issue25678@psf.upfronthosting.co.za> Message-ID: <1448017907.17.0.608997461396.issue25678@psf.upfronthosting.co.za> Eryk Sun added the comment: > Now we have an example, and can backport that patch. More seriously it's possible to get a buffer over-read using NumPy: >>> import numpy >>> int(buffer(numpy.array('123', dtype='c'))) Traceback (most recent call last): File "", line 1, in ValueError: invalid literal for int() with base 10: '123\xe1\x18\x7f' I backported the modification to PyNumber_Int and PyNumber_Long, using PyString_FromStringAndSize and PyString_AS_STRING. It works as expected: Python 2.7.10+ (2.7:5d88c1d413b9+, Nov 20 2015, 04:58:55) [GCC 4.8.4] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> int(buffer('123test', 1, 2)) 23 [41951 refs] >>> long(buffer('123test', 1, 2)) 23L [41952 refs] ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 06:19:18 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 20 Nov 2015 11:19:18 +0000 Subject: [issue25678] int() from a buffer reads past the buffer boundaries In-Reply-To: <1448008840.02.0.961643049915.issue25678@psf.upfronthosting.co.za> Message-ID: <1448018358.31.0.946399948084.issue25678@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Do you forgot to add a patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 06:24:01 2015 From: report at bugs.python.org (Eryk Sun) Date: Fri, 20 Nov 2015 11:24:01 +0000 Subject: [issue25678] int() from a buffer reads past the buffer boundaries In-Reply-To: <1448008840.02.0.961643049915.issue25678@psf.upfronthosting.co.za> Message-ID: <1448018641.56.0.019355785145.issue25678@psf.upfronthosting.co.za> Eryk Sun added the comment: I just made a quick modification to check that it works. I'm sure you could do the same. But here it is anyway. ---------- keywords: +patch Added file: http://bugs.python.org/file41095/issue25678.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 06:34:16 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 20 Nov 2015 11:34:16 +0000 Subject: [issue25678] int() from a buffer reads past the buffer boundaries In-Reply-To: <1448008840.02.0.961643049915.issue25678@psf.upfronthosting.co.za> Message-ID: <1448019256.08.0.74361821982.issue25678@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could you backport full patch, with tests? And compile() is affected too: >>> compile(buffer("123\0test", 1, 2), '', 'exec') at 0xb70c5800, file "", line 1> >>> compile(buffer("123test", 1, 2), '', 'exec') Traceback (most recent call last): File "", line 1, in TypeError: compile() expected string without null bytes ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 06:51:36 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Fri, 20 Nov 2015 11:51:36 +0000 Subject: [issue25672] set SSL_MODE_RELEASE_BUFFERS In-Reply-To: <1448017800.19.0.946147791129.issue25672@psf.upfronthosting.co.za> Message-ID: <564F0940.6060800@egenix.com> Marc-Andre Lemburg added the comment: On 20.11.2015 12:10, Cory Benfield wrote: > Yeah, while generally speaking OpenSSL doesn't ship betas, it does provide them as tarballs. I have a beta of 1.0.2 floating around somewhere on my machine that I was using for ALPN testing back in 2014, and so I can speak from personal experience and say that people do actually work with betas sometimes. On this issue (defending ourselves from a CVE) my instinct is to be conservative. However, we should allow later patch releases of OpenSSL 1.0.0 to have this optimisation if they're safe. Ah, right. For new major release versions such as 1.0.1 or 1.0.2 they do ship betas, but historically they have often introduced new features in their abcde... level releases without doing betas for those first - that's what I was thinking of :-) > Therefore, I've uploaded a new patch that does allow for 1.0.0m and later to use this optimisation too. It makes the conditional a little more complex, but c'est la vie. LGTM Thanks, -- Marc-Andre Lemburg eGenix.com ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 07:51:35 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 20 Nov 2015 12:51:35 +0000 Subject: [issue25626] Gzip fails for file over 2**32 bytes In-Reply-To: <1447530501.75.0.968129152166.issue25626@psf.upfronthosting.co.za> Message-ID: <1448023895.87.0.574047445591.issue25626@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks for your testing Serhiy. I can reproduce this on 32-bit Linux (also by building with CC="gcc -m32"). It is easy to produce the bug with flush(), but with Decompress.decompress() it would need over 2?GiB of memory and data to expand the buffer enough to trigger the error. >>> zlib.decompressobj().flush(sys.maxsize + 1) SystemError: Negative size passed to PyBytes_FromStringAndSize In zlib-Py_ssize_t.patch, I added the bigmem tests, but I am not able to actually test them. The gzip test would require 8?GiB of memory. I also changed the converter to Py_ssize_t to fix this latest bug. ---------- Added file: http://bugs.python.org/file41096/zlib-Py_ssize_t.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 08:05:51 2015 From: report at bugs.python.org (Davin Potts) Date: Fri, 20 Nov 2015 13:05:51 +0000 Subject: [issue25656] multiprocessing.dummy: pool.map hangs on empty list In-Reply-To: <1447855498.22.0.263851728204.issue25656@psf.upfronthosting.co.za> Message-ID: <1448024751.89.0.472100424498.issue25656@psf.upfronthosting.co.za> Davin Potts added the comment: I am unable to reproduce the behavior you describe using the code you provided. I've tried on both the current Linux Mint release (64-bit) and OS X 10.10 using the current Python 2.7 release (2.7.10). Could you be more specific about what platform you are using and the precise (2.7.?) version of Python? Anything else that might be missing from your example to help us reproduce? ---------- nosy: +davin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 08:41:29 2015 From: report at bugs.python.org (Jan Malte) Date: Fri, 20 Nov 2015 13:41:29 +0000 Subject: [issue16811] email.message.Message flatten dies of list index out of range In-Reply-To: <1356776594.55.0.534961583044.issue16811@psf.upfronthosting.co.za> Message-ID: <1448026889.79.0.261349587829.issue16811@psf.upfronthosting.co.za> Jan Malte added the comment: seems like this happens still, if the CC header starts with a new line character. Python 3.4.3 ---------- nosy: +janmalte _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 09:18:22 2015 From: report at bugs.python.org (Aleksey Kladov) Date: Fri, 20 Nov 2015 14:18:22 +0000 Subject: [issue25680] Selector.select() hangs when there is nothing to select Message-ID: <1448029102.96.0.470819036773.issue25680@psf.upfronthosting.co.za> New submission from Aleksey Kladov: The following hangs on Linux ```Python >>> import selectors >>> s = selectors.DefaultSelector() >>> s.select() ``` On Mac it returns an empty list. ---------- messages: 254975 nosy: Aleksey Kladov priority: normal severity: normal status: open title: Selector.select() hangs when there is nothing to select versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 09:23:12 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 20 Nov 2015 14:23:12 +0000 Subject: [issue25626] Gzip fails for file over 2**32 bytes In-Reply-To: <1447530501.75.0.968129152166.issue25626@psf.upfronthosting.co.za> Message-ID: <1448029392.13.0.0655128071694.issue25626@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Added new comments. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 09:36:38 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 20 Nov 2015 14:36:38 +0000 Subject: [issue25680] Selector.select() hangs when there is nothing to select In-Reply-To: <1448029102.96.0.470819036773.issue25680@psf.upfronthosting.co.za> Message-ID: <1448030198.7.0.693514644561.issue25680@psf.upfronthosting.co.za> STINNER Victor added the comment: Your code doesn't make sense. You listen to 0 file descriptor and wait forever until you get events, which will never occur. I'm not even sure that it should be allowed by the Selector API. What's the point of your bug report? Does your application really rely on the behaviour of the selector when no file descriptor is registered? The behaviour changes between Linux and OS X because the "default" selector is a different selector on Linux (epoll) and OS X (kqueue? select?) ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 09:39:48 2015 From: report at bugs.python.org (Yan) Date: Fri, 20 Nov 2015 14:39:48 +0000 Subject: [issue25681] Assignment of one element in nested list changes multiple elements Message-ID: <1448030388.6.0.28566235581.issue25681@psf.upfronthosting.co.za> New submission from Yan: Is this the correct behavior? >>> l=[['']*2]*3 >>> b=[['', ''], ['', ''], ['', '']] >>> l == b True >>> l[0][1]='A' >>> b[0][1]='A' >>> l == b False >>> l [['', 'A'], ['', 'A'], ['', 'A']] >>> b [['', 'A'], ['', ''], ['', '']] ---------- messages: 254978 nosy: ydu priority: normal severity: normal status: open title: Assignment of one element in nested list changes multiple elements type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 09:40:32 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 20 Nov 2015 14:40:32 +0000 Subject: [issue25677] Syntax error caret confused by indentation In-Reply-To: <1447998656.06.0.471632717786.issue25677@psf.upfronthosting.co.za> Message-ID: <1448030432.96.0.512310709351.issue25677@psf.upfronthosting.co.za> R. David Murray added the comment: It appears as though the line is always printed without the leading whitespace, but the caret takes the whitespace into account (try indenting the line even further). So the problem is that the caret and the printing of the source line in the error message are not consistent about how whitespace is handled. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 09:43:03 2015 From: report at bugs.python.org (Emanuel Barry) Date: Fri, 20 Nov 2015 14:43:03 +0000 Subject: [issue25681] Assignment of one element in nested list changes multiple elements In-Reply-To: <1448030388.6.0.28566235581.issue25681@psf.upfronthosting.co.za> Message-ID: <1448030583.59.0.54836569837.issue25681@psf.upfronthosting.co.za> Emanuel Barry added the comment: Your list `l` actually holds only one list, except three times. When you change it, it's reflected in all the lists. It's the equivalent of the following: >>> x=['', ''] >>> l=[x, x, x] Makes a bit more sense this way? Either way, yes, this is intentional behaviour. ---------- nosy: +ebarry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 09:44:12 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 20 Nov 2015 14:44:12 +0000 Subject: [issue25677] Syntax error caret confused by indentation In-Reply-To: <1447998656.06.0.471632717786.issue25677@psf.upfronthosting.co.za> Message-ID: <1448030652.19.0.660422949189.issue25677@psf.upfronthosting.co.za> R. David Murray added the comment: By the way, python3.4 also shows the behavior. Python2 does not, because python2 does not print the caret. The bug presumably crept in when the caret was added. I'm marking this as easy...presumably the hardest part of fixing it is figuring out exactly how the message is constructed :) ---------- keywords: +easy stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 09:45:14 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 20 Nov 2015 14:45:14 +0000 Subject: [issue9504] signal.signal/signal.alarm not working as expected In-Reply-To: <1280910836.88.0.645209486589.issue9504@psf.upfronthosting.co.za> Message-ID: <1448030714.52.0.939240654789.issue9504@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 09:48:06 2015 From: report at bugs.python.org (Emanuel Barry) Date: Fri, 20 Nov 2015 14:48:06 +0000 Subject: [issue25681] Assignment of one element in nested list changes multiple elements In-Reply-To: <1448030388.6.0.28566235581.issue25681@psf.upfronthosting.co.za> Message-ID: <1448030886.35.0.631064651532.issue25681@psf.upfronthosting.co.za> Emanuel Barry added the comment: Another way to fix this would be the following: >>> l=[[''] * 2 for _ in range(3)] >>> l [['', ''], ['', ''], ['', '']] >>> l[0][1] = "A" >>> l [['', 'A'], ['', ''], ['', '']] The * operator on lists doesn't create new elements, it only adds new references to them. A list comprehension will evaluate the expression each time, while repetition (the * operator) will only evaluate it once. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 09:53:59 2015 From: report at bugs.python.org (Yan) Date: Fri, 20 Nov 2015 14:53:59 +0000 Subject: [issue25681] Assignment of one element in nested list changes multiple elements In-Reply-To: <1448030388.6.0.28566235581.issue25681@psf.upfronthosting.co.za> Message-ID: <1448031239.92.0.826464899719.issue25681@psf.upfronthosting.co.za> Yan added the comment: Thanks for the quick response. It makes sense to me. I misunderstood the * operator. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 10:00:35 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 20 Nov 2015 15:00:35 +0000 Subject: [issue25679] Fix typo in Doc/reference/executionmodel.rst In-Reply-To: <1448010811.87.0.415617545534.issue25679@psf.upfronthosting.co.za> Message-ID: <20151120150028.79037.59836@psf.io> Roundup Robot added the comment: New changeset 3e723559d9f1 by R David Murray in branch '3.4': #25679: spelling fix https://hg.python.org/cpython/rev/3e723559d9f1 New changeset 44ca5e073feb by R David Murray in branch '3.5': Merge: #25679: spelling fix https://hg.python.org/cpython/rev/44ca5e073feb New changeset 14a3cfc477c6 by R David Murray in branch 'default': Merge: #25679: spelling fix https://hg.python.org/cpython/rev/14a3cfc477c6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 10:00:56 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 20 Nov 2015 15:00:56 +0000 Subject: [issue25681] Assignment of one element in nested list changes multiple elements In-Reply-To: <1448030388.6.0.28566235581.issue25681@psf.upfronthosting.co.za> Message-ID: <1448031656.19.0.364884421014.issue25681@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 10:01:58 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 20 Nov 2015 15:01:58 +0000 Subject: [issue25679] Fix typo in Doc/reference/executionmodel.rst In-Reply-To: <1448010811.87.0.415617545534.issue25679@psf.upfronthosting.co.za> Message-ID: <1448031718.53.0.807028889927.issue25679@psf.upfronthosting.co.za> R. David Murray added the comment: Fixed, thanks. I wonder if it was one of our german speakers who typed that :) ---------- nosy: +r.david.murray resolution: -> fixed stage: -> resolved status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 10:04:47 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 20 Nov 2015 15:04:47 +0000 Subject: [issue16811] email.message.Message flatten dies of list index out of range In-Reply-To: <1356776594.55.0.534961583044.issue16811@psf.upfronthosting.co.za> Message-ID: <1448031887.69.0.763557283704.issue16811@psf.upfronthosting.co.za> R. David Murray added the comment: Please open a new issue and provide a reproducer. Thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 10:07:02 2015 From: report at bugs.python.org (JGoutin) Date: Fri, 20 Nov 2015 15:07:02 +0000 Subject: [issue25646] Distutils and Windows SDK 7.1 In-Reply-To: <1447756303.67.0.435034104806.issue25646@psf.upfronthosting.co.za> Message-ID: <1448032022.42.0.373547484502.issue25646@psf.upfronthosting.co.za> JGoutin added the comment: Better compatibility for Architectures names conversion between Vcvarsall.bat and SetEnv.Cmd for cross compilation. This seem to work good on classic compilation, but I still have difficulties with cross-compilation. ---------- title: Distutils and Windows SDK 7.0 / Windows SDK 7.1 / Visual C++ Build Tools 2015 -> Distutils and Windows SDK 7.1 Added file: http://bugs.python.org/file41097/msvc9compiler.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 10:53:48 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 20 Nov 2015 15:53:48 +0000 Subject: [issue25665] typing.NamedTuple instances are not picklable. In-Reply-To: <1447920386.58.0.359968299873.issue25665@psf.upfronthosting.co.za> Message-ID: <1448034828.66.0.0161786691997.issue25665@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The test tests pickling only with default protocol. It would be better to test pickling with all supported protocols. Why special TestCase methods to check for and report failures are not used in test_typing? ---------- nosy: +serhiy.storchaka Added file: http://bugs.python.org/file41098/test_typing_pickle.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 11:02:19 2015 From: report at bugs.python.org (Keith Prussing) Date: Fri, 20 Nov 2015 16:02:19 +0000 Subject: [issue25682] __package__ not set to None under pdb in Python 3 Message-ID: <1448035339.32.0.969832659097.issue25682@psf.upfronthosting.co.za> New submission from Keith Prussing: When a module is run under pdb in Python 3, __package__ is set to the empty string instead of None. The attached minimum working example depicts this behavior. The results are summarized in the following table. =============== ====== ====== Command Py 2 Py 3 =============== ====== ====== python None None python -m '' '' python -m pdb None '' pdb None '' =============== ====== ====== The behavior I expected was for the Python executable to treat the input file as a script and not a module. My rationale is that pdb is loaded as the executing module that accepts a script as its argument. Per the help, only one -m option is allowed when launching python. ---------- components: Extension Modules files: mwe.py messages: 254989 nosy: Keith Prussing priority: normal severity: normal status: open title: __package__ not set to None under pdb in Python 3 type: behavior versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file41099/mwe.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 11:14:11 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 20 Nov 2015 16:14:11 +0000 Subject: [issue25612] nested try..excepts don't work correctly for generators In-Reply-To: <1447361959.0.0.839122121456.issue25612@psf.upfronthosting.co.za> Message-ID: <1448036051.07.0.341098857427.issue25612@psf.upfronthosting.co.za> Yury Selivanov added the comment: Martin, you might be right here. Guido, do you think it's OK that SubError doesn't have MainError in its __context__? http://bugs.python.org/issue25612#msg254576 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 11:16:23 2015 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 20 Nov 2015 16:16:23 +0000 Subject: [issue25612] nested try..excepts don't work correctly for generators In-Reply-To: <1448036051.07.0.341098857427.issue25612@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: I'm sorry, I'm no help here -- I don't know how __context__ is supposed to work. :-( On Fri, Nov 20, 2015 at 8:14 AM, Yury Selivanov wrote: > > Yury Selivanov added the comment: > > Martin, you might be right here. Guido, do you think it's OK that SubError doesn't have MainError in its __context__? http://bugs.python.org/issue25612#msg254576 > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 11:20:39 2015 From: report at bugs.python.org (Michael Layzell) Date: Fri, 20 Nov 2015 16:20:39 +0000 Subject: [issue25677] Syntax error caret confused by indentation In-Reply-To: <1447998656.06.0.471632717786.issue25677@psf.upfronthosting.co.za> Message-ID: <1448036439.34.0.92222720816.issue25677@psf.upfronthosting.co.za> Michael Layzell added the comment: This should fix the problem. It appears as though the indentation was being stripped from the program text differently depending on how the error was produced. In the case of a syntax error from the parser, the indentation was maintained until it was printed (in print_error_text, correctly handling the offset value). In contrast, errors from the AST were created with PyErr_ProgramText*, which would also strip the indentation (without mutating any offset value). This patch causes the second code path to not strip whitespace. This shouldn't cause I problem (I think), as it seems to only be used to instantiate SyntaxErrors. ---------- keywords: +patch Added file: http://bugs.python.org/file41100/cpython25677.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 11:21:12 2015 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 20 Nov 2015 16:21:12 +0000 Subject: [issue25665] typing.NamedTuple instances are not picklable. In-Reply-To: <1447920386.58.0.359968299873.issue25665@psf.upfronthosting.co.za> Message-ID: <1448036472.07.0.748840238444.issue25665@psf.upfronthosting.co.za> Guido van Rossum added the comment: Serhiy, feel free to commit that patch. I was just being lazy. Also, I was using assert instead of self.assertEquals etc. out of laziness (and because at Dropbox people have got the py.test religion and prefer to use assert statements -- but I'm not keen to do this for the stdlib). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 11:29:46 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 20 Nov 2015 16:29:46 +0000 Subject: [issue25683] __context__ for yields inside except clause Message-ID: <1448036986.79.0.682793402944.issue25683@psf.upfronthosting.co.za> New submission from Yury Selivanov: In the below snippet, SubError will propagate with __context__ set to None, instead of MainError. Maybe this isn't a bug? class MainError(Exception): pass class SubError(Exception): pass def main(): try: raise MainError() except MainError: yield coro = main() coro.send(None) coro.throw(SubError()) ---------- components: Interpreter Core messages: 254994 nosy: benjamin.peterson, gvanrossum, haypo, yselivanov priority: normal severity: normal status: open title: __context__ for yields inside except clause type: behavior versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 11:30:09 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 20 Nov 2015 16:30:09 +0000 Subject: [issue25612] nested try..excepts don't work correctly for generators In-Reply-To: <1447361959.0.0.839122121456.issue25612@psf.upfronthosting.co.za> Message-ID: <1448037009.0.0.0437443948843.issue25612@psf.upfronthosting.co.za> Yury Selivanov added the comment: Anyways, here's a separate issue for the __context__ problem: http://bugs.python.org/issue25683 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 11:31:29 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 20 Nov 2015 16:31:29 +0000 Subject: [issue25612] nested try..excepts don't work correctly for generators In-Reply-To: <1447361959.0.0.839122121456.issue25612@psf.upfronthosting.co.za> Message-ID: <1448037089.97.0.887113385954.issue25612@psf.upfronthosting.co.za> Yury Selivanov added the comment: Guido, Martin, I've just posted to python-dev about this ticket. Let's see what others think. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 11:34:02 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 20 Nov 2015 16:34:02 +0000 Subject: [issue25665] typing.NamedTuple instances are not picklable. In-Reply-To: <1447920386.58.0.359968299873.issue25665@psf.upfronthosting.co.za> Message-ID: <20151120163355.105899.17349@psf.io> Roundup Robot added the comment: New changeset 4f30b0d47c24 by Serhiy Storchaka in branch '3.5': Issue #25665: Test pickling with all protocols in test_typing. https://hg.python.org/cpython/rev/4f30b0d47c24 New changeset 9e65015582a5 by Serhiy Storchaka in branch 'default': Issue #25665: Test pickling with all protocols in test_typing. https://hg.python.org/cpython/rev/9e65015582a5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 11:38:50 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 20 Nov 2015 16:38:50 +0000 Subject: [issue25660] tabs don't work correctly in python repl In-Reply-To: <1447876730.91.0.918964104484.issue25660@psf.upfronthosting.co.za> Message-ID: <1448037530.92.0.436434964136.issue25660@psf.upfronthosting.co.za> Yury Selivanov added the comment: Can someone try the patch? I'm fairly confident it should work, and it'd be great to have it fixed in 3.5.1. ---------- priority: high -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 11:59:43 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 20 Nov 2015 16:59:43 +0000 Subject: [issue25646] Distutils and Windows SDK 7.1 In-Reply-To: <1447756303.67.0.435034104806.issue25646@psf.upfronthosting.co.za> Message-ID: <1448038783.19.0.143106646583.issue25646@psf.upfronthosting.co.za> Steve Dower added the comment: I appreciate the enthusiasm, but be aware that at best this will show up in Python 3.4.4 only, and the timeline for that is very short. You would have a better chance if you were to make this a monkey-patch via setuptools. See https://bitbucket.org/pypa/setuptools/src/tip/setuptools/msvc9_support.py for where we added this for the compiler for 2.7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 12:04:24 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 20 Nov 2015 17:04:24 +0000 Subject: [issue25677] Syntax error caret confused by indentation In-Reply-To: <1447998656.06.0.471632717786.issue25677@psf.upfronthosting.co.za> Message-ID: <1448039064.41.0.684184463186.issue25677@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +haypo, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 12:05:08 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 20 Nov 2015 17:05:08 +0000 Subject: [issue25677] Syntax error caret confused by indentation In-Reply-To: <1447998656.06.0.471632717786.issue25677@psf.upfronthosting.co.za> Message-ID: <1448039108.64.0.240537120905.issue25677@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 12:24:23 2015 From: report at bugs.python.org (Eric Snow) Date: Fri, 20 Nov 2015 17:24:23 +0000 Subject: [issue25623] Keep the link to Python implementation of OrderedDict In-Reply-To: <1447488768.43.0.519685796607.issue25623@psf.upfronthosting.co.za> Message-ID: <1448040263.57.0.868789261588.issue25623@psf.upfronthosting.co.za> Eric Snow added the comment: I agree with Raymond. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 12:24:48 2015 From: report at bugs.python.org (Bryan Oakley) Date: Fri, 20 Nov 2015 17:24:48 +0000 Subject: [issue25684] ttk.OptionMenu radiobuttons aren't unique between two instances of OptionMenu Message-ID: <1448040288.53.0.198369542776.issue25684@psf.upfronthosting.co.za> New submission from Bryan Oakley: Original issue was brought to my attention by this SO question: http://stackoverflow.com/questions/33831289/ttk-optionmenu-displaying-check-mark-on-all-menus The ttk.OptionMenu uses radiobuttons for the dropdown menu. However, because it doesn't set the `variable` attribute, they all get the default. If you have two or more OptionMenu instances, all of the radiobuttons are tied together. If you select the first item in the first OptionMenu, and the second item in the second OptionMenu, the dropdown menu for both will show the second item checked. The solution is to add `variable=self._variable` when creating the menu radiobutton items. ---------- components: Tkinter messages: 255001 nosy: Bryan.Oakley priority: normal severity: normal status: open title: ttk.OptionMenu radiobuttons aren't unique between two instances of OptionMenu versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 12:25:41 2015 From: report at bugs.python.org (Bryan Oakley) Date: Fri, 20 Nov 2015 17:25:41 +0000 Subject: [issue25684] ttk.OptionMenu radiobuttons aren't unique between two instances of OptionMenu In-Reply-To: <1448040288.53.0.198369542776.issue25684@psf.upfronthosting.co.za> Message-ID: <1448040341.39.0.166307663781.issue25684@psf.upfronthosting.co.za> Changes by Bryan Oakley : ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 12:26:29 2015 From: report at bugs.python.org (Eryk Sun) Date: Fri, 20 Nov 2015 17:26:29 +0000 Subject: [issue25678] int() from a buffer reads past the buffer boundaries In-Reply-To: <1448008840.02.0.961643049915.issue25678@psf.upfronthosting.co.za> Message-ID: <1448040389.57.0.651413897011.issue25678@psf.upfronthosting.co.za> Changes by Eryk Sun : Added file: http://bugs.python.org/file41101/issue25678_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 12:29:09 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 20 Nov 2015 17:29:09 +0000 Subject: [issue15348] IDLE - shell becomes unresponsive if debugger windows is closed while active. In-Reply-To: <1342208290.25.0.778184843655.issue15348@psf.upfronthosting.co.za> Message-ID: <1448040549.42.0.575974651246.issue15348@psf.upfronthosting.co.za> Terry J. Reedy added the comment: "not responsive to new commands" means that a statements can be typed but is ignored and no execution takes place. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 12:47:05 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Fri, 20 Nov 2015 17:47:05 +0000 Subject: [issue25625] "chdir" Contex manager for pathlib In-Reply-To: <1447527503.2.0.866276605324.issue25625@psf.upfronthosting.co.za> Message-ID: <20151120174702.GB22243@sg1> St?phane Wirtel added the comment: What's the relation with subprocess.Popen ? ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 13:06:38 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 20 Nov 2015 18:06:38 +0000 Subject: [issue25623] Keep the link to Python implementation of OrderedDict In-Reply-To: <1447488768.43.0.519685796607.issue25623@psf.upfronthosting.co.za> Message-ID: <1448042798.44.0.241470306375.issue25623@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> rejected stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 13:14:34 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 20 Nov 2015 18:14:34 +0000 Subject: [issue25625] "chdir" Contex manager for pathlib In-Reply-To: <1447523143.32.0.921942004004.issue25625@psf.upfronthosting.co.za> Message-ID: <1448043274.41.0.413694988101.issue25625@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I agree with desbma. ---------- nosy: +serhiy.storchaka resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 13:17:59 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 20 Nov 2015 18:17:59 +0000 Subject: [issue25625] "chdir" Contex manager for pathlib In-Reply-To: <1447523143.32.0.921942004004.issue25625@psf.upfronthosting.co.za> Message-ID: <1448043479.8.0.862248555676.issue25625@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > What's the relation with subprocess.Popen ? In the context of subprocesses there is better way to run a program in specified working directory that temporary change current working directory in parent process. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 13:18:01 2015 From: report at bugs.python.org (Sven Berkvens-Matthijsse) Date: Fri, 20 Nov 2015 18:18:01 +0000 Subject: [issue25678] int() from a buffer reads past the buffer boundaries In-Reply-To: <1448008840.02.0.961643049915.issue25678@psf.upfronthosting.co.za> Message-ID: <1448043481.88.0.551354504515.issue25678@psf.upfronthosting.co.za> Sven Berkvens-Matthijsse added the comment: Eryk, could the tests in the path file that you posted regarding int() and float() be incorrect in the sense that buffer(...)[a:b] returns a str() and not another buffer() (and will thus always be NUL terminated and not exhibit the problem, whether or not the C source have been patch)? I think the tests should be using buffer(..., a, b) instead. May I say that I am very, very impressed by the speed with which this has been picked up? Thank you all for your impressive work! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 13:19:25 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 20 Nov 2015 18:19:25 +0000 Subject: [issue25684] ttk.OptionMenu radiobuttons aren't unique between two instances of OptionMenu In-Reply-To: <1448040288.53.0.198369542776.issue25684@psf.upfronthosting.co.za> Message-ID: <1448043565.81.0.2093954682.issue25684@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka nosy: +serhiy.storchaka stage: -> needs patch versions: -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 13:26:46 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 20 Nov 2015 18:26:46 +0000 Subject: [issue25677] Syntax error caret confused by indentation In-Reply-To: <1447998656.06.0.471632717786.issue25677@psf.upfronthosting.co.za> Message-ID: <1448044006.05.0.43665169323.issue25677@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Would be nice to have a test. ---------- stage: patch review -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 13:28:00 2015 From: report at bugs.python.org (Sven Berkvens-Matthijsse) Date: Fri, 20 Nov 2015 18:28:00 +0000 Subject: [issue25678] int() from a buffer reads past the buffer boundaries In-Reply-To: <1448008840.02.0.961643049915.issue25678@psf.upfronthosting.co.za> Message-ID: <1448044080.54.0.1396304321.issue25678@psf.upfronthosting.co.za> Sven Berkvens-Matthijsse added the comment: (Please excuse my horrible spelling in my last message, I'm apparently more tired than I care to admit) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 13:38:46 2015 From: report at bugs.python.org (Eryk Sun) Date: Fri, 20 Nov 2015 18:38:46 +0000 Subject: [issue25678] int() from a buffer reads past the buffer boundaries In-Reply-To: <1448008840.02.0.961643049915.issue25678@psf.upfronthosting.co.za> Message-ID: <1448044726.96.0.434975399648.issue25678@psf.upfronthosting.co.za> Eryk Sun added the comment: > I think the tests should be using buffer(..., a, b) instead. Thanks, you're right. :) ---------- Added file: http://bugs.python.org/file41102/issue25678_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 13:49:06 2015 From: report at bugs.python.org (Nathan West) Date: Fri, 20 Nov 2015 18:49:06 +0000 Subject: [issue25671] Fix venv activate.fish to maintain $status In-Reply-To: <1447946690.19.0.336666934208.issue25671@psf.upfronthosting.co.za> Message-ID: <1448045346.61.0.872883952722.issue25671@psf.upfronthosting.co.za> Nathan West added the comment: Fixed an issue where fish_prompt was returning before calling _old_fish_prompt ---------- Added file: http://bugs.python.org/file41103/patch.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 14:06:50 2015 From: report at bugs.python.org (Marvin Greenberg) Date: Fri, 20 Nov 2015 19:06:50 +0000 Subject: [issue25685] Inefficiency with SocketHandler - may send log record message string twice in pickled data structure Message-ID: <1448046410.18.0.578360319482.issue25685@psf.upfronthosting.co.za> New submission from Marvin Greenberg: In logging.handlers.SocketHandler.makePickle code was added for issue 14436 that replaces the 'msg' in the log record dict with the formatted message. But if an earlier handler already formatted the message, it will have been added to the log record with key 'message'. In this case the identical message will be sent across the wire twice in the pickled data. The patch simply deletes the 'message' entry from the dict. More involved changes (like reusing record.message instead of calling getMessage) probably not useful. ---------- components: Library (Lib) files: handlers.py.patch keywords: patch messages: 255011 nosy: Marvin Greenberg priority: normal severity: normal status: open title: Inefficiency with SocketHandler - may send log record message string twice in pickled data structure type: resource usage versions: Python 3.5 Added file: http://bugs.python.org/file41104/handlers.py.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 14:14:22 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 20 Nov 2015 19:14:22 +0000 Subject: [issue25678] int() from a buffer reads past the buffer boundaries In-Reply-To: <1448008840.02.0.961643049915.issue25678@psf.upfronthosting.co.za> Message-ID: <1448046862.6.0.0744646710724.issue25678@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 14:32:53 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Fri, 20 Nov 2015 19:32:53 +0000 Subject: [issue25625] "chdir" Contex manager for pathlib In-Reply-To: <1448043479.8.0.862248555676.issue25625@psf.upfronthosting.co.za> Message-ID: <20151120193250.GA5453@sg1> St?phane Wirtel added the comment: > In the context of subprocesses there is better way to run a program in specified working directory that temporary change current working directory in parent process. Ok, haven't read the last line of the description. thanks for the clarification. -- St?phane Wirtel - http://wirtel.be - @matrixise ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 14:38:36 2015 From: report at bugs.python.org (SilentGhost) Date: Fri, 20 Nov 2015 19:38:36 +0000 Subject: [issue25685] Inefficiency with SocketHandler - may send log record message string twice in pickled data structure In-Reply-To: <1448046410.18.0.578360319482.issue25685@psf.upfronthosting.co.za> Message-ID: <1448048316.43.0.500720765587.issue25685@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- nosy: +vinay.sajip stage: -> patch review versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 14:56:36 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 20 Nov 2015 19:56:36 +0000 Subject: [issue25637] Move non-collections-related ABCs out of collections.abc In-Reply-To: <1447701682.74.0.653642972551.issue25637@psf.upfronthosting.co.za> Message-ID: <1448049396.92.0.346121317197.issue25637@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I would not like to have, say, 20 namespaces, some with just one ABD, such as functools.abc.Callable. I might have preferred abc.collections to collections.abc, etc. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 14:56:50 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 20 Nov 2015 19:56:50 +0000 Subject: [issue24802] int and float constructing from non NUL-terminated buffer In-Reply-To: <1438830920.07.0.863152787453.issue24802@psf.upfronthosting.co.za> Message-ID: <20151120195646.63492.9255@psf.io> Roundup Robot added the comment: New changeset 3ef7d1af5195 by Serhiy Storchaka in branch '2.7': Issue #25678: Copy buffer objects to null-terminated strings. https://hg.python.org/cpython/rev/3ef7d1af5195 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 14:56:50 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 20 Nov 2015 19:56:50 +0000 Subject: [issue25678] int() from a buffer reads past the buffer boundaries In-Reply-To: <1448008840.02.0.961643049915.issue25678@psf.upfronthosting.co.za> Message-ID: <20151120195646.63492.36888@psf.io> Roundup Robot added the comment: New changeset 3ef7d1af5195 by Serhiy Storchaka in branch '2.7': Issue #25678: Copy buffer objects to null-terminated strings. https://hg.python.org/cpython/rev/3ef7d1af5195 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 14:58:57 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 20 Nov 2015 19:58:57 +0000 Subject: [issue25678] int() from a buffer reads past the buffer boundaries In-Reply-To: <1448008840.02.0.961643049915.issue25678@psf.upfronthosting.co.za> Message-ID: <1448049537.47.0.112989686605.issue25678@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Committed after fixing some details. Thank you Eryk Sun. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 15:01:09 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 20 Nov 2015 20:01:09 +0000 Subject: [issue25644] Unable to open IDLE on Windows 10 with Python 2.7.10 In-Reply-To: <1447732580.69.0.0826869384289.issue25644@psf.upfronthosting.co.za> Message-ID: <1448049669.08.0.950996361695.issue25644@psf.upfronthosting.co.za> Terry J. Reedy added the comment: By 'active Python distribution', do you mean 'ActiveState Python distribution'? If so, you should talk with ActiveState. The 2.7.10 64 bit PSF installer works fine on my machine. Was Win 7, now Win 10. In any case, try "python -m idlelib" at a command line and see what error message you get. ---------- components: +Installation, Windows nosy: +paul.moore, steve.dower, terry.reedy, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 15:02:48 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 20 Nov 2015 20:02:48 +0000 Subject: [issue25644] Unable to open IDLE on Windows 10 with Python 2.7.10 In-Reply-To: <1447732580.69.0.0826869384289.issue25644@psf.upfronthosting.co.za> Message-ID: <1448049768.95.0.36772854918.issue25644@psf.upfronthosting.co.za> Terry J. Reedy added the comment: 'Crash' means getting a Windows 'Application stopped running' box as opposed to Python merely stopping with no error message when started from an icon. ---------- type: crash -> behavior versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 15:20:39 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Fri, 20 Nov 2015 20:20:39 +0000 Subject: [issue25671] Fix venv activate.fish to maintain $status In-Reply-To: <1447946690.19.0.336666934208.issue25671@psf.upfronthosting.co.za> Message-ID: <20151120202037.GB8862@sg1> St?phane Wirtel added the comment: I am a user of fish. The use case is just execute python -mvenv demo source demo/bin/activate.fish check the status and deactivate the virtualenv ? do you confirm ? Thank you ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 16:19:57 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 20 Nov 2015 21:19:57 +0000 Subject: [issue25594] enum instance attribute access possible In-Reply-To: <1447144067.5.0.526378354242.issue25594@psf.upfronthosting.co.za> Message-ID: <20151120211954.21873.31939@psf.io> Roundup Robot added the comment: New changeset 276cf69b911e by Ethan Furman in branch '3.5': Close issue25594: advise against accessing Enum members from other members https://hg.python.org/cpython/rev/276cf69b911e ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 16:34:36 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 20 Nov 2015 21:34:36 +0000 Subject: [issue25638] Verify the etree_parse and etree_iterparse benchmarks are working appropriately In-Reply-To: <1447702883.28.0.950037808414.issue25638@psf.upfronthosting.co.za> Message-ID: <1448055276.87.0.131425163444.issue25638@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Sorry Brett. How tests were ran? There are two implementations of ElementTree, accelerated and non-accelerated. xml.etree.ElementTree by default is accelerated in Python 3, but non-accelerated in Python 2. $ python2.7 bm_elementtree.py -n 7 --take_geo_mean 0.463665158795 $ python2.7 bm_elementtree.py -n 7 --take_geo_mean --etree-module=xml.etree.ElementTree 5.46309932568 $ python3.4 bm_elementtree.py -n 7 --take_geo_mean --etree-module=xml.etree.ElementTree 0.813397633467649 $ python3.4 bm_elementtree.py -n 7 --take_geo_mean --etree-module=xml.etree.ElementTree --no-accelerator 5.31174765817514 If run the test with the same options --etree-module=xml.etree.ElementTree, it will use accelerated implementation in Python 3 and non-accelerated in Python 2. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 16:35:44 2015 From: report at bugs.python.org (Ethan Furman) Date: Fri, 20 Nov 2015 21:35:44 +0000 Subject: [issue25594] enum instance attribute access possible In-Reply-To: <1447144067.5.0.526378354242.issue25594@psf.upfronthosting.co.za> Message-ID: <1448055344.66.0.823945968895.issue25594@psf.upfronthosting.co.za> Ethan Furman added the comment: Other changeset f4b495ceab17 in default branch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 17:13:35 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 20 Nov 2015 22:13:35 +0000 Subject: [issue25686] Don't use distutils in test_shutil Message-ID: <1448057615.39.0.634950011826.issue25686@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: The distutils package is used in test_shutil to search and run external archivers. But using distutils can have side effects (see issue25607). Proposed patch replaces distutils with standard functions for searching executables and running command, shutil.which() and subprocess.check_call(). ---------- components: Tests files: test_shutil_no_distutils.patch keywords: patch messages: 255023 nosy: eric.araujo, serhiy.storchaka, tarek priority: normal severity: normal stage: patch review status: open title: Don't use distutils in test_shutil type: enhancement versions: Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file41105/test_shutil_no_distutils.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 17:18:20 2015 From: report at bugs.python.org (Brett Cannon) Date: Fri, 20 Nov 2015 22:18:20 +0000 Subject: [issue25638] Verify the etree_parse and etree_iterparse benchmarks are working appropriately In-Reply-To: <1447702883.28.0.950037808414.issue25638@psf.upfronthosting.co.za> Message-ID: <1448057900.33.0.493740383425.issue25638@psf.upfronthosting.co.za> Brett Cannon added the comment: The commands I used are in the notebook for each implementation and you can get the same result with `python3 perf.py -b etree python2 python3`. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 17:19:32 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Fri, 20 Nov 2015 22:19:32 +0000 Subject: [issue25686] Don't use distutils in test_shutil In-Reply-To: <1448057615.39.0.634950011826.issue25686@psf.upfronthosting.co.za> Message-ID: <20151120221929.GA8855@sg1> St?phane Wirtel added the comment: Works fine on my laptop with 3.6. and the code is right ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 17:43:21 2015 From: report at bugs.python.org (Davin Potts) Date: Fri, 20 Nov 2015 22:43:21 +0000 Subject: [issue21162] code in multiprocessing.pool freeze if inside some code from scikit-learn (and probably liblinear) executed on ubuntu 12.04 64 Bit In-Reply-To: <1396716060.12.0.828109902525.issue21162@psf.upfronthosting.co.za> Message-ID: <1448059401.08.0.230034213424.issue21162@psf.upfronthosting.co.za> Davin Potts added the comment: I'm going ahead with closing this issue as it originates outside of multiprocessing and Python itself as well as being highly dependent upon specific combinations of build options and versions of 3rd party libraries (such as ATLAS). ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 17:44:24 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 20 Nov 2015 22:44:24 +0000 Subject: [issue25638] Verify the etree_parse and etree_iterparse benchmarks are working appropriately In-Reply-To: <1447702883.28.0.950037808414.issue25638@psf.upfronthosting.co.za> Message-ID: <1448059464.71.0.679803611322.issue25638@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The slowing down Python 3 can be related to adding XMLPullParser (issue17741). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 18:27:24 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 20 Nov 2015 23:27:24 +0000 Subject: [issue25660] tabs don't work correctly in python repl In-Reply-To: <1447876730.91.0.918964104484.issue25660@psf.upfronthosting.co.za> Message-ID: <1448062044.06.0.210489018723.issue25660@psf.upfronthosting.co.za> Martin Panter added the comment: Sorry to throw a potential spanner in the works, but I think this introduces a dependence on the readline module. Consider what happens when the Completer class is used but Readline is not, or even if the ?readline? could not be imported (see bottom of rlcompleter.py). Maybe there is a way around this, but it might involve more complicated code. ---------- priority: release blocker -> high stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 18:27:50 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 20 Nov 2015 23:27:50 +0000 Subject: [issue25660] tabs don't work correctly in python repl In-Reply-To: <1447876730.91.0.918964104484.issue25660@psf.upfronthosting.co.za> Message-ID: <1448062070.36.0.158874707538.issue25660@psf.upfronthosting.co.za> Martin Panter added the comment: Didn?t mean to adjust priority ---------- priority: high -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 18:39:41 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 20 Nov 2015 23:39:41 +0000 Subject: [issue25660] tabs don't work correctly in python repl In-Reply-To: <1447876730.91.0.918964104484.issue25660@psf.upfronthosting.co.za> Message-ID: <1448062781.6.0.118060561706.issue25660@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Sorry to throw a potential spanner in the works, but I think this introduces a dependence on the readline module. Consider what happens when the Completer class is used but Readline is not, or even if the ?readline? could not be imported (see bottom of rlcompleter.py). Hm... This module provides a "Completer" class **specifically** for readline, as its documentation (and name!) indicates. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 19:06:51 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Sat, 21 Nov 2015 00:06:51 +0000 Subject: [issue25485] Add a context manager to telnetlib.Telnet In-Reply-To: <1445883619.21.0.032521861016.issue25485@psf.upfronthosting.co.za> Message-ID: <1448064411.17.0.122977525588.issue25485@psf.upfronthosting.co.za> St?phane Wirtel added the comment: Need review for this new patch. * Add test * Improve the documentation * Update the Misc/NEWS ---------- Added file: http://bugs.python.org/file41106/issue25485-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 19:37:36 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 21 Nov 2015 00:37:36 +0000 Subject: [issue25626] Gzip fails for file over 2**32 bytes In-Reply-To: <1447530501.75.0.968129152166.issue25626@psf.upfronthosting.co.za> Message-ID: <1448066256.93.0.388090193616.issue25626@psf.upfronthosting.co.za> Martin Panter added the comment: New patch addressing comments. I used the undocumented API _PyLong_FromNbInt() to call __int__() rather than __index__(). ---------- Added file: http://bugs.python.org/file41107/zlib-Py_ssize_t.2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 19:37:42 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 21 Nov 2015 00:37:42 +0000 Subject: [issue24455] IDLE debugger causes crash if not quitted properly before next run In-Reply-To: <1434383850.99.0.136251358232.issue24455@psf.upfronthosting.co.za> Message-ID: <20151121003734.20270.51651@psf.io> Roundup Robot added the comment: New changeset f51467273d3b by Terry Jan Reedy in branch '2.7': Issue #24455: Prevent IDLE from hanging when a) closing the shell while the https://hg.python.org/cpython/rev/f51467273d3b New changeset 1ddd77a5e8c8 by Terry Jan Reedy in branch '3.4': Issue #24455: Prevent IDLE from hanging when a) closing the shell while the https://hg.python.org/cpython/rev/1ddd77a5e8c8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 20:24:34 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 21 Nov 2015 01:24:34 +0000 Subject: [issue15347] IDLE - does not close if the debugger was active In-Reply-To: <1342207963.58.0.539607447258.issue15347@psf.upfronthosting.co.za> Message-ID: <1448069074.68.0.919464270433.issue15347@psf.upfronthosting.co.za> Terry J. Reedy added the comment: See #15348 for result of fix-mainloop2.patch on Windows. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 20:38:28 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 21 Nov 2015 01:38:28 +0000 Subject: [issue15348] IDLE - shell becomes unresponsive if debugger windows is closed while active. In-Reply-To: <1342208290.25.0.778184843655.issue15348@psf.upfronthosting.co.za> Message-ID: <1448069908.71.0.055565359155.issue15348@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The patch for #24455 replaced root.mainloop,.quit with tcl vwait, set as the suspend/resume mechanism for Debugger.interation. After this, closing the shell as described in #15347, or the debugger with [x] as described here, on my Windows 10 machine, resulted in File "F:\Python\dev\34\lib\idlelib\Debugger.py", line 20, in user_line self.gui.interaction(message, frame) _tkinter.TclError: invalid command name ".86740760.86830984.86827736" instead of a hang. This is an improvement as the Exception can be caught and ignored. People testing of other systems did not report this. With TclError caught, closing the debugger with [x] then produced File "F:\Python\dev\34\lib\idlelib\Debugger.py", line 21, in user_line self.gui.interaction(message, frame) RuntimeError: Unknown object id: 'gui_adapter' I applied the patch with Runtime also caught and ignored. The exceptions did not occur when [Quit] was pressed first. So I think [x] should do whatever Quit does before closing. ---------- assignee: roger.serwy -> terry.reedy stage: patch review -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 20:38:42 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 21 Nov 2015 01:38:42 +0000 Subject: [issue24455] IDLE debugger causes crash if not quitted properly before next run In-Reply-To: <1434383850.99.0.136251358232.issue24455@psf.upfronthosting.co.za> Message-ID: <1448069922.5.0.493290195527.issue24455@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Patch does two things. On startup, check if debugger is already active and if it is, send 'finish' signal to existing interaction and try again after .1 second. This is the part aimed at the particular problem of this issue. During active running, use the tcl vwait mechanism https://www.tcl.tk/man/tcl/TclCmd/vwait.htm intended for suspending and resuming a function without blocking the event loop. Using root.mainloop and root.quit for this purpose was a hack that sort of worked but created the shutdown problems in #15347 and #15348. To further explain the suspend/resume ping-ponging of control: IDLE's bebugger is based on the bdb.Bdb debug engine. User interaction is added by overriding Bdb.user_xyz methods. The overrides tell Bdb what to do after they return by calling Bdb.set_uvw methods. idlelib.Debugger.Idb defines .user_line and .user_exception, which are called when the debugger stops on a line or with an exception. Both end by calling Debugger.Debugger.interaction. This method updates the gui and activates the buttons. It must then pause (now with vwait waitvar) and allow button presses (and other IDLE gui events) to be handled *without* returning. (The stdlib pdb can instead just call "cmd = input('pdb>')" and block waiting for user input.) When a debugger button is pressed, a Bdb.set_uvw method is called and waitvar is set. Then .interaction resumes, disables the buttons, and returns so Bdb can do the action requested. Thanks Mark for working this out and finding the proper pause/resume method. On my Windows 10 machine, at least, the patch did not completely solve the hang-on-close issues. One or two exceptions are raised instead of hanging. This is improvement. Details are on #15348. Pending a better solution, I added try-except around the gui.interaction call to ignore the exception. After numerous tests (at least 10) where I started and either stopped the debugger or restarted from the editor, I encountered a hang. But this was not something I could reproduce, and Restart Shell worked, whereas it had not previously. ---------- assignee: -> terry.reedy resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 20:46:30 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 21 Nov 2015 01:46:30 +0000 Subject: [issue15347] IDLE - does not close if the debugger was active In-Reply-To: <1342207963.58.0.539607447258.issue15347@psf.upfronthosting.co.za> Message-ID: <1448070390.26.0.461327753515.issue15347@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Git patch does not apply because header does not have full paths. diff --git a/Debugger.py b/Debugger.py index e2014d1..9efe6fa 100644 --- a/Debugger.py +++ b/Debugger.py versus diff -r ed694938c61a Lib/idlelib/Debugger.py --- a/Lib/idlelib/Debugger.py Tue Sep 22 13:08:42 2015 +0300 +++ b/Lib/idlelib/Debugger.py Tue Sep 22 20:36:09 2015 -0700 This is also why no *review* link after the *edit* link on right. I will go ahead and manually edit the file. ---------- assignee: -> terry.reedy stage: -> commit review versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 22:13:04 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 21 Nov 2015 03:13:04 +0000 Subject: [issue25194] Opt-in motivations & affiliations page for core contributors In-Reply-To: <1442740668.12.0.539568285088.issue25194@psf.upfronthosting.co.za> Message-ID: <1448075584.98.0.181673623661.issue25194@psf.upfronthosting.co.za> Nick Coghlan added the comment: Offline feedback from GvR: * the currently accepted term for folks with commit access is "core developer", and this page isn't the place to attempt to change that, so I've switched to that conventional terminology throughout the page * the scope limitation to core developers now appears in the section heading in addition to the preamble text I agree there are legitimate concerns with "commits for the sake of commits" as a metric, but it's just one link used to contrast what a page like this can provide with what automated VCS analysis can do, and reviewing and incorporating other people's patches at a general bug fixing level is actually the area where we most struggle at the moment, especially for orphan modules. I'm going to post this updated version, and then try to encourage more folks to start filling in entries now that there's a better explanation of the page's purpose. ---------- Added file: http://bugs.python.org/file41108/core-developer-motivations.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 22:28:44 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 21 Nov 2015 03:28:44 +0000 Subject: [issue25612] nested try..excepts don't work correctly for generators In-Reply-To: <1447361959.0.0.839122121456.issue25612@psf.upfronthosting.co.za> Message-ID: <1448076524.42.0.313871175967.issue25612@psf.upfronthosting.co.za> Nick Coghlan added the comment: Interrogating the thread state like that makes me wonder how this patch behaves in the following scenario: class MainError(Exception): pass class SubError(Exception): pass def yield_coro(): yield coro = yield_coro() coro.send(None) try: raise MainError except MainError: try: coro.throw(SubError) except SubError: pass raise Also potentially worth exploring is this proposed architectural change from Mark Shannon to move all exception related state out of frame objects: http://bugs.python.org/issue13897 While we couldn't do the latter in a maintenance release, I'd be interested to know what effect it has on this edge case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 00:03:37 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 21 Nov 2015 05:03:37 +0000 Subject: [issue15348] IDLE - shell becomes unresponsive if debugger windows is closed while active. In-Reply-To: <1342208290.25.0.778184843655.issue15348@psf.upfronthosting.co.za> Message-ID: <1448082217.08.0.181296710827.issue15348@psf.upfronthosting.co.za> Terry J. Reedy added the comment: (I was wrong about seeing the exception when closing the shell.) A major difference between [Quit] and [x] is that [Quit] stops the running program whereas [x] closes the visible gui but leaves the program to run through to the end, as though the [go] button were pressed. I added 'as e' and 'print(e)' to the try except and there are multiple RuntimeErrors, 1 per line traced by [step], including IDLE code for input() and print() calls, with [x], but none with [quit] first. The TclError only occurs in 3.4.3, not in 2.7.10. The string 'gui_adapter' comes from RemoteDebugger.py, line 28. gui_adap_oid = "gui_adapter" It represents the debugger window in the idle process. My interpretation of the traceback is that when self.gui.interaction(message, frame) is executed in the user process, the interaction call actually calls debugger.interaction in the idle process via RemoteDebugger.GUIProxy.interaction. The latter does not appear in the traceback because IDLE rpc calls are deleted from tracebacks before they are printed. Replacing self.abort_loop with self.quit (which calls abort_loop) eliminates the Runtime exceptions, as the backend debugger in the user process is stopped before the idle process frontend gui disappears. However, self.idb.set_quit (within self.quit) raises AttributeError: 'Idb' object has no attribute 'botframe' if one attempts to immediately close the debugger window (with menu or button) before it is activated. It is then left as a zombie window. The exception is in the Tkinter callback, so it is printed to console rather than the IDLE shell, and included RemoteDebugger and rpc calls, but not the line in Bdb.set_quit(self), self.stopframe = self.botframe that actually raised the exception. So the call must either be conditioned or the exception caught. I decided to go with latter now. ---------- versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 00:06:00 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 21 Nov 2015 05:06:00 +0000 Subject: [issue15348] IDLE - shell becomes unresponsive if debugger windows is closed while active. In-Reply-To: <1342208290.25.0.778184843655.issue15348@psf.upfronthosting.co.za> Message-ID: <20151121050556.3532.673@psf.io> Roundup Robot added the comment: New changeset 427ad0ede016 by Terry Jan Reedy in branch '2.7': Issue 15348: Stop debugger engine (normally in user process) https://hg.python.org/cpython/rev/427ad0ede016 New changeset 4eae64a9cd26 by Terry Jan Reedy in branch '3.4': Issue 15348: Stop debugger engine (normally in user process) https://hg.python.org/cpython/rev/4eae64a9cd26 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 00:26:07 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 21 Nov 2015 05:26:07 +0000 Subject: [issue15348] IDLE - shell becomes unresponsive if debugger windows is closed while active. In-Reply-To: <1342208290.25.0.778184843655.issue15348@psf.upfronthosting.co.za> Message-ID: <1448083567.55.0.279523345502.issue15348@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I don't like the idea of [x] flashing quit instead of closing. This patch, on top of the one for #24455, may not be perfect, but the two are definite improvements. Unless I see something critically bad first, I want them in the upcoming releases. Mark claims that his second patch for #15347 improves behavior for no subprocess. But that was without this patch. There is one situation not mentioned that I know is still glitchy. Debug a program with input(prompt). Run up to and including that line. While the program is waiting for input, close with [x]. The shell prints '[DEBUG OFF]' after the prompt and '>>> ' on the next line. But that is a fake prompt in that a statement entered will not be executed, but will be seen as the response to the pending input(). While there is a pending input (or any other blocked statement), the [Quit] button is disabled. The close method should detect this 'program executing' condition and ask whether to kill it, just as if one tries to close IDLE under the same condition. I am leaving this open, at least for now, at least for this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 00:41:43 2015 From: report at bugs.python.org (Takayuki SHIMIZUKAWA) Date: Sat, 21 Nov 2015 05:41:43 +0000 Subject: [issue8304] time.strftime() and Unicode characters on Windows In-Reply-To: <1270307324.04.0.0348018847246.issue8304@psf.upfronthosting.co.za> Message-ID: <1448084503.39.0.50675761853.issue8304@psf.upfronthosting.co.za> Takayuki SHIMIZUKAWA added the comment: I've implemented a workaround for Sphinx: >>> time.strftime(u'%Y ?'.encode('unicode-escape').decode(), *args).encode().decode('unicode-escape') 2015 ? https://github.com/sphinx-doc/sphinx/blob/8ae43b9fd/sphinx/util/osutil.py#L175 ---------- nosy: +shimizukawa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 02:00:18 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 21 Nov 2015 07:00:18 +0000 Subject: [issue25626] Gzip fails for file over 2**32 bytes In-Reply-To: <1447530501.75.0.968129152166.issue25626@psf.upfronthosting.co.za> Message-ID: <1448089218.08.0.164459192956.issue25626@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Martin, the patch LGTM. The difference between __int__() and __index__() is that float has the former, but not the latter. For better compatibility we have to use __int__() in maintained releases. But obviously __index__() is more appropriate semantically. float buffer length doesn't make sense. We have to change __int__ to __index__ in future releases. But this is separate issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 02:00:59 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 21 Nov 2015 07:00:59 +0000 Subject: [issue25626] Gzip fails for file over 2**32 bytes In-Reply-To: <1447530501.75.0.968129152166.issue25626@psf.upfronthosting.co.za> Message-ID: <1448089259.15.0.788288650746.issue25626@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> martin.panter stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 02:54:27 2015 From: report at bugs.python.org (Benno Leslie) Date: Sat, 21 Nov 2015 07:54:27 +0000 Subject: [issue25687] Error during test case and tearDown Message-ID: <1448092467.41.0.746674123801.issue25687@psf.upfronthosting.co.za> New submission from Benno Leslie: I'm not sure if this should be considered a bug, but the behaviour is surprising and not clearly documented. I a have a very simple test that has an error during both the test case, and during tearDown. """ import unittest class Test(unittest.TestCase): def test_a(self): asdf def tearDown(self): asdf if __name__ == '__main__': unittest.main() """ When this occurs it is surprising (to me) that the output is: """ Ran 1 test in 0.000s FAILED (errors=2) """ In particular, the fact that has more errors than there are tests that have been run. Obviously in this very simple example it is clear what has happened, however in a test suite that has hundreds of test cases it is somewhat frustrating to have the number of failing test cases over-reported. (And of course in the real-world test suite that led to this the tearDown doesn't fail on every single test case like in this simplified example). Although there are definitely two errors occurring in my example, in all other cases, only the first error would be reported. e.g.: an error in setUp wouldn't run the test case, and only the first (potential) error in the testcase itself would occur. I think that either: 1/ The documentation of the tearDown method should clearly indicate that an error in tearDown would cause multiple errors to be reported for the single testCase, or. 2/ Change the implementation so that if there is an exception during tearDown, and there was already an error in the test case only the first error is reported. 2 is probably a non-starter given backwards compatibility concerns (even assuming anyone else thinks this is the best behaviour in this corner case). I'd be happy to try and draft something for #1 if that is the best action. ---------- components: Library (Lib) messages: 255045 nosy: bennoleslie priority: normal severity: normal status: open title: Error during test case and tearDown type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 03:17:59 2015 From: report at bugs.python.org (Davis Herring) Date: Sat, 21 Nov 2015 08:17:59 +0000 Subject: [issue1062277] Pickle breakage with reduction of recursive structures Message-ID: <1448093879.59.0.541695863577.issue1062277@psf.upfronthosting.co.za> Davis Herring added the comment: Re msg110868: it's impossible to resolve a __reduce__ loop that involves only immutable intermediate objects (including none at all): class Direct: def __reduce__(self): return id,(self,) # obviously impossible class Indirect: # Can't create either the new object or the tuple first! def __reduce__(self): return id,((self,),) With pre-existing mutable objects, the same trick as for tuples certainly could be applied: class Mutable: def __init__(self): self.bracketed=[self] # Create list, REDUCE, then populate list def __reduce__(self): return id,(self.bracketed,) The way an analog to the tuple implementation would deal with this would be something like id # the dummy "constructor" in this example [] # empty list, memoized immediately as, say, #5 id # try again to store the Mutable @5 # fetch from memo T1 # make singleton tuple R # reduce (have now succeeded in "making" the Mutable as, say, #20) APP # to the list T1 # finish the first __reduce__ attempt POP # abandon it, since the object has been created POP # abandon the "id" as well @20 # fetch the previous answer If the list were created directly in __reduce__, you'd still recurse infinitely trying to create each new list object. On the other hand, even complicated cases like this should work: class Switch: def __reduce__(self): return id,(self.lst,) a=Switch(); b=Switch() a.list=[b,a]; b.list=[a,b] where the pickling of, say, a would look something like id [] # -> #17 id # trying b now [] # -> #42 id # trying a again @17 T1 R # a done (#88) APP id # trying b again @42 T1 R # b done (#101) APP # b's list now populated POP POP # b abandoned @101 # b fetched APP # finally building a's list @88 # a is long done APP # a's list now populated POP POP # a abandoned @88 # final value: a Perhaps a technique for distinguishing these cases is to look for new objects having been created since the last time we visited an object. If there are none, we're in the immutable case and we lose. If there are yet more created between the second and third visits, on the other hand, we're generating more objects from __reduce__ every time and should again abort. ---------- nosy: +herring _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 03:59:10 2015 From: report at bugs.python.org (Rohit Mediratta) Date: Sat, 21 Nov 2015 08:59:10 +0000 Subject: [issue25528] Attempt to further increase test coverage of calendar module In-Reply-To: <1446371863.84.0.773420016182.issue25528@psf.upfronthosting.co.za> Message-ID: <1448096350.86.0.0118178731004.issue25528@psf.upfronthosting.co.za> Rohit Mediratta added the comment: Thanks for the comments. I did indeed have the patch reversed. I've resolved it here. Martin: I had the locale=None case in the patch. ---------- Added file: http://bugs.python.org/file41109/mywork_update.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 05:59:44 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 21 Nov 2015 10:59:44 +0000 Subject: [issue25626] Gzip fails for file over 2**32 bytes In-Reply-To: <1447530501.75.0.968129152166.issue25626@psf.upfronthosting.co.za> Message-ID: <20151121105941.22175.38757@psf.io> Roundup Robot added the comment: New changeset 80f6f77a7cc3 by Martin Panter in branch '3.5': Issue #25626: Change zlib to accept Py_ssize_t and cap to UINT_MAX https://hg.python.org/cpython/rev/80f6f77a7cc3 New changeset afa1b6cd77a5 by Martin Panter in branch 'default': Issue #25626: Merge zlib fix from 3.5 https://hg.python.org/cpython/rev/afa1b6cd77a5 New changeset 5117f0b3be09 by Martin Panter in branch 'default': Issue #25626: Add news to 3.6 section https://hg.python.org/cpython/rev/5117f0b3be09 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 06:03:41 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 21 Nov 2015 11:03:41 +0000 Subject: [issue25626] Gzip fails for file over 2**32 bytes In-Reply-To: <1447530501.75.0.968129152166.issue25626@psf.upfronthosting.co.za> Message-ID: <1448103821.75.0.373311754342.issue25626@psf.upfronthosting.co.za> Martin Panter added the comment: Thank you Serhiy for you help, and Ben for reporting this. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 06:06:46 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 21 Nov 2015 11:06:46 +0000 Subject: [issue25638] Verify the etree_parse and etree_iterparse benchmarks are working appropriately In-Reply-To: <1447702883.28.0.950037808414.issue25638@psf.upfronthosting.co.za> Message-ID: <1448104006.46.0.769271286814.issue25638@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Proposed patch optimizes iterparse(). Now it is only 33% slower than in 2.7 (was 2.6 times slower). ---------- components: +Extension Modules, Library (Lib), XML keywords: +patch nosy: +eli.bendersky, scoder stage: -> patch review type: -> performance versions: +Python 3.6 Added file: http://bugs.python.org/file41110/etree_iterparse.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 06:11:33 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 21 Nov 2015 11:11:33 +0000 Subject: [issue25688] File leak in ElementTree.iterparse() Message-ID: <1448104293.18.0.824435970603.issue25688@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: ElementTree.iterparse() can leak internally open file in case of error. Proposed patch fixes the leak. ---------- components: Library (Lib) files: etree_iterparse_leak.patch keywords: patch messages: 255051 nosy: eli.bendersky, scoder, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: File leak in ElementTree.iterparse() type: resource usage versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file41111/etree_iterparse_leak.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 07:12:23 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 21 Nov 2015 12:12:23 +0000 Subject: [issue25686] Don't use distutils in test_shutil In-Reply-To: <1448057615.39.0.634950011826.issue25686@psf.upfronthosting.co.za> Message-ID: <20151121121219.127564.62103@psf.io> Roundup Robot added the comment: New changeset c50cbb5d5ece by Serhiy Storchaka in branch '3.4': Issue #25686: test_shutil no longer uses the distutils package for searching https://hg.python.org/cpython/rev/c50cbb5d5ece New changeset df11d58fce00 by Serhiy Storchaka in branch '3.5': Issue #25686: test_shutil no longer uses the distutils package for searching https://hg.python.org/cpython/rev/df11d58fce00 New changeset 3ccd9dfb8ab7 by Serhiy Storchaka in branch 'default': Issue #25686: test_shutil no longer uses the distutils package for searching https://hg.python.org/cpython/rev/3ccd9dfb8ab7 New changeset 81b4b130a891 by Serhiy Storchaka in branch '2.7': Issue #25686: test_shutil no longer uses the distutils package for running https://hg.python.org/cpython/rev/81b4b130a891 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 07:13:31 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 21 Nov 2015 12:13:31 +0000 Subject: [issue25686] Don't use distutils in test_shutil In-Reply-To: <1448057615.39.0.634950011826.issue25686@psf.upfronthosting.co.za> Message-ID: <1448108011.49.0.70913872623.issue25686@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you St?phane for your review. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 07:19:58 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 21 Nov 2015 12:19:58 +0000 Subject: [issue25624] shutil.make_archive makes invalid directory entries In-Reply-To: <1447493124.52.0.848319062026.issue25624@psf.upfronthosting.co.za> Message-ID: <1448108398.68.0.769220588485.issue25624@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could you add a test Dingyuan? You can take test_zipfile_vs_zip in test_shutil as an example. The patch changes both shutil and zipfile. Aren't only changes to zipfile needed? ---------- stage: needs patch -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 07:25:52 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Sat, 21 Nov 2015 12:25:52 +0000 Subject: [issue25686] Don't use distutils in test_shutil In-Reply-To: <1448108011.49.0.70913872623.issue25686@psf.upfronthosting.co.za> Message-ID: <20151121122550.GA2417@sg1> St?phane Wirtel added the comment: Welcome Serhiy, ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 07:35:52 2015 From: report at bugs.python.org (SilentGhost) Date: Sat, 21 Nov 2015 12:35:52 +0000 Subject: [issue25689] ftplib docs language fix Message-ID: <1448109352.75.0.661923441746.issue25689@psf.upfronthosting.co.za> New submission from SilentGhost: Just a minor fix, removing the following: "Here is a sample on how using it:" ---------- assignee: docs at python components: Documentation files: ftplib_docs.diff keywords: patch messages: 255056 nosy: SilentGhost, docs at python priority: normal severity: normal stage: patch review status: open title: ftplib docs language fix versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file41112/ftplib_docs.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 10:03:28 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 21 Nov 2015 15:03:28 +0000 Subject: [issue13275] Recommend xml.etree for XML processing In-Reply-To: <1319709959.84.0.984784684468.issue13275@psf.upfronthosting.co.za> Message-ID: <1448118208.56.0.770410093534.issue13275@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The wording in the tutorial was changed in issue23891. Now ElementTree is mentioned on first place. In the "Structured Markup Processing Tools" section ElementTree is listed before other XML processing modules. I think this issue can be closed now. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 10:09:26 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 21 Nov 2015 15:09:26 +0000 Subject: [issue10942] xml.etree.ElementTree.tostring returns type bytes, expected type str In-Reply-To: <1295395949.96.0.0409847573272.issue10942@psf.upfronthosting.co.za> Message-ID: <1448118566.01.0.0548842701118.issue10942@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: For now the documentation explains the resulting type of tostring(). https://docs.python.org/3/library/xml.etree.elementtree.html#xml.etree.ElementTree.tostring """ Generates a string representation of an XML element, including all subelements. element is an Element instance. encoding [1] is the output encoding (default is US-ASCII). Use encoding="unicode" to generate a Unicode string (otherwise, a bytestring is generated). method is either "xml", "html" or "text" (default is "xml"). """ Looks as this issue can be closed. ---------- nosy: +serhiy.storchaka status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 10:14:22 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 21 Nov 2015 15:14:22 +0000 Subject: [issue14988] _elementtree: Raise ImportError when importing of pyexpat fails In-Reply-To: <1338708115.99.0.275881966348.issue14988@psf.upfronthosting.co.za> Message-ID: <1448118862.95.0.48285314698.issue14988@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Can this issue be closed? ---------- nosy: +serhiy.storchaka status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 11:01:08 2015 From: report at bugs.python.org (Aleksey Kladov) Date: Sat, 21 Nov 2015 16:01:08 +0000 Subject: [issue25680] Selector.select() hangs when there is nothing to select In-Reply-To: <1448029102.96.0.470819036773.issue25680@psf.upfronthosting.co.za> Message-ID: <1448121668.99.0.342630988773.issue25680@psf.upfronthosting.co.za> Aleksey Kladov added the comment: >What's the point of your bug report? To show surprising platform-dependent API behavior. I don't know what is the correct behavior here, but it should be cross platform. Seems like the most sane option is to throw an exception. >Does your application really rely on the behaviour of the selector when no file descriptor is registered? It was developed on Mac and relied (quite probably incorrectly) on the empty list result. When I run it on linux, it unexpectedly hanged. So, I would like to either * observe an exception on all platforms * observe an empty list on all platforms * observe infinite blocking on all platforms I think this special case should also be mentioned in the docs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 11:23:05 2015 From: report at bugs.python.org (Niv Ben-David) Date: Sat, 21 Nov 2015 16:23:05 +0000 Subject: [issue25690] Replacement for unittest.mock.mock_open Message-ID: <1448122983.8.0.049241542179.issue25690@psf.upfronthosting.co.za> New submission from Niv Ben-David: The unittest.mock module defines a mock_open utility to mock the builtin open function. During a recent project I found I needed something more. Specifically, mocking different files at the same time, better mocking for operations (like seek, readlines, etc.) among others. The project can also be found on http://github.com/nivbend/mock-open Thanks ---------- components: Library (Lib) files: mock_open.patch keywords: patch messages: 255061 nosy: Niv Ben-David priority: normal severity: normal status: open title: Replacement for unittest.mock.mock_open type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file41113/mock_open.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 11:26:52 2015 From: report at bugs.python.org (SilentGhost) Date: Sat, 21 Nov 2015 16:26:52 +0000 Subject: [issue25690] Replacement for unittest.mock.mock_open In-Reply-To: <1448122983.8.0.049241542179.issue25690@psf.upfronthosting.co.za> Message-ID: <1448123212.47.0.474622190741.issue25690@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- components: +Tests nosy: +ezio.melotti, michael.foord, rbcollins stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 11:50:05 2015 From: report at bugs.python.org (Tomer) Date: Sat, 21 Nov 2015 16:50:05 +0000 Subject: [issue25656] multiprocessing.dummy: pool.map hangs on empty list In-Reply-To: <1447855498.22.0.263851728204.issue25656@psf.upfronthosting.co.za> Message-ID: <1448124605.47.0.0168967177552.issue25656@psf.upfronthosting.co.za> Tomer added the comment: Thanks for the reply, So first thing I found that I wasn?t working with python 2.7.10 ? I updated to 2.7.10 and it fixed the problem. If you are still curious about reproducing the behavior I?m working on windows 7 64 bit and as I said I worked with python 2.7, Thank you. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 11:52:15 2015 From: report at bugs.python.org (Emanuel Barry) Date: Sat, 21 Nov 2015 16:52:15 +0000 Subject: [issue25656] multiprocessing.dummy: pool.map hangs on empty list In-Reply-To: <1447855498.22.0.263851728204.issue25656@psf.upfronthosting.co.za> Message-ID: <1448124735.98.0.811459122394.issue25656@psf.upfronthosting.co.za> Changes by Emanuel Barry : ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 12:04:39 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 21 Nov 2015 17:04:39 +0000 Subject: [issue25691] Crash on deleting Element attribute Message-ID: <1448125479.67.0.778631980782.issue25691@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: >>> import xml.etree.ElementTree as ET >>> e = ET.Element('tag') >>> del e.tag Segmentation fault (core dumped) Proposed patch fixes the crash. ---------- components: Extension Modules files: etree_del_attributes.patch keywords: patch messages: 255063 nosy: eli.bendersky, scoder, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Crash on deleting Element attribute type: crash versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file41114/etree_del_attributes.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 12:12:46 2015 From: report at bugs.python.org (Nan Wu) Date: Sat, 21 Nov 2015 17:12:46 +0000 Subject: [issue25651] Confusing output for TestCase.subTest(0) In-Reply-To: <1447814053.14.0.516761369725.issue25651@psf.upfronthosting.co.za> Message-ID: <1448125966.65.0.341016651258.issue25651@psf.upfronthosting.co.za> Nan Wu added the comment: Made it check against None explicitly. My concern is if [] is passed in, if will show [[]]. But this case should be rare. ---------- keywords: +patch nosy: +Nan Wu Added file: http://bugs.python.org/file41115/subtest_msg_check_against_None.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 12:28:02 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 21 Nov 2015 17:28:02 +0000 Subject: [issue20612] cElementTree has problems with StringIO object containing unicode content In-Reply-To: <1392236199.28.0.287931665829.issue20612@psf.upfronthosting.co.za> Message-ID: <1448126882.69.0.630097732363.issue20612@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: For now cElementTree parser just stops parsing when has read something that is not exactly of type str. Eli, Stefan, it is not hard to make cElementTree supporting Unicode streams, only few lines of code. But is it worth to do this on this stage? Or we have just close this issue as "won't fix"? ---------- nosy: +eli.bendersky, scoder _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 12:40:58 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 21 Nov 2015 17:40:58 +0000 Subject: [issue19687] Fixes for elementtree integer overflow In-Reply-To: <1385078611.06.0.503563950207.issue19687@psf.upfronthosting.co.za> Message-ID: <1448127658.22.0.274572105473.issue19687@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 13:39:25 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 21 Nov 2015 18:39:25 +0000 Subject: [issue25488] IDLE: Remove '' and idlelib from sys.path when added In-Reply-To: <1445937913.03.0.194834202195.issue25488@psf.upfronthosting.co.za> Message-ID: <1448131165.32.0.494784434089.issue25488@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- title: IDLE: Remove idlelib from sys.path when added -> IDLE: Remove '' and idlelib from sys.path when added _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 14:54:36 2015 From: report at bugs.python.org (Eugene Toder) Date: Sat, 21 Nov 2015 19:54:36 +0000 Subject: [issue1062277] Pickle breakage with reduction of recursive structures Message-ID: <1448135676.31.0.838787306435.issue1062277@psf.upfronthosting.co.za> Eugene Toder added the comment: Davis, the possible cases (i.e. recursion via appropriate mutable objects) are already supported, and the impossible cases are, well, impossible. The only open issue is whether to implement better error handling for infinite recursion problems, instead of relying on built-in maximum recursion depth. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 14:54:56 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 21 Nov 2015 19:54:56 +0000 Subject: [issue25264] test_marshal always crashs on "AMD64 Windows10 2.7" buildbot In-Reply-To: <1443513708.82.0.964856310612.issue25264@psf.upfronthosting.co.za> Message-ID: <1448135696.02.0.427744324594.issue25264@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka priority: normal -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 15:03:28 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 21 Nov 2015 20:03:28 +0000 Subject: [issue25264] test_marshal always crashs on "AMD64 Windows10 2.7" buildbot In-Reply-To: <1443513708.82.0.964856310612.issue25264@psf.upfronthosting.co.za> Message-ID: <1448136208.12.0.144653185811.issue25264@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could anybody please run the test on Windows at found at least what test method is crashed? A stacktrace could help a lot too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 15:19:31 2015 From: report at bugs.python.org (Gordon C) Date: Sat, 21 Nov 2015 20:19:31 +0000 Subject: [issue9941] Unify trace and profile interfaces In-Reply-To: <1285347468.19.0.483467963743.issue9941@psf.upfronthosting.co.za> Message-ID: <1448137171.0.0.0851757021667.issue9941@psf.upfronthosting.co.za> Gordon C added the comment: I know this is an old bug (my first-time contribution), but I checked and it still applies in current versions. As suggested by @belopolsky, I added runcall to Trace and made runfunc an alias for it. I also updated the tests for trace to reflect the change to runcall over runfunc. ---------- keywords: +patch nosy: +Gordon C Added file: http://bugs.python.org/file41116/9941.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 15:26:57 2015 From: report at bugs.python.org (Davin Potts) Date: Sat, 21 Nov 2015 20:26:57 +0000 Subject: [issue25656] multiprocessing.dummy: pool.map hangs on empty list In-Reply-To: <1447855498.22.0.263851728204.issue25656@psf.upfronthosting.co.za> Message-ID: <1448137617.38.0.849488001131.issue25656@psf.upfronthosting.co.za> Davin Potts added the comment: @tomer70: Thanks for the update and glad to hear that updating to the latest release fixed the issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 16:56:20 2015 From: report at bugs.python.org (=?utf-8?q?Jacek_Ko=C5=82odziej?=) Date: Sat, 21 Nov 2015 21:56:20 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <1448142980.63.0.953101673049.issue23883@psf.upfronthosting.co.za> Changes by Jacek Ko?odziej : Added file: http://bugs.python.org/file41117/Issue23883_calendar_all.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 16:56:43 2015 From: report at bugs.python.org (=?utf-8?q?Jacek_Ko=C5=82odziej?=) Date: Sat, 21 Nov 2015 21:56:43 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <1448143003.33.0.578788147019.issue23883@psf.upfronthosting.co.za> Jacek Ko?odziej added the comment: Week and no response, I'm posting updated patches for calendar and tarfile. ---------- Added file: http://bugs.python.org/file41118/Issue23883_tarfile_all.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 17:01:43 2015 From: report at bugs.python.org (Jason R. Coombs) Date: Sat, 21 Nov 2015 22:01:43 +0000 Subject: [issue25692] input function outputs prompt to stderr Message-ID: <1448143303.11.0.840684568567.issue25692@psf.upfronthosting.co.za> New submission from Jason R. Coombs: The built-in function 'input' appears to be sending the prompt to stderr instead of stdout, as the docs state it should. $ python3.5 -c "print('stdout'); import sys; print('stderr', file=sys.stderr); input('foo')" 2> errors.txt stdout hello $ cat errors.txt stderr foo I've replicated this behavior in both Python 3.4 on Linux and Python 3.5 and 2.7 on OS X. Here's the 2.7 test/output: $ python2.7 -c "from __future__ import print_function; print('stdout'); import sys; print('stderr', file=sys.stderr); raw_input('foo')" 2> errors.txt stdout hello $ cat errors.txt stderr foo I believe the stated behavior (outputting the prompt to stdout) is the proper behavior. I figure I must be doing something wrong here, because it seems bizarre to me that this discrepancy hasn't been discovered before. ---------- messages: 255072 nosy: jason.coombs priority: normal severity: normal status: open title: input function outputs prompt to stderr versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 17:22:55 2015 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 21 Nov 2015 22:22:55 +0000 Subject: [issue19687] Fixes for elementtree integer overflow In-Reply-To: <1385078611.06.0.503563950207.issue19687@psf.upfronthosting.co.za> Message-ID: <1448144575.09.0.501747561924.issue19687@psf.upfronthosting.co.za> Eli Bendersky added the comment: Serhiy, I'm truly sorry but for this and other issues you pinged -- I currently have zero bandwidth to invest in this. Feel free to ask around on pydev if there are other folks interested in reviewing patches and decisions w.r.t the etree module. I'm fine with your judgement otherwise. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 17:46:06 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 21 Nov 2015 22:46:06 +0000 Subject: [issue25689] ftplib docs language fix In-Reply-To: <1448109352.75.0.661923441746.issue25689@psf.upfronthosting.co.za> Message-ID: <1448145966.68.0.0184297036104.issue25689@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks for the patch, I will commit it. I also noticed the same problem in nntplib. And I think the sentence works even better starting as ?The FTP class supports .?.?.?. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 17:56:51 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 21 Nov 2015 22:56:51 +0000 Subject: [issue25689] ftplib docs language fix In-Reply-To: <1448109352.75.0.661923441746.issue25689@psf.upfronthosting.co.za> Message-ID: <20151121225648.15095.47816@psf.io> Roundup Robot added the comment: New changeset 74111e62a76c by Martin Panter in branch '3.4': Issue #25689: Fix language in ftplib and nntplib docs https://hg.python.org/cpython/rev/74111e62a76c New changeset 2fa12e53e8f3 by Martin Panter in branch '3.5': Issue #25689: Merge ftplib and nntplib docs from 3.4 into 3.5 https://hg.python.org/cpython/rev/2fa12e53e8f3 New changeset b99a30383bd5 by Martin Panter in branch 'default': Issue #25689: Merge ftplib and nntplib docs from 3.5 https://hg.python.org/cpython/rev/b99a30383bd5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 18:06:27 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 21 Nov 2015 23:06:27 +0000 Subject: [issue25689] ftplib docs language fix In-Reply-To: <1448109352.75.0.661923441746.issue25689@psf.upfronthosting.co.za> Message-ID: <1448147187.9.0.986049312769.issue25689@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 18:09:28 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 21 Nov 2015 23:09:28 +0000 Subject: [issue25692] input function outputs prompt to stderr In-Reply-To: <1448143303.11.0.840684568567.issue25692@psf.upfronthosting.co.za> Message-ID: <1448147368.75.0.00294860979406.issue25692@psf.upfronthosting.co.za> Martin Panter added the comment: This has been discovered before: Issue 1927, with a simple patch. The choice between stdout and stderr seems to be rather complicated, so the patch may need a bit more work. ---------- nosy: +martin.panter resolution: -> duplicate status: open -> closed superseder: -> raw_input behavior incorrect if readline not enabled _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 19:14:32 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 22 Nov 2015 00:14:32 +0000 Subject: [issue12869] PyOS_StdioReadline is printing the prompt on stderr In-Reply-To: <1314801518.5.0.445361297153.issue12869@psf.upfronthosting.co.za> Message-ID: <1448151272.55.0.808316033052.issue12869@psf.upfronthosting.co.za> Martin Panter added the comment: Actually Issue 1927 has a simple patch which should change this to stdout. I haven?t tested, the code looks like that patch will not use a redirected sys.stdout, so it would match not using a redirected sys.stdin. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 19:39:50 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 22 Nov 2015 00:39:50 +0000 Subject: [issue25690] Replacement for unittest.mock.mock_open In-Reply-To: <1448122983.8.0.049241542179.issue25690@psf.upfronthosting.co.za> Message-ID: <1448152790.47.0.176646590403.issue25690@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks for the submission. I haven't looked at this in detail, but the fact that you are changing existing unit tests indicates there is probably a backward compatibility problem with your patch. Also if you are adding features I'd expect there to be doc changes, which would make it easier to understand what you are proposing. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 19:56:14 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 22 Nov 2015 00:56:14 +0000 Subject: [issue25612] nested try..excepts don't work correctly for generators In-Reply-To: <1447361959.0.0.839122121456.issue25612@psf.upfronthosting.co.za> Message-ID: <1448153774.29.0.536759866234.issue25612@psf.upfronthosting.co.za> Martin Panter added the comment: Nick, your scenario seems to behave no differently with and without the patch: Traceback (most recent call last): File "", line 2, in __main__.MainError ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 20:13:22 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 22 Nov 2015 01:13:22 +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: <1448154802.14.0.173223712782.issue1927@psf.upfronthosting.co.za> Martin Panter added the comment: The input() implementation is a bit like this: def input(prompt): if stdin and stdout are the original file descriptors, and are terminals: return PyOS_Readline(sys.stdin, sys.stdout, prompt) else: sys.stdout.write(prompt) # Writes to stdout return sys.stdin.readline() def PyOS_StdioReadline(stdin, stdout, prompt): '''Default implementation of PyOS_Readline()''' sys.stderr.write(prompt) # Writes to stderr return stdin.readline() def call_readline(stdin, stdout, prompt): '''Implementation of PyOS_Readline() in the "readline" module''' rl_instream = stdin rl_outstream = stdout # Readline writes to stdout return readline_until_enter_or_signal(prompt) It looks like PyOS_StdioReadline() has always written to stderr. The stdin and stdout parameters of PyOS_Readline() were added later, in revision dc4a0336a2a3. I think the changes to myreadline.c will also affect the interactive interpreter prompt. But we have Issue 12869 open to change that to stdout, so maybe the change is okay. Since input() should no longer depend on any instance of stderr, perhaps the check for ?lost sys.stderr? should also be removed. It may be worth applying any changes in myreadline.c to the independent version in pgenmain.c as well, just for consistency. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 21:12:07 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 22 Nov 2015 02:12:07 +0000 Subject: [issue25680] Selector.select() hangs when there is nothing to select In-Reply-To: <1448029102.96.0.470819036773.issue25680@psf.upfronthosting.co.za> Message-ID: <1448158327.6.0.93033536019.issue25680@psf.upfronthosting.co.za> Martin Panter added the comment: I would expect it to hang (until the timeout expired) of no files are added. If it returns an empty list, that should mean the timeout expired. I guess Mac uses KqueueSelector. I would certainly expect SelectSelector to hang. Maybe the underlying kqueue implementation behaves differently though. Perhaps Python should handle this as a special case in the selectors module? ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 23:47:25 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Sun, 22 Nov 2015 04:47:25 +0000 Subject: [issue25643] Python tokenizer rewriting In-Reply-To: <1447723653.14.0.424824913135.issue25643@psf.upfronthosting.co.za> Message-ID: <1448167645.57.0.728023870066.issue25643@psf.upfronthosting.co.za> Changes by St?phane Wirtel : ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 01:29:50 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Sun, 22 Nov 2015 06:29:50 +0000 Subject: [issue25643] Python tokenizer rewriting In-Reply-To: <1447723653.14.0.424824913135.issue25643@psf.upfronthosting.co.za> Message-ID: <20151122062946.GA29075@sg1> St?phane Wirtel added the comment: Hi Serhiy, Just of your information but I think you know that, the tests pass ;-) [398/399] test_multiprocessing_spawn (138 sec) -- running: test_tools (108 sec) [399/399] test_tools (121 sec) 385 tests OK. 3 tests altered the execution environment: test___all__ test_site test_warnings 11 tests skipped: test_devpoll test_kqueue test_msilib test_ossaudiodev test_startfile test_tix test_tk test_ttk_guionly test_winreg test_winsound test_zipfile64 But I am interested by this part of CPython, I am not an expert in lexing and parsing but how can I help you ? I am a novice in this domain. Stephane ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 01:41:37 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Sun, 22 Nov 2015 06:41:37 +0000 Subject: [issue25485] Add a context manager to telnetlib.Telnet In-Reply-To: <1445883619.21.0.032521861016.issue25485@psf.upfronthosting.co.za> Message-ID: <1448174497.96.0.373396012022.issue25485@psf.upfronthosting.co.za> St?phane Wirtel added the comment: I applied the recommendation of SilentGhost for this issue. Need review Thank you ---------- Added file: http://bugs.python.org/file41119/issue25485-4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 01:50:11 2015 From: report at bugs.python.org (Dingyuan Wang) Date: Sun, 22 Nov 2015 06:50:11 +0000 Subject: [issue25624] shutil.make_archive makes invalid directory entries In-Reply-To: <1447493124.52.0.848319062026.issue25624@psf.upfronthosting.co.za> Message-ID: <1448175011.56.0.925919141725.issue25624@psf.upfronthosting.co.za> Dingyuan Wang added the comment: Yes, patching zipfile is enough. I wrote a test using `unzip -t` to check the zip. ZipFile.testzip can't detect this kind of error because zlib.decompressobj(-15) will decode b'' to b'' without errors. ---------- Added file: http://bugs.python.org/file41120/storedirectory_test.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 02:07:19 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 22 Nov 2015 07:07:19 +0000 Subject: [issue25660] tabs don't work correctly in python repl In-Reply-To: <1447876730.91.0.918964104484.issue25660@psf.upfronthosting.co.za> Message-ID: <1448176039.28.0.225465869218.issue25660@psf.upfronthosting.co.za> Larry Hastings added the comment: The "release blocker" priority level is inappropriate for nice-to-have features. Quoting PEP 101, the how-to-make-a-Python-release guide: release blocker - Stops the release dead in its tracks. You may not make any release with any open release blocker bugs. While I'd like to see this fixed too, I'm not holding up the release for it. ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 02:07:26 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 22 Nov 2015 07:07:26 +0000 Subject: [issue25660] tabs don't work correctly in python repl In-Reply-To: <1447876730.91.0.918964104484.issue25660@psf.upfronthosting.co.za> Message-ID: <1448176046.65.0.237231029485.issue25660@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- priority: release blocker -> normal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 03:08:35 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 22 Nov 2015 08:08:35 +0000 Subject: [issue25693] test_asyncio prints some messages Message-ID: <1448179715.27.0.908145386853.issue25693@psf.upfronthosting.co.za> New submission from Arfrever Frehtes Taifersar Arahesis: When running full test suite, test_asyncio prints some messages. ResourceWarnings should be fixed. Other messages should not be shown, at least without --verbose. [171/398] test_epoll [172/398] test_optparse [173/398] test_socket [174/398] test_sax [175/398] test_weakref [176/398] test_codecmaps_tw [177/398] test_property [178/398] test_asyncio Executing .start() done, defined at /tmp/cpython/Lib/test/test_asyncio/test_pep492.py:146> result=None created at /tmp/cpython/Lib/asyncio/base_events.py:317> took 0.252 seconds /tmp/cpython/Lib/threading.py:864: ResourceWarning: unclosed self._target(*self._args, **self._kwargs) returning true from eof_received() has no effect when using ssl returning true from eof_received() has no effect when using ssl /tmp/cpython/Lib/asyncio/base_events.py:379: ResourceWarning: unclosed event loop <_UnixSelectorEventLoop running=False closed=False debug=False> warnings.warn("unclosed event loop %r" % self, ResourceWarning) [179/398] test_os [180/398] test_enumerate [181/398] test_math [182/398] test_zipfile [183/398] test_tarfile [184/398] test_pep380 [185/398] test_with [186/398] test_mmap [187/398] test_trace [188/398] test_eintr ---------- components: Tests, asyncio messages: 255086 nosy: Arfrever, giampaolo.rodola, gvanrossum, haypo, pitrou, yselivanov priority: normal severity: normal status: open title: test_asyncio prints some messages versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 03:49:09 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 22 Nov 2015 08:49:09 +0000 Subject: [issue25694] test.libregrtest not installed Message-ID: <1448182149.01.0.175316940428.issue25694@psf.upfronthosting.co.za> New submission from Arfrever Frehtes Taifersar Arahesis: test.libregrtest is not installed, which breaks running of test suite from installed Python. Probably LIBSUBDIRS in Makefile.pre.in should be updated. $ python3.5 -m test test_int [1/1] test_int 1 test OK. $ python3.6 -m test test_int Traceback (most recent call last): File "/usr/lib64/python3.6/runpy.py", line 170, in _run_module_as_main "__main__", mod_spec) File "/usr/lib64/python3.6/runpy.py", line 85, in _run_code exec(code, run_globals) File "/usr/lib64/python3.6/test/__main__.py", line 1, in from test import regrtest File "/usr/lib64/python3.6/test/regrtest.py", line 14, in from test.libregrtest import main, main_in_temp_cwd ImportError: No module named 'test.libregrtest' ---------- assignee: haypo components: Tests messages: 255087 nosy: Arfrever, haypo priority: normal severity: normal status: open title: test.libregrtest not installed versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 03:58:58 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 22 Nov 2015 08:58:58 +0000 Subject: [issue25695] test___all__ and test_support alter execution environment Message-ID: <1448182737.98.0.235138945354.issue25695@psf.upfronthosting.co.za> New submission from Arfrever Frehtes Taifersar Arahesis: test___all__ and test_support alter execution environment. Problem seems to be present only in Python 3.6. $ python3.5 -m test test___all__ test_support [1/2] test___all__ [2/2] test_support All 2 tests OK. $ python3.6 -m test test___all__ test_support [1/2] test___all__ Warning -- files was modified by test___all__ [2/2] test_support Warning -- files was modified by test_support 2 tests altered the execution environment: test___all__ test_support When running these test files separately, problem is only present for test___all__: $ python3.5 -m test test___all__ [1/1] test___all__ 1 test OK. $ python3.6 -m test test___all__ [1/1] test___all__ Warning -- files was modified by test___all__ 1 test altered the execution environment: test___all__ $ python3.5 -m test test_support [1/1] test_support 1 test OK. $ python3.6 -m test test_support [1/1] test_support 1 test OK. ---------- components: Tests messages: 255088 nosy: Arfrever, ezio.melotti, haypo priority: normal severity: normal status: open title: test___all__ and test_support alter execution environment versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 04:11:25 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 22 Nov 2015 09:11:25 +0000 Subject: [issue25693] test_asyncio prints some messages In-Reply-To: <1448179715.27.0.908145386853.issue25693@psf.upfronthosting.co.za> Message-ID: <1448183485.24.0.610513126677.issue25693@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- resolution: -> duplicate status: open -> closed superseder: -> asyncio tests are getting noisy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 05:24:46 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 22 Nov 2015 10:24:46 +0000 Subject: [issue19687] Fixes for elementtree integer overflow In-Reply-To: <1385078611.06.0.503563950207.issue19687@psf.upfronthosting.co.za> Message-ID: <1448187886.56.0.184115046868.issue19687@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Christian's patch fixes two things: integer overflow and memory leak. First I'll commit a fix for memory leak (with cleanup and tests). Integer overflow looks already fixed in recent releases, there is nothing to commit. This part should be applied only to old releases. ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 05:31:45 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 22 Nov 2015 10:31:45 +0000 Subject: [issue19687] Fixes for elementtree integer overflow In-Reply-To: <1385078611.06.0.503563950207.issue19687@psf.upfronthosting.co.za> Message-ID: <20151122103142.38235.46418@psf.io> Roundup Robot added the comment: New changeset d51d420f3e9d by Serhiy Storchaka in branch '3.4': Issue #19687: Fixed memory leak on failed Element slice assignment. https://hg.python.org/cpython/rev/d51d420f3e9d New changeset 4d5417444961 by Serhiy Storchaka in branch '3.5': Issue #19687: Fixed memory leak on failed Element slice assignment. https://hg.python.org/cpython/rev/4d5417444961 New changeset de5a11836ad4 by Serhiy Storchaka in branch 'default': Issue #19687: Fixed memory leak on failed Element slice assignment. https://hg.python.org/cpython/rev/de5a11836ad4 New changeset c33e4881721f by Serhiy Storchaka in branch '2.7': Issue #19687: Fixed memory leak on failed Element slice assignment. https://hg.python.org/cpython/rev/c33e4881721f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 05:33:17 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Sun, 22 Nov 2015 10:33:17 +0000 Subject: [issue4744] asynchat documentation needs to be more precise In-Reply-To: <1230168171.56.0.381937953807.issue4744@psf.upfronthosting.co.za> Message-ID: <1448188397.41.0.26692575932.issue4744@psf.upfronthosting.co.za> St?phane Wirtel added the comment: Ping, what's the status of this issue ? maybe we can close it and open an new one with a new description. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 05:38:12 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Sun, 22 Nov 2015 10:38:12 +0000 Subject: [issue22218] Fix more compiler warnings "comparison between signed and unsigned integers" In-Reply-To: <1408296679.77.0.83853794909.issue22218@psf.upfronthosting.co.za> Message-ID: <1448188692.13.0.35929415601.issue22218@psf.upfronthosting.co.za> St?phane Wirtel added the comment: a patch for 3.6 for the unicodeobject.c file ---------- versions: +Python 3.6 -Python 3.5 Added file: http://bugs.python.org/file41121/issue22218-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 05:52:10 2015 From: report at bugs.python.org (SilentGhost) Date: Sun, 22 Nov 2015 10:52:10 +0000 Subject: [issue25695] test___all__ and test_support alter execution environment In-Reply-To: <1448182737.98.0.235138945354.issue25695@psf.upfronthosting.co.za> Message-ID: <1448189530.08.0.180641961681.issue25695@psf.upfronthosting.co.za> SilentGhost added the comment: test_support has this line: TESTDIRN = os.path.basename(tempfile.mkdtemp(dir='.')) Which is the culprit. The reason it gets so far as to import the module is due to the "fuzzy logic" check looking for __all__ What I'd suggest is replacing simple "in" string search with re.search for '\b__all__\b'. The downside of this is that the test execution time increased from .4 s to .7 s on my machine. ---------- keywords: +needs review, patch nosy: +SilentGhost stage: -> patch review Added file: http://bugs.python.org/file41122/issue25695.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 06:27:11 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 22 Nov 2015 11:27:11 +0000 Subject: [issue19687] Fixes for elementtree integer overflow In-Reply-To: <1385078611.06.0.503563950207.issue19687@psf.upfronthosting.co.za> Message-ID: <1448191631.82.0.516039210002.issue19687@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is updated patch for 3.4. Added new overflow checks in element_resize(), some runtime checks are replaced with asserts (conditions are always true), check for buffer size is copied from 3.5, followed Eli's suggestions about nchildren and index. ---------- Added file: http://bugs.python.org/file41123/elementtree_overflow3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 06:36:05 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 22 Nov 2015 11:36:05 +0000 Subject: [issue25694] test.libregrtest not installed In-Reply-To: <1448182149.01.0.175316940428.issue25694@psf.upfronthosting.co.za> Message-ID: <1448192165.97.0.61949026679.issue25694@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 06:40:28 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 22 Nov 2015 11:40:28 +0000 Subject: [issue25455] Some repr implementations don't check for self-referential structures In-Reply-To: <1445455038.6.0.824380060049.issue25455@psf.upfronthosting.co.za> Message-ID: <1448192428.44.0.857723201371.issue25455@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Raymond, could you please make a review of the first patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 07:32:17 2015 From: report at bugs.python.org (=?utf-8?q?Adam_Barto=C5=A1?=) Date: Sun, 22 Nov 2015 12:32:17 +0000 Subject: [issue12869] PyOS_StdioReadline is printing the prompt on stderr In-Reply-To: <1314801518.5.0.445361297153.issue12869@psf.upfronthosting.co.za> Message-ID: <1448195537.01.0.550783135085.issue12869@psf.upfronthosting.co.za> Adam Barto? added the comment: > * The interactive interpreter always reads from the original standard input, whether Readline is used or not. This is not true ? the interactive interpreter reads via PyOS_Readline, which may call whatever readline hook is installed. I think the situation would be much more clear if something like my proposal was implemented (https://mail.python.org/pipermail/python-dev/2015-November/142246.html). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 07:56:55 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 22 Nov 2015 12:56:55 +0000 Subject: [issue25624] shutil.make_archive makes invalid directory entries In-Reply-To: <1447493124.52.0.848319062026.issue25624@psf.upfronthosting.co.za> Message-ID: <20151122125651.15085.72684@psf.io> Roundup Robot added the comment: New changeset e7d1df56f70b by Serhiy Storchaka in branch '3.4': Issue #25624: ZipFile now always writes a ZIP_STORED header for directory https://hg.python.org/cpython/rev/e7d1df56f70b New changeset 0f8d426e0d0c by Serhiy Storchaka in branch '3.5': Issue #25624: ZipFile now always writes a ZIP_STORED header for directory https://hg.python.org/cpython/rev/0f8d426e0d0c New changeset 09ed44192995 by Serhiy Storchaka in branch 'default': Issue #25624: ZipFile now always writes a ZIP_STORED header for directory https://hg.python.org/cpython/rev/09ed44192995 New changeset de5582c569ff by Serhiy Storchaka in branch '2.7': Issue #25624: ZipFile now always writes a ZIP_STORED header for directory https://hg.python.org/cpython/rev/de5582c569ff ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 08:01:06 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 22 Nov 2015 13:01:06 +0000 Subject: [issue25624] shutil.make_archive makes invalid directory entries In-Reply-To: <1447493124.52.0.848319062026.issue25624@psf.upfronthosting.co.za> Message-ID: <1448197266.96.0.488612291022.issue25624@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your contribution Dingyuan. Benjamin, I think this fix should be in 2.7.11. It was a regression in 2.7.11 that had made shutil.make_archive() unusable with the zip format. ---------- nosy: +benjamin.peterson, larry priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 08:05:21 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 22 Nov 2015 13:05:21 +0000 Subject: [issue25684] ttk.OptionMenu radiobuttons aren't unique between two instances of OptionMenu In-Reply-To: <1448040288.53.0.198369542776.issue25684@psf.upfronthosting.co.za> Message-ID: <1448197521.35.0.579903362388.issue25684@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could you provide a patch Bryan? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 08:52:05 2015 From: report at bugs.python.org (STINNER Victor) Date: Sun, 22 Nov 2015 13:52:05 +0000 Subject: [issue25680] Selector.select() hangs when there is nothing to select In-Reply-To: <1448029102.96.0.470819036773.issue25680@psf.upfronthosting.co.za> Message-ID: <1448200325.6.0.462038269995.issue25680@psf.upfronthosting.co.za> STINNER Victor added the comment: Aleksey Kladov: "To show surprising platform-dependent API behavior." Hum ok, it makes sense :-) I agree that it would be better to have a portable behaviour in the selectors module which is supposed to be an abstraction providing a portable behaviour. We already wrote code to have the same behaviour when a file descriptor is closed (handle EBADF). Aleksey Kladov: "I think this special case should also be mentioned in the docs." I disagree, we can do better than documenting "bugs" :-) select.select([], [], [], None) raise an OSError "An invalid argument was supplied" on Windows. I propose to use this behaviour on all platforms for all selectors. I should be easy to write a patch in selectors, is anyone interested to write a patch? ---------- components: +asyncio nosy: +gvanrossum, neologix, yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 09:27:52 2015 From: report at bugs.python.org (Aleksey Kladov) Date: Sun, 22 Nov 2015 14:27:52 +0000 Subject: [issue25680] Selector.select() hangs when there is nothing to select In-Reply-To: <1448029102.96.0.470819036773.issue25680@psf.upfronthosting.co.za> Message-ID: <1448202472.71.0.704784203481.issue25680@psf.upfronthosting.co.za> Aleksey Kladov added the comment: >I disagree, we can do better than documenting "bugs" :-) The result of `select.select([], [], [], None)` should defintelly be documented. Three platoforms made three different decisions in similar situation, so any behavior is reasonable and it should be made clear which one is used by Python. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 09:31:42 2015 From: report at bugs.python.org (STINNER Victor) Date: Sun, 22 Nov 2015 14:31:42 +0000 Subject: [issue25696] "make install" fails because bininstall target requires the libainstall target Message-ID: <1448202702.88.0.964294450431.issue25696@psf.upfronthosting.co.za> New submission from STINNER Victor: I'm unable to install Python 3.6, "make install" doesn't copy .py files because the bininstall target failed. It failed because /opt/py36/lib/pkgconfig doesn't exist. Try: --- export MAKEFLAGS=-j9 rm -rf /opt/py36 ./configure --prefix=/opt/py36 make make install # you may need 'sudo make install' --- Attached patch fixes the Makefile, but I don't know if my change is correct. ---------- components: Build files: bininstall.patch keywords: patch messages: 255102 nosy: Arfrever, doko, haypo priority: normal severity: normal status: open title: "make install" fails because bininstall target requires the libainstall target versions: Python 3.6 Added file: http://bugs.python.org/file41124/bininstall.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 09:33:59 2015 From: report at bugs.python.org (STINNER Victor) Date: Sun, 22 Nov 2015 14:33:59 +0000 Subject: [issue25696] "make install" fails because bininstall target requires the libainstall target In-Reply-To: <1448202702.88.0.964294450431.issue25696@psf.upfronthosting.co.za> Message-ID: <1448202839.76.0.939641420087.issue25696@psf.upfronthosting.co.za> STINNER Victor added the comment: Output: --- $ make install --debug=v (...) Must remake target 'bininstall'. (...) (cd /opt/py36/lib/pkgconfig; ln -s python-3.6.pc python-3.6dm.pc); (...) (...) /bin/sh: ligne 4 : cd: /opt/py36/lib/pkgconfig: Aucun fichier ou dossier de ce type --- ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 09:45:16 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 22 Nov 2015 14:45:16 +0000 Subject: [issue25694] test.libregrtest not installed In-Reply-To: <1448182149.01.0.175316940428.issue25694@psf.upfronthosting.co.za> Message-ID: <20151122144512.127552.12659@psf.io> Roundup Robot added the comment: New changeset 1f563b259f09 by Victor Stinner in branch 'default': Issue #25694: Install test.libregrtest to be able to run tests on the installed https://hg.python.org/cpython/rev/1f563b259f09 New changeset fea86d0049d2 by Victor Stinner in branch 'default': Issue #25694: Fix test_regrtest for installed Python https://hg.python.org/cpython/rev/fea86d0049d2 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 09:46:14 2015 From: report at bugs.python.org (STINNER Victor) Date: Sun, 22 Nov 2015 14:46:14 +0000 Subject: [issue25694] test.libregrtest not installed In-Reply-To: <1448182149.01.0.175316940428.issue25694@psf.upfronthosting.co.za> Message-ID: <1448203574.81.0.28655322309.issue25694@psf.upfronthosting.co.za> STINNER Victor added the comment: Hum, not only libregrtest was not installable, but test_regrtest didn't work on installed Python. Can you please retry? It would be nice to modify test_regrtest to *not* write into the test package, but I failed to find a way to load tests from a different directory :-/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 10:44:48 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 22 Nov 2015 15:44:48 +0000 Subject: [issue25697] Fix rough alphabetical order in Misc/ACKS Message-ID: <1448207088.07.0.222703830715.issue25697@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: the list in Misc/ACKS is intended to be in rough alphabetical order by last names. But some lines breaks this order. Proposed patch restores ordering. It also removes duplicates for Richard Oudkerk. Correct sorting is not easy due to different letter order in different alphabets and different collation rules in different languages. I tried to take it into account, but can make a mistake. ---------- assignee: docs at python components: Documentation files: acks_order-3.6.patch keywords: patch messages: 255106 nosy: docs at python, georg.brandl, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Fix rough alphabetical order in Misc/ACKS Added file: http://bugs.python.org/file41125/acks_order-3.6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 11:17:08 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 22 Nov 2015 16:17:08 +0000 Subject: [issue24858] python3 -m test -ugui -v test_tk gives 3 failures under Debian unstable (sid) In-Reply-To: <1439486580.93.0.0912467403749.issue24858@psf.upfronthosting.co.za> Message-ID: <1448209028.54.0.608416003439.issue24858@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Matthias, can you confirm that this is Debian packaging issue? ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 12:18:12 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 22 Nov 2015 17:18:12 +0000 Subject: [issue25696] "make install" fails because bininstall target requires the libainstall target In-Reply-To: <1448202702.88.0.964294450431.issue25696@psf.upfronthosting.co.za> Message-ID: <1448212692.34.0.693206250677.issue25696@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: This problem in bininstall target seems to exist since Python 2.7 and 3.1. bininstall target depends on altbininstall target, which contains: @for i in $(BINDIR) $(LIBDIR); \ do \ if test ! -d $(DESTDIR)$$i; then \ echo "Creating directory $$i"; \ $(INSTALL) -d -m $(DIRMODE) $(DESTDIR)$$i; \ else true; \ fi; \ done For consistency with other things, I would suggest to add the following at the beginning of bininstall target (instead of making bininstall target depend on libainstall target): @for i in $(LIBPC); \ do \ if test ! -d $(DESTDIR)$$i; then \ echo "Creating directory $$i"; \ $(INSTALL) -d -m $(DIRMODE) $(DESTDIR)$$i; \ else true; \ fi; \ done ---------- versions: +Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 13:58:26 2015 From: report at bugs.python.org (Matthias Klose) Date: Sun, 22 Nov 2015 18:58:26 +0000 Subject: [issue25698] test regressions introduced with the fix for #22995 Message-ID: <1448218706.46.0.334921108763.issue25698@psf.upfronthosting.co.za> New submission from Matthias Klose: seen with the 2.7.11 release candidate; I'm not yet 100% if this is the fix for #22995 causing these test regressions. [ 93/395] test_cpickle test test_cpickle failed -- multiple errors occurred; run in verbose mode for details [101/395/2] test_decimal test test_decimal failed -- Traceback (most recent call last): File "/home/packages/python/2.7/python2.7-2.7.11~rc1/Lib/test/test_decimal.py", line 1774, in test_pickle e = pickle.loads(pickle.dumps(c, proto)) File "/home/packages/python/2.7/python2.7-2.7.11~rc1/Lib/pickle.py", line 1380, in dumps Pickler(file, protocol).dump(obj) File "/home/packages/python/2.7/python2.7-2.7.11~rc1/Lib/pickle.py", line 224, in dump self.save(obj) File "/home/packages/python/2.7/python2.7-2.7.11~rc1/Lib/pickle.py", line 306, in save rv = reduce(self.proto) AttributeError: 'module' object has no attribute '_reduce_ex' [108/395/4] test_dictviews test test_dictviews failed -- Traceback (most recent call last): File "/home/packages/python/2.7/python2.7-2.7.11~rc1/Lib/test/test_dictviews.py", line 201, in test_pickle pickle.dumps, d.viewkeys(), proto) File "/home/packages/python/2.7/python2.7-2.7.11~rc1/Lib/unittest/case.py", line 473, in assertRaises callableObj(*args, **kwargs) File "/home/packages/python/2.7/python2.7-2.7.11~rc1/Lib/pickle.py", line 1380, in dumps Pickler(file, protocol).dump(obj) File "/home/packages/python/2.7/python2.7-2.7.11~rc1/Lib/pickle.py", line 224, in dump self.save(obj) File "/home/packages/python/2.7/python2.7-2.7.11~rc1/Lib/pickle.py", line 306, in save rv = reduce(self.proto) AttributeError: 'module' object has no attribute '_reduce_ex' [177/395/7] test_imp test test_imp failed -- Traceback (most recent call last): File "/home/packages/python/2.7/python2.7-2.7.11~rc1/Lib/test/test_imp.py", line 60, in test_source imp.reload(os) File "/home/packages/python/2.7/python2.7-2.7.11~rc1/Lib/os.py", line 727, in _copy_reg.pickle(stat_result, _pickle_stat_result, _make_stat_result) AttributeError: 'module' object has no attribute 'pickle' [184/395/10] test_int_literal [185/395/10] test_ioctl test test_ioctl crashed -- : 'module' object has no attribute 'pickle' [186/395/11] test_isinstance [187/395/11] test_iter [188/395/11] test_iterlen [189/395/11] test_itertools [190/395/11] test_json test test_json crashed -- : 'module' object has no attribute 'pickle' [191/395/12] test_kqueue test_kqueue skipped -- test works only on BSD [192/395/12] test_largefile test test_largefile crashed -- : 'module' object has no attribute 'pickle' [193/395/13] test_lib2to3 test test_lib2to3 crashed -- : 'module' object has no attribute 'pickle' [194/395/14] test_linecache test test_linecache crashed -- : 'module' object has no attribute 'pickle' [195/395/15] test_list test test_list crashed -- : 'module' object has no attribute 'pickle' [196/395/16] test_locale [197/395/16] test_logging test test_logging crashed -- : 'module' object has no attribute 'pickle' [198/395/17] test_long [199/395/17] test_long_future [200/395/17] test_longexp [201/395/17] test_macos test test_macos crashed -- : 'module' object has no attribute 'pickle' [202/395/18] test_macostools test test_macostools crashed -- : 'module' object has no attribute 'pickle' [203/395/19] test_macpath [204/395/19] test_macurl2path [205/395/19] test_mailbox test test_mailbox crashed -- : 'module' object has no attribute 'pickle' [206/395/20] test_marshal test test_marshal crashed -- : 'module' object has no attribute 'pickle' [207/395/21] test_math test test_math crashed -- : 'module' object has no attribute 'pickle' [208/395/22] test_md5 [209/395/22] test_memoryio test test_memoryio failed -- multiple errors occurred; run in verbose mode for details [210/395/23] test_memoryview [211/395/23] test_mhlib test test_mhlib crashed -- : 'module' object has no attribute 'pickle' ---------- components: Extension Modules messages: 255109 nosy: benjamin.peterson, doko, serhiy.storchaka priority: release blocker severity: normal status: open title: test regressions introduced with the fix for #22995 versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 14:47:02 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 22 Nov 2015 19:47:02 +0000 Subject: [issue25455] Some repr implementations don't check for self-referential structures In-Reply-To: <1445455038.6.0.824380060049.issue25455@psf.upfronthosting.co.za> Message-ID: <1448221622.29.0.610327392435.issue25455@psf.upfronthosting.co.za> Raymond Hettinger added the comment: >Raymond, could you please make a review of the first patch? Will do. Also, we should ask Antoine Pitrou to look at the TextIO patch and ask Stephan Krah to look at the ElementTree patch. ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 15:46:20 2015 From: report at bugs.python.org (John Mark Vandenberg) Date: Sun, 22 Nov 2015 20:46:20 +0000 Subject: [issue25699] Easier way to specify reduced globals for doctest Message-ID: <1448225180.77.0.54969716848.issue25699@psf.upfronthosting.co.za> New submission from John Mark Vandenberg: Currently doctest.testmod `globals` defaults to including everything in the module scope, and tools like pyflakes assume that doctests run with globals as a copy of __dict__ . It is relatively simple to exclude everything using doctest.testmod(globs={}). However to use a limited scope, such as only including attributes in __all__, we need to use `doctest.testmod(globs=[(name, globals()[name]) for name in __all__])` However those solutions require that each module includes a `if __name__ == "__main__":` block that invokes doctest.testmod, and then other doctest related tools (pyflakes, nose, etc) need to *parse* the invocation to determine the desired globals contents. It would be easier to control the globals using a module attribute that works like __all__, so that all doctest tools could easily determine the desired contents of globals. e.g. the following could provide a sane reduced globals for doctests __test_all__ = __all__ = ['foo'] As people sometimes add docstrings/doctest for functions not exported in __all__ for external use, in addition to the list of symbols in __test_all__, the doctest globals should include the function/class which the docstring/doctest is attached to. See https://bugs.launchpad.net/pyflakes/+bug/1178807 for background to this enhancement request. ---------- components: Tests messages: 255111 nosy: John.Mark.Vandenberg priority: normal severity: normal status: open title: Easier way to specify reduced globals for doctest type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 16:53:22 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 22 Nov 2015 21:53:22 +0000 Subject: [issue4744] asynchat documentation needs to be more precise In-Reply-To: <1230168171.56.0.381937953807.issue4744@psf.upfronthosting.co.za> Message-ID: <1448229202.17.0.607837184501.issue4744@psf.upfronthosting.co.za> Martin Panter added the comment: I think it would be okay to keep this issue open to address the other mentions of ?strings?. Nitika?s patch is missing the special --- and @@ indicator lines at the top, which is probably why it was rejected. Usually you make a patch by using a ?diff? command (standalone, with Mercurial, etc). ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 17:17:55 2015 From: report at bugs.python.org (Matt Hickford) Date: Sun, 22 Nov 2015 22:17:55 +0000 Subject: [issue25251] Unknown MS Compiler version 1900 In-Reply-To: <1447590629.53.0.0908441405229.issue25251@psf.upfronthosting.co.za> Message-ID: Matt Hickford added the comment: Hi Ateik. Find cygwinccompiler.py on your computer and copy the patch to the same folder. Then run the command `patch < patch.diff`. It that doesn't work, just open both files in a text editor and copy and paste the lines to the right place, you'll work it out. It may or not solve your problem. On 15 November 2015 at 12:30, Ateik Al-Zehla wrote: > > Ateik Al-Zehla added the comment: > > how to apply patch file : patch.diff ? plz help > > ---------- > nosy: +Ateik Al-Zehla > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 17:37:44 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 22 Nov 2015 22:37:44 +0000 Subject: [issue25698] test regressions introduced with the fix for #22995 In-Reply-To: <1448218706.46.0.334921108763.issue25698@psf.upfronthosting.co.za> Message-ID: <1448231864.58.0.469477440489.issue25698@psf.upfronthosting.co.za> Martin Panter added the comment: Duplicate or related to Issue 25601? ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 17:50:16 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 22 Nov 2015 22:50:16 +0000 Subject: [issue25697] Fix rough alphabetical order in Misc/ACKS In-Reply-To: <1448207088.07.0.222703830715.issue25697@psf.upfronthosting.co.za> Message-ID: <1448232616.04.0.719865354382.issue25697@psf.upfronthosting.co.za> Martin Panter added the comment: I left one review comment about Ma?kowiak. The other changes look okay. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 18:01:15 2015 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 22 Nov 2015 23:01:15 +0000 Subject: [issue25680] Selector.select() hangs when there is nothing to select In-Reply-To: <1448029102.96.0.470819036773.issue25680@psf.upfronthosting.co.za> Message-ID: <1448233275.42.0.404065728317.issue25680@psf.upfronthosting.co.za> Guido van Rossum added the comment: I don't think we should "fix" the select module; it's advertised as a wrapper around the various syscalls, and if the platforms disagree on what that syscall (e.g. select()) does we shouldn't try to fix it. (Documenting the differences is fine.) However the *selectors* module is a different thing. It defines a better abstraction that's supposedly independent from the underlying syscall. I agree with Aleksey that it should just hang when no FDs are registered and no timeout is given -- this is the only logical extension of its behavior when a FD is registered or a timeout is given. This could be used to wait until e.g. a signal arrives. It's illogical that it would behave differently if a FD was registered that will never fire, or if a timeout of a billion seconds was given (although that may be an easy hack to wait forever if the underlying syscall doesn't like this). The asyncio package would probably be broken because of this except that it always has a FD registered (the self-pipe). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 18:11:11 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 22 Nov 2015 23:11:11 +0000 Subject: [issue24731] Incorrect assert in str_subtype_new In-Reply-To: <1437952885.56.0.72690112679.issue24731@psf.upfronthosting.co.za> Message-ID: <1448233871.74.0.864416565918.issue24731@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your report Kevin and sorry for the delay. I confirm the bug and agree with your solution. The same bug exists for ints and floats. Here are patches that fix crashes. ---------- keywords: +patch nosy: +mark.dickinson stage: needs patch -> patch review Added file: http://bugs.python.org/file41126/issue24731.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 18:11:59 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 22 Nov 2015 23:11:59 +0000 Subject: [issue24731] Incorrect assert in str_subtype_new In-Reply-To: <1437952885.56.0.72690112679.issue24731@psf.upfronthosting.co.za> Message-ID: <1448233919.38.0.0902863643625.issue24731@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file41127/issue24731-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 18:40:04 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 22 Nov 2015 23:40:04 +0000 Subject: [issue25698] test regressions introduced with the fix for #22995 In-Reply-To: <1448218706.46.0.334921108763.issue25698@psf.upfronthosting.co.za> Message-ID: <1448235604.28.0.928916150436.issue25698@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yes, it is a duplicate of issue25601. And I can't reproduce it locally. Matthias, can you reproduce test failure every time when run tests? If yes, could you please run tests in verbose mode and found what tests in test_cpickle were failed first? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 18:59:22 2015 From: report at bugs.python.org (Matthias Klose) Date: Sun, 22 Nov 2015 23:59:22 +0000 Subject: [issue25698] test regressions introduced with the fix for #22995 In-Reply-To: <1448218706.46.0.334921108763.issue25698@psf.upfronthosting.co.za> Message-ID: <1448236762.03.0.439317489964.issue25698@psf.upfronthosting.co.za> Matthias Klose added the comment: looks like re-running the tests in verbose mode using -w is affected by this issue. the first cpickle subtest failing is: ====================================================================== ERROR: test_recursive_dict_subclass_and_inst (test.test_cpickle.cStringIOCPicklerFastTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/packages/python/2.7/python2.7-2.7.11~rc1/Lib/test/test_cpickle.py", line 175, in wrapper func(self) File "/home/packages/python/2.7/python2.7-2.7.11~rc1/Lib/test/pickletester.py", line 819, in test_recursive_dict_subclass_a nd_inst self.check_recursive_collection_and_inst(MyDict.fromkeys) File "/home/packages/python/2.7/python2.7-2.7.11~rc1/Lib/test/pickletester.py", line 790, in check_recursive_collection_and _inst s = self.dumps(y, proto) File "/home/packages/python/2.7/python2.7-2.7.11~rc1/Lib/test/test_cpickle.py", line 141, in dumps p.dump(arg) AttributeError: 'module' object has no attribute '_reduce_ex' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 19:27:30 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 23 Nov 2015 00:27:30 +0000 Subject: [issue25698] test regressions introduced with the fix for #22995 In-Reply-To: <1448218706.46.0.334921108763.issue25698@psf.upfronthosting.co.za> Message-ID: <1448238450.5.0.0507229291394.issue25698@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: In your report test_cpickle has number 93. What other 92 tests were ran before? Could you run tests few times and find minimal list of tests that precede failing test_cpickle? This failure is not related to issue22995 because the same failure was reported in issue25601 5 commits before first commit in issue22995. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 19:44:40 2015 From: report at bugs.python.org (Laur Joost) Date: Mon, 23 Nov 2015 00:44:40 +0000 Subject: [issue25700] namedtuple documentation Message-ID: <1448239480.46.0.591822736111.issue25700@psf.upfronthosting.co.za> New submission from Laur Joost: collections.namedtuple documentation has an example about changing the resulting class docstrings: Docstrings can be customized by making direct assignments to the ``__doc__`` fields: >>> Book = namedtuple('Book', ['id', 'title', 'authors']) >>> Book.__doc__ += ': Hardcover book in active collection' This seems to work for the resulting class, but not the field names: MsgPacket = namedtuple('MsgPacket', ['sender', 'target', 'sig', 'ser_msg']) MsgPacket.__doc__ = '. Message packet format. This is the data added to client queues.' MsgPacket.sender.__doc__ = 'Sender public key.' gives Traceback (most recent call last): File "C:/UTCloud/UT/DS/S11/server.py", line 42, in MsgPacket.sender.__doc__ = 'Sender public key.' AttributeError: readonly attribute ---------- assignee: docs at python components: Documentation messages: 255121 nosy: Laur Joost, docs at python priority: normal severity: normal status: open title: namedtuple documentation versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 19:51:40 2015 From: report at bugs.python.org (Laur Joost) Date: Mon, 23 Nov 2015 00:51:40 +0000 Subject: [issue25700] namedtuple documentation In-Reply-To: <1448239480.46.0.591822736111.issue25700@psf.upfronthosting.co.za> Message-ID: <1448239900.52.0.5935426244.issue25700@psf.upfronthosting.co.za> Laur Joost added the comment: Did my testing on 3.4.3 (other computer). My apologies. ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 21:53:59 2015 From: report at bugs.python.org (Zachary Ware) Date: Mon, 23 Nov 2015 02:53:59 +0000 Subject: [issue25700] namedtuple documentation In-Reply-To: <1448239480.46.0.591822736111.issue25700@psf.upfronthosting.co.za> Message-ID: <1448247239.76.0.0721031346204.issue25700@psf.upfronthosting.co.za> Zachary Ware added the comment: I wonder if it's worth a ..versionchanged note in the namedtuple docs pointing out that __doc__ assignment on fields only works in 3.5+ due to property docstrings becoming writable. ---------- nosy: +zach.ware stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 22:05:38 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 23 Nov 2015 03:05:38 +0000 Subject: [issue25624] shutil.make_archive makes invalid directory entries In-Reply-To: <1447493124.52.0.848319062026.issue25624@psf.upfronthosting.co.za> Message-ID: <20151123030534.21515.22093@psf.io> Roundup Robot added the comment: New changeset 43208b0f2535 by Benjamin Peterson in branch '2.7': Issue #25624: ZipFile now always writes a ZIP_STORED header for directory entries. Patch by Dingyuan Wang. https://hg.python.org/cpython/rev/43208b0f2535 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 23:58:38 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 23 Nov 2015 04:58:38 +0000 Subject: [issue25691] Crash on deleting Element attribute In-Reply-To: <1448125479.67.0.778631980782.issue25691@psf.upfronthosting.co.za> Message-ID: <1448254718.16.0.199090902864.issue25691@psf.upfronthosting.co.za> Martin Panter added the comment: The patch looks good to me. This may be a side effect of poor documentation. I guess the documentation at and/or the referenced functions should mention that the they also delete attributes when the name argument is null. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 00:47:16 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 23 Nov 2015 05:47:16 +0000 Subject: [issue25695] test___all__ and test_support alter execution environment In-Reply-To: <1448182737.98.0.235138945354.issue25695@psf.upfronthosting.co.za> Message-ID: <1448257636.95.0.685069487575.issue25695@psf.upfronthosting.co.za> Martin Panter added the comment: This was introduced with revision f8fa7bc837a3. I guess I overlooked the new messages because I run the tests with -Wall, which is affected by Issue 18383. It seems a bad idea to create a temporary directory when you import the test_support module. I propose this patch to defer creation until the one test that uses it is run. As for your patch Silent Ghost, I?m not sure. It kind of side-steps the real issue by tweaking a heuristic. Maybe we should keep the heuristic as it is, because it is simpler. ---------- nosy: +martin.panter type: -> behavior Added file: http://bugs.python.org/file41128/defer-TESTDIRN.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 01:08:16 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 23 Nov 2015 06:08:16 +0000 Subject: [issue25688] File leak in ElementTree.iterparse() In-Reply-To: <1448104293.18.0.824435970603.issue25688@psf.upfronthosting.co.za> Message-ID: <1448258896.7.0.324980929525.issue25688@psf.upfronthosting.co.za> Martin Panter added the comment: What?s the point of the catch_warnings() and filterwarnings() calls in the tests? They don?t seem to be doing much; I think the CleanContext manager is already enabling warnings. Perhaps you could call simplefilter("error", ResourceWarning) instead. Also I?m not enthusiastic about the iterparse() API when passing a file name. If it has to stay, maybe there should be an explicit way to clean it up without exhausting the iterator, like a generator.close() method. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 01:29:30 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 23 Nov 2015 06:29:30 +0000 Subject: [issue25624] shutil.make_archive makes invalid directory entries In-Reply-To: <1447493124.52.0.848319062026.issue25624@psf.upfronthosting.co.za> Message-ID: <1448260170.08.0.433765834223.issue25624@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Benjamin. ---------- resolution: -> fixed stage: test needed -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 01:50:57 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 23 Nov 2015 06:50:57 +0000 Subject: [issue25691] Crash on deleting Element attribute In-Reply-To: <1448125479.67.0.778631980782.issue25691@psf.upfronthosting.co.za> Message-ID: <20151123065052.127576.823@psf.io> Roundup Robot added the comment: New changeset 852c9ed9115c by Serhiy Storchaka in branch '3.4': Issue #25691: Fixed crash on deleting ElementTree.Element attributes. https://hg.python.org/cpython/rev/852c9ed9115c New changeset 3a44f06907f1 by Serhiy Storchaka in branch '3.5': Issue #25691: Fixed crash on deleting ElementTree.Element attributes. https://hg.python.org/cpython/rev/3a44f06907f1 New changeset 936fcd0ba6b1 by Serhiy Storchaka in branch 'default': Issue #25691: Fixed crash on deleting ElementTree.Element attributes. https://hg.python.org/cpython/rev/936fcd0ba6b1 New changeset e3dea2e4f93d by Serhiy Storchaka in branch '2.7': Issue #25691: Added tests on deleting cElementTree.Element attributes. https://hg.python.org/cpython/rev/e3dea2e4f93d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 01:57:21 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 23 Nov 2015 06:57:21 +0000 Subject: [issue25701] Document that tp_setattro and tp_setattr are used for deleting attributes Message-ID: <1448261841.63.0.685963364339.issue25701@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: tp_setattro and tp_setattr fields of PyTypeObject are used for deleting attributes. In this case the third argument is NULL. This should be documented. Not awareness of this can cause a segmentation fail (for example see issue25698). ---------- assignee: docs at python components: Documentation messages: 255130 nosy: docs at python, serhiy.storchaka priority: normal severity: normal status: open title: Document that tp_setattro and tp_setattr are used for deleting attributes type: crash versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 01:57:28 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 23 Nov 2015 06:57:28 +0000 Subject: [issue25701] Document that tp_setattro and tp_setattr are used for deleting attributes In-Reply-To: <1448261841.63.0.685963364339.issue25701@psf.upfronthosting.co.za> Message-ID: <1448261848.59.0.0113100675889.issue25701@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- priority: normal -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 01:58:04 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 23 Nov 2015 06:58:04 +0000 Subject: [issue25701] Document that tp_setattro and tp_setattr are used for deleting attributes Message-ID: <1448261884.32.0.138792735983.issue25701@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- Removed message: http://bugs.python.org/msg255130 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 01:58:24 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 23 Nov 2015 06:58:24 +0000 Subject: [issue25701] Document that tp_setattro and tp_setattr are used for deleting attributes Message-ID: <1448261904.1.0.459120146493.issue25701@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: tp_setattro and tp_setattr fields of PyTypeObject are used for deleting attributes. In this case the third argument is NULL. This should be documented. Not awareness of this can cause a segmentation fail (for example see issue25691). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 01:58:51 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 23 Nov 2015 06:58:51 +0000 Subject: [issue25701] Document that tp_setattro and tp_setattr are used for deleting attributes In-Reply-To: <1448261904.1.0.459120146493.issue25701@psf.upfronthosting.co.za> Message-ID: <1448261931.5.0.569292373888.issue25701@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 02:01:10 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 23 Nov 2015 07:01:10 +0000 Subject: [issue25691] Crash on deleting Element attribute In-Reply-To: <1448125479.67.0.778631980782.issue25691@psf.upfronthosting.co.za> Message-ID: <1448262070.44.0.887596961416.issue25691@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your review Martin. Opened issue25701 for documenting. Interestingly, 2.7 is free from this bug. It has a check for NULL. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 02:05:54 2015 From: report at bugs.python.org (Eryk Sun) Date: Mon, 23 Nov 2015 07:05:54 +0000 Subject: [issue8304] time.strftime() and Unicode characters on Windows In-Reply-To: <1270307324.04.0.0348018847246.issue8304@psf.upfronthosting.co.za> Message-ID: <1448262354.84.0.562273558937.issue8304@psf.upfronthosting.co.za> Eryk Sun added the comment: The problem from issue 10653 is that internally the CRT encodes the time zone name using the ANSI codepage (i.e. the default system codepage). wcsftime decodes this string using mbstowcs (i.e. multibyte string to wide-character string), which uses Latin-1 in the C locale. In other words, in the C locale on Windows, mbstowcs just casts the byte values to wchar_t. With the new Universal CRT, strftime is implemented by calling wcsftime, so the accepted solution for issue 10653 is broken in 3.5+. A simple way around the problem is to switch back to using wcsftime and temporarily (or permanently) set the thread's LC_CTYPE locale to the system default. This makes the internal mbstowcs call use the ANSI codepage. Note that on POSIX platforms 3.x already sets the default via setlocale(LC_CTYPE, "") in Python/pylifecycle.c. Why not set this for all platforms that have setlocale? > I only tested with my default US locale. If your system locale uses codepage 1252 (a superset of Latin-1), then you can still test this on a per thread basis if your system has additional language packs. For example: import ctypes kernel32 = ctypes.WinDLL('kernel32', use_last_error=True) if kernel32.GetModuleHandleW('ucrtbased'): # debug build crt = ctypes.CDLL('ucrtbased', use_errno=True) else: crt = ctypes.CDLL('ucrtbase', use_errno=True) MUI_LANGUAGE_NAME = 8 LC_CTYPE = 2 class tm(ctypes.Structure): pass crt._gmtime64.restype = ctypes.POINTER(tm) # set a Russian locale for the current thread kernel32.SetThreadPreferredUILanguages(MUI_LANGUAGE_NAME, 'ru-RU\0', None) crt._wsetlocale(LC_CTYPE, 'ru-RU') # update the time zone name based on the thread locale crt._tzset() # get a struct tm * ltime = ctypes.c_int64() crt._time64(ctypes.byref(ltime)) tmptr = crt._gmtime64(ctypes.byref(ltime)) # call wcsftime using C and Russian locales buf = (ctypes.c_wchar * 100)() crt._wsetlocale(LC_CTYPE, 'C') size = crt.wcsftime(buf, 100, '%Z\r\n', tmptr) tz1 = buf[:size] crt._wsetlocale(LC_CTYPE, 'ru-RU') size = crt.wcsftime(buf, 100, '%Z\r\n', tmptr) tz2 = buf[:size] hcon = kernel32.GetStdHandle(-11) pn = ctypes.pointer(ctypes.c_uint()) >>> _ = kernel32.WriteConsoleW(hcon, tz1, len(tz1), pn, None) ????? ? ??????? UTC >>> _ = kernel32.WriteConsoleW(hcon, tz2, len(tz2), pn, None) ????? ? ??????? UTC The first result demonstrates the ANSI => Latin-1 mojibake problem in the C locale. You can encode this result as Latin-1 and then decode it back as codepage 1251: >>> tz1.encode('latin-1').decode('1251') == tz2 True But transcoding isn't a general workaround since the format string shouldn't be restricted to ANSI, unless you can smuggle the Unicode through like Takayuki showed. ---------- nosy: +eryksun versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 02:28:15 2015 From: report at bugs.python.org (Larry Hastings) Date: Mon, 23 Nov 2015 07:28:15 +0000 Subject: [issue25691] Crash on deleting Element attribute In-Reply-To: <1448125479.67.0.778631980782.issue25691@psf.upfronthosting.co.za> Message-ID: <1448263695.91.0.299251831534.issue25691@psf.upfronthosting.co.za> Larry Hastings added the comment: This change didn't make it into 3.5.1. It will be released with 3.5.2. I've already updated the Misc/NEWS entry. ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 02:28:30 2015 From: report at bugs.python.org (Larry Hastings) Date: Mon, 23 Nov 2015 07:28:30 +0000 Subject: [issue25624] shutil.make_archive makes invalid directory entries In-Reply-To: <1447493124.52.0.848319062026.issue25624@psf.upfronthosting.co.za> Message-ID: <1448263710.92.0.511257335248.issue25624@psf.upfronthosting.co.za> Larry Hastings added the comment: This change didn't make it into 3.5.1. It will be released with 3.5.2. I've already updated the Misc/NEWS entry. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 02:57:42 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 23 Nov 2015 07:57:42 +0000 Subject: [issue25688] File leak in ElementTree.iterparse() In-Reply-To: <1448104293.18.0.824435970603.issue25688@psf.upfronthosting.co.za> Message-ID: <1448265462.69.0.011933331006.issue25688@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Warning is emitted in destructor, and exceptions in destructors are ignored. Hence turning it into error makes the test passed. Tests were not correct, here is fixed patch. Yes, CleanContext does the work. But depending on it looks fragile. CleanContext can be removed after getting rid of all deprecated methods. I agree that we have to add the close() method to iterparse object. But this is new feature and separate issue. ---------- Added file: http://bugs.python.org/file41129/etree_iterparse_leak_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 03:02:35 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 23 Nov 2015 08:02:35 +0000 Subject: [issue25624] shutil.make_archive makes invalid directory entries In-Reply-To: <1447493124.52.0.848319062026.issue25624@psf.upfronthosting.co.za> Message-ID: <1448265755.14.0.204409395577.issue25624@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Larry, I think this patch is enough important to go into 3.5.1 final. It fixes a regression in common operation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 03:34:33 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 23 Nov 2015 08:34:33 +0000 Subject: [issue25698] test regressions introduced with the fix for #22995 In-Reply-To: <1448218706.46.0.334921108763.issue25698@psf.upfronthosting.co.za> Message-ID: <1448267673.18.0.836937864076.issue25698@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This can be related to issue25083. Can you look at the size of copy_reg.pyc and copy_reg.pyo files? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 03:57:11 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 23 Nov 2015 08:57:11 +0000 Subject: [issue25695] test___all__ and test_support alter execution environment In-Reply-To: <1448182737.98.0.235138945354.issue25695@psf.upfronthosting.co.za> Message-ID: <1448269031.01.0.918126143952.issue25695@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: defer-TESTDIRN.patch LGTM. ---------- nosy: +serhiy.storchaka stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 03:59:40 2015 From: report at bugs.python.org (Alecsandru Patrascu) Date: Mon, 23 Nov 2015 08:59:40 +0000 Subject: [issue25702] Link Time Optimizations support for GCC and CLANG Message-ID: <1448269180.86.0.895879966461.issue25702@psf.upfronthosting.co.za> New submission from Alecsandru Patrascu: Title: Link Time Optimizations support for GCC and CLANG Hi All, This is Alecsandru from Server Scripting Languages Optimization team at Intel Corporation. I would like to submit a patch that adds support for Link Time Optimization (LTO) when using GCC and CLANG to compile CPython2 and CPython3. LTO is a compiler assisted optimization technique that is performed by the compiler at link time. Combined with Profile Guided Optimization (PGO), enabled when running "make profile-opt", and running the Grand Unified Python Benchmark (GUPB), a speedup up to 11%, with a few regressions, was observed comparing with PGO only. Compared with a default build, a performance gain as high as 26% was observed from PGO+LTO. In addition, we are also seeing 2% boost in throughput rate from our OpenStack Swift setup comparing with PGO only. Our GUPB performance evaluation was conducted on Intel SkyLake/Broadwell systems running CentOS/Ubuntu, with CLANG/LLVM and GCC 4.*/5.*. Our OpenStack Swift performance was done on various systems consisting of XEON and Avoton processors. Steps: ====== 1. Get the CPython source codes hg clone https://hg.python.org/cpython cpython cd cpython hg update 2.7 (for CPython2) 2. Build the binary a) Default: ./configure make b) PGO: ./configure make profile-opt c) PGO+LTO: Copy the attached patch files hg import --no-commit lto-cpython3-v01.patch (for CPython3) hg import --no-commit lto-cpython2-v01.patch (for CPython2) ./configure make profile-opt Hardware and OS Configuration ============================= Hardware: Intel XEON (Broadwell-DE) 8 Cores BIOS settings: Intel Turbo Boost Technology: false Hyper-Threading: false OS: Ubuntu 14.04.3 LTS Server OS configuration: Address Space Layout Randomization (ASLR) disabled to reduce run to run variation by echo 0 > /proc/sys/kernel/randomize_va_space CPU frequency set fixed at 2.6GHz GCC version: GCC version 4.9.2 Benchmark: Grand Unified Python Benchmark from https://hg.python.org/benchmarks/ Measurements and Results ======================== A. Repository: GUPB Benchmark: hg id : 2979f5ce6a0c tip hg --debug id -i : 2979f5ce6a0cee994d5485401945d8457bb0afac CPython3: hg id : 21a28f6de358 hg id -r 'ancestors(.) and tag()': 374f501f4567 (3.5) v3.5.0 hg --debug id -i : 21a28f6de3582833652c958b8fd6ae8448b61c7c CPython2: hg id : a37ea1d56e98 (2.7) hg id -r 'ancestors(.) and tag()': 15c95b7d81dc (2.7) v2.7.10 hg --debug id -i : a37ea1d56e98eb158750d3e495a5cf524e8c3980 B. Results: CPython2 and CPython3 sample results, measured on a Broadwell platform, can be viewed in Table 1 and 2. On the first column (Benchmark) you can see the benchmark name, on the second (%D) the speedup compared with the default version and on the third column (%PGO) the speedup compared with just PGO; a higher value is better. Table 1. CPython2 results: Benchmark %D %PGO -------------------------------- raytrace 18 3 chaos 16 5 django_v2 16 6 mako 16 6 pathlib 15 3 simple_logging 15 1 slowpickle 15 5 django 14 4 go 14 4 richards 13 -1 float 12 4 slowunpickle 12 4 etree_process 11 3 fastunpickle 11 6 formatted_logging 11 3 nqueens 11 1 regex_compile 11 3 etree_iterparse 10 4 mako_v2 10 3 telco 10 5 pybench 9 1 hexiom2 9 1 html5lib_warmup 9 3 meteor_contest 9 4 pickle_list 9 5 2to3 8 2 bzr_startup 8 2 chameleon 8 0 etree_generate 8 2 regex_v8 8 3 silent_logging 8 1 fannkuch 7 1 html5lib 7 3 json_load 7 -5 tornado_http 7 3 call_method_slots 6 3 json_dump_v2 6 -4 spambayes 6 2 unpickle_list 6 0 etree_parse 5 3 fastpickle 5 4 rietveld 5 1 call_method 4 -1 normal_startup 4 2 startup_nosite 4 2 slowspitfire 3 0 ssbench 4 2 call_method_unknown 1 -6 json_dump 1 -4 nbody 1 1 pidigits 1 -10 pickle_dict 0 -1 regex_effbot 0 -2 spectral_norm 0 -3 call_simple -3 -3 unpack_sequence -6 -2 Table 2. CPython3 results: Benchmark %D %PGO -------------------------------- formatted_logging 26 11 raytrace 24 8 simple_logging 24 6 richards 22 3 chaos 21 7 go 21 11 hexiom2 21 8 nbody 21 9 etree_generate 19 5 etree_process 19 5 call_method_slots 18 3 fastunpickle 18 0 pathlib 18 5 regex_compile 18 8 float 17 8 nqueens 17 7 call_method 16 3 etree_iterparse 16 9 json_dump 16 -4 json_load 16 5 silent_logging 15 8 2to3 14 5 fannkuch 14 8 call_simple 12 0 meteor_contest 12 7 call_method_unknown 11 -1 spectral_norm 11 4 json_dump_v2 10 3 telco 10 5 fastpickle 9 -4 etree_parse 8 1 normal_startup 8 3 startup_nosite 7 3 unpack_sequence 7 3 regex_v8 6 4 unpickle_list 5 3 pickle_list 1 -10 pidigits 1 -11 regex_effbot -2 2 pickle_dict -3 -10 Thank you, Alecsandru ---------- components: Build messages: 255140 nosy: alecsandru.patrascu priority: normal severity: normal status: open title: Link Time Optimizations support for GCC and CLANG type: performance versions: Python 2.7, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 04:00:03 2015 From: report at bugs.python.org (Alecsandru Patrascu) Date: Mon, 23 Nov 2015 09:00:03 +0000 Subject: [issue25702] Link Time Optimizations support for GCC and CLANG In-Reply-To: <1448269180.86.0.895879966461.issue25702@psf.upfronthosting.co.za> Message-ID: <1448269203.44.0.578009631883.issue25702@psf.upfronthosting.co.za> Changes by Alecsandru Patrascu : ---------- keywords: +patch Added file: http://bugs.python.org/file41130/lto-cpython2-v01.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 04:00:11 2015 From: report at bugs.python.org (Alecsandru Patrascu) Date: Mon, 23 Nov 2015 09:00:11 +0000 Subject: [issue25702] Link Time Optimizations support for GCC and CLANG In-Reply-To: <1448269180.86.0.895879966461.issue25702@psf.upfronthosting.co.za> Message-ID: <1448269211.39.0.0312381471707.issue25702@psf.upfronthosting.co.za> Changes by Alecsandru Patrascu : Added file: http://bugs.python.org/file41131/lto-cpython3-v01.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 04:17:04 2015 From: report at bugs.python.org (JGoutin) Date: Mon, 23 Nov 2015 09:17:04 +0000 Subject: [issue25646] Distutils and Windows SDK 7.1 In-Reply-To: <1447756303.67.0.435034104806.issue25646@psf.upfronthosting.co.za> Message-ID: <1448270224.39.0.883711554764.issue25646@psf.upfronthosting.co.za> JGoutin added the comment: OK, I'll look that. ---------- resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 04:35:47 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 23 Nov 2015 09:35:47 +0000 Subject: [issue25703] test_sys is failed if standard stream is redirected in 2.7 Message-ID: <1448271347.53.0.201659881218.issue25703@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: When stdout or stderr (but not both) are redirected and PYTHONIOENCODING is not set, test_sys is failed in 2.7. ====================================================================== FAIL: test_43581 (test.test_sys.SysModuleTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/serhiy/py/cpython2.7-debug/Lib/test/test_sys.py", line 415, in test_43581 self.assertTrue(sys.__stdout__.encoding == sys.__stderr__.encoding) AssertionError: False is not true ---------------------------------------------------------------------- Can be reproduced by one of following commands: $ ./python -m test.regrtest -v test_sys | cat $ ./python -m test.regrtest -v test_sys 2>/dev/null Proposed patch fixes the test. ---------- assignee: serhiy.storchaka components: Tests files: test_sys_test_43581.patch keywords: patch messages: 255142 nosy: serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: test_sys is failed if standard stream is redirected in 2.7 type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file41132/test_sys_test_43581.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 04:49:27 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 23 Nov 2015 09:49:27 +0000 Subject: [issue7990] xml.etree.cElementTree lacks full dir() on Element In-Reply-To: <1266856563.54.0.534391635456.issue7990@psf.upfronthosting.co.za> Message-ID: <1448272167.74.0.985532380052.issue7990@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch updated to 3.6. ---------- nosy: +serhiy.storchaka versions: +Python 3.6 -Python 3.3, Python 3.4 Added file: http://bugs.python.org/file41133/etree_attributes.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 04:49:36 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 23 Nov 2015 09:49:36 +0000 Subject: [issue7990] xml.etree.cElementTree lacks full dir() on Element In-Reply-To: <1266856563.54.0.534391635456.issue7990@psf.upfronthosting.co.za> Message-ID: <1448272176.84.0.158188215185.issue7990@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 05:14:46 2015 From: report at bugs.python.org (Ronald Oussoren) Date: Mon, 23 Nov 2015 10:14:46 +0000 Subject: [issue25657] virtualenv's activate does not update LD_LIBRARY_PATH In-Reply-To: <1447858128.82.0.165586856524.issue25657@psf.upfronthosting.co.za> Message-ID: <1448273686.67.0.392859621514.issue25657@psf.upfronthosting.co.za> Ronald Oussoren added the comment: Hi, This appears to be a description of an issue for , not a component of CPython or its standard library. The issue tracker for virtualenv is at . ---------- nosy: +ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 05:39:49 2015 From: report at bugs.python.org (serge-sans-paille) Date: Mon, 23 Nov 2015 10:39:49 +0000 Subject: [issue25657] virtualenv's activate does not update LD_LIBRARY_PATH In-Reply-To: <1447858128.82.0.165586856524.issue25657@psf.upfronthosting.co.za> Message-ID: <1448275189.86.0.278229859917.issue25657@psf.upfronthosting.co.za> serge-sans-paille added the comment: ok, I'll report there then. Sorry for the noise :-/ ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 05:42:15 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 23 Nov 2015 10:42:15 +0000 Subject: [issue6478] time.tzset does not reset _strptime's locale time cache In-Reply-To: <1247506425.36.0.284798334504.issue6478@psf.upfronthosting.co.za> Message-ID: <1448275335.66.0.447369778962.issue6478@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I forgot about this issue and proposed similar patch for issue25168. It doesn't recalculate timezone values (a tuple of frozensets) on every _strptime call, but uses cheaper tests for time.tzname and time.daylight. issue6478_v3.diff has a bug, it doesn't clear _regex_cache after changing _TimeRE_cache. And I doubt that after fixing this the benefit of not recreating the entire _TimeRE_cache will be worth the complication of the code. Looks as this bug is a cause of random order depending tests failure (issue22067). ---------- stage: needs patch -> patch review versions: +Python 3.5, Python 3.6 -Python 3.3 Added file: http://bugs.python.org/file41134/strptime_cache_timezone.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 06:16:59 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 23 Nov 2015 11:16:59 +0000 Subject: [issue25688] File leak in ElementTree.iterparse() In-Reply-To: <1448104293.18.0.824435970603.issue25688@psf.upfronthosting.co.za> Message-ID: <1448277419.27.0.330700242818.issue25688@psf.upfronthosting.co.za> Martin Panter added the comment: Patch 2 looks good. I like the new version of the tests better. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 06:36:30 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 23 Nov 2015 11:36:30 +0000 Subject: [issue25702] Link Time Optimizations support for GCC and CLANG In-Reply-To: <1448269180.86.0.895879966461.issue25702@psf.upfronthosting.co.za> Message-ID: <1448278590.1.0.658058166016.issue25702@psf.upfronthosting.co.za> Antoine Pitrou added the comment: LTO only exists on recent versions of gcc, so the configure script should probably do some version checking. Also we can't enable it by default as 1) it makes compile times much longer 2) there are some bugs in some gcc versions (see e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753134). ---------- nosy: +pitrou stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 06:40:48 2015 From: report at bugs.python.org (Michael Foord) Date: Mon, 23 Nov 2015 11:40:48 +0000 Subject: [issue25669] unittest.assertEqual() on un-equal types inheriting from collections.Mapping In-Reply-To: <1447945164.43.0.781001179378.issue25669@psf.upfronthosting.co.za> Message-ID: <1448278848.92.0.789025622452.issue25669@psf.upfronthosting.co.za> Michael Foord added the comment: assertEqual *does* do type checking and it's strict that it will only resort to the "type specific" assert checks if both types are of the same type. In the general case it's impossible to know whether comparing a subclass with the type specific check is the right thing to do - so unittest doesn't guess. As you have a simple workaround ( dict(foo) ) I'm closing this. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 07:18:48 2015 From: report at bugs.python.org (Alecsandru Patrascu) Date: Mon, 23 Nov 2015 12:18:48 +0000 Subject: [issue25702] Link Time Optimizations support for GCC and CLANG In-Reply-To: <1448269180.86.0.895879966461.issue25702@psf.upfronthosting.co.za> Message-ID: <1448281128.84.0.0891852869857.issue25702@psf.upfronthosting.co.za> Alecsandru Patrascu added the comment: LTO exists in GCC since version 4.5, but it is true that only recent versions (>=4.8) perform it in good conditions. It is not enabled by default in this patch, it is only available when building with PGO support. Running just "make" will not activate the LTO flags. Do you see it as an configure option (using, for example, an explicit --with-lto flag) rather than using it automatically? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 07:33:54 2015 From: report at bugs.python.org (Eli Bendersky) Date: Mon, 23 Nov 2015 12:33:54 +0000 Subject: [issue25455] Some repr implementations don't check for self-referential structures In-Reply-To: <1445455038.6.0.824380060049.issue25455@psf.upfronthosting.co.za> Message-ID: <1448282034.78.0.302050261487.issue25455@psf.upfronthosting.co.za> Changes by Eli Bendersky : ---------- nosy: -eli.bendersky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 07:48:24 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Mon, 23 Nov 2015 12:48:24 +0000 Subject: [issue25704] Update the documentation to 3.5 Message-ID: <1448282904.47.0.71490462116.issue25704@psf.upfronthosting.co.za> Changes by St?phane Wirtel : ---------- components: Devguide nosy: ezio.melotti, matrixise, willingc priority: normal severity: normal status: open title: Update the documentation to 3.5 versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 07:49:46 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Mon, 23 Nov 2015 12:49:46 +0000 Subject: [issue25704] Update the documentation to 3.5 Message-ID: <1448282986.29.0.990424693558.issue25704@psf.upfronthosting.co.za> New submission from St?phane Wirtel: In this patch, I have updated the version of Python, from 3.4 to 3.5. And added Ned Deily in the Release Manager for 3.6. ---------- keywords: +patch Added file: http://bugs.python.org/file41135/issue25704.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 08:05:25 2015 From: report at bugs.python.org (Florin Papa) Date: Mon, 23 Nov 2015 13:05:25 +0000 Subject: [issue25705] Fix regex_compile benchmark crash Message-ID: <1448283925.8.0.456132903966.issue25705@psf.upfronthosting.co.za> New submission from Florin Papa: Hi all, This is Florin Papa from the Server Languages Optimizations Team at Intel Corporation. The patch submitted here solves a crash occurring on Python 2.7 and 3.6 when running the regex_compile benchmark. The clear_cache() call was replaced with re.purge(). To apply the patch please follow these steps: hg clone https://hg.python.org/benchmarks cd benchmarks/ copy fix_regex_compile.patch to the current directory hg import --no-commit fix_regex_compile.patch Thank you, Florin Papa ---------- components: Benchmarks files: fix_regex_compile.patch keywords: patch messages: 255152 nosy: brett.cannon, florin.papa, pitrou priority: normal severity: normal status: open title: Fix regex_compile benchmark crash type: crash versions: Python 2.7, Python 3.6 Added file: http://bugs.python.org/file41136/fix_regex_compile.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 08:16:33 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Mon, 23 Nov 2015 13:16:33 +0000 Subject: [issue19316] devguide: compiler - wording In-Reply-To: <1382272126.03.0.859419260116.issue19316@psf.upfronthosting.co.za> Message-ID: <1448284593.88.0.70642003179.issue19316@psf.upfronthosting.co.za> St?phane Wirtel added the comment: Hi everybody, Here is a new version of the script for the last version of the devguide. 198554fa82c2 Please review and apply. ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 08:21:12 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 23 Nov 2015 13:21:12 +0000 Subject: [issue23914] pickle fails with SystemError In-Reply-To: <1428756762.72.0.925495036586.issue23914@psf.upfronthosting.co.za> Message-ID: <20151123132109.9722.88480@psf.io> Roundup Robot added the comment: New changeset bac3f63ea747 by Serhiy Storchaka in branch '3.4': Issue #23914: Fixed SystemError raised by unpickler on broken pickle data. https://hg.python.org/cpython/rev/bac3f63ea747 New changeset 531e2674f003 by Serhiy Storchaka in branch '3.5': Issue #23914: Fixed SystemError raised by unpickler on broken pickle data. https://hg.python.org/cpython/rev/531e2674f003 New changeset b08c3a733fda by Serhiy Storchaka in branch 'default': Issue #23914: Fixed SystemError raised by unpickler on broken pickle data. https://hg.python.org/cpython/rev/b08c3a733fda New changeset 686fa9439d38 by Serhiy Storchaka in branch '2.7': Issue #23914: Fixed SystemError raised by unpickler on broken pickle data. https://hg.python.org/cpython/rev/686fa9439d38 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 08:29:19 2015 From: report at bugs.python.org (hiroaki itoh) Date: Mon, 23 Nov 2015 13:29:19 +0000 Subject: [issue25706] problems in library/base64.rst Message-ID: <1448285359.37.0.0735251263176.issue25706@psf.upfronthosting.co.za> New submission from hiroaki itoh: * default of ignorechars for a85decode b' tnrv' should be b' \t\n\r\v' * explanation of newline for a85encode "newline('n')" should be "newline('\n')" ---------- assignee: docs at python components: Documentation messages: 255155 nosy: docs at python, xwhhsprings priority: normal severity: normal status: open title: problems in library/base64.rst versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 08:32:50 2015 From: report at bugs.python.org (hiroaki itoh) Date: Mon, 23 Nov 2015 13:32:50 +0000 Subject: [issue25706] problems in library/base64.rst In-Reply-To: <1448285359.37.0.0735251263176.issue25706@psf.upfronthosting.co.za> Message-ID: <1448285570.5.0.782774103901.issue25706@psf.upfronthosting.co.za> Changes by hiroaki itoh : ---------- versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 08:33:15 2015 From: report at bugs.python.org (hiroaki itoh) Date: Mon, 23 Nov 2015 13:33:15 +0000 Subject: [issue25706] problems in library/base64.rst In-Reply-To: <1448285359.37.0.0735251263176.issue25706@psf.upfronthosting.co.za> Message-ID: <1448285595.25.0.300220638133.issue25706@psf.upfronthosting.co.za> Changes by hiroaki itoh : ---------- versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 08:36:31 2015 From: report at bugs.python.org (hiroaki itoh) Date: Mon, 23 Nov 2015 13:36:31 +0000 Subject: [issue25706] problems in library/base64.rst In-Reply-To: <1448285359.37.0.0735251263176.issue25706@psf.upfronthosting.co.za> Message-ID: <1448285791.24.0.932384737348.issue25706@psf.upfronthosting.co.za> hiroaki itoh added the comment: maybe this is Sphinx bug. rst has no problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 08:47:11 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 23 Nov 2015 13:47:11 +0000 Subject: [issue25688] File leak in ElementTree.iterparse() In-Reply-To: <1448104293.18.0.824435970603.issue25688@psf.upfronthosting.co.za> Message-ID: <20151123134704.130871.22862@psf.io> Roundup Robot added the comment: New changeset 6e23777948f3 by Serhiy Storchaka in branch '3.4': Issue #25688: Fixed file leak in ElementTree.iterparse() raising an error. https://hg.python.org/cpython/rev/6e23777948f3 New changeset 267d04459ba3 by Serhiy Storchaka in branch '3.5': Issue #25688: Fixed file leak in ElementTree.iterparse() raising an error. https://hg.python.org/cpython/rev/267d04459ba3 New changeset d841205776fe by Serhiy Storchaka in branch 'default': Issue #25688: Fixed file leak in ElementTree.iterparse() raising an error. https://hg.python.org/cpython/rev/d841205776fe New changeset 09a8ac75b351 by Serhiy Storchaka in branch '2.7': Issue #25688: Fixed file leak in ElementTree.iterparse() raising an error. https://hg.python.org/cpython/rev/09a8ac75b351 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 08:49:36 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 23 Nov 2015 13:49:36 +0000 Subject: [issue25706] problems in library/base64.rst In-Reply-To: <1448285359.37.0.0735251263176.issue25706@psf.upfronthosting.co.za> Message-ID: <1448286576.19.0.151141842639.issue25706@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: docs at python -> serhiy.storchaka nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 08:51:44 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Mon, 23 Nov 2015 13:51:44 +0000 Subject: [issue25706] problems in library/base64.rst In-Reply-To: <1448286576.19.0.151141842639.issue25706@psf.upfronthosting.co.za> Message-ID: <20151123135141.GA25726@sg1> St?phane Wirtel added the comment: Who can explain the problem ? I am ignorant about this issue. ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 08:57:25 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 23 Nov 2015 13:57:25 +0000 Subject: [issue25707] Add the close method for ElementTree.iterparse() object Message-ID: <1448287045.22.0.0931965485798.issue25707@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: If ElementTree.iterparse() is called with file names, it opens a file. When resulting iterator is not exhausted, the file lefts not closed. >>> import xml.etree.ElementTree as ET >>> import gc >>> ET.iterparse('/dev/null') >>> gc.collect() __main__:1: ResourceWarning: unclosed file <_io.BufferedReader name='/dev/null'> 34 Martin Panter proposed in issue25688 to add an explicit way to clean it up, like a generator.close() method. ---------- assignee: serhiy.storchaka components: Library (Lib) messages: 255159 nosy: serhiy.storchaka priority: normal severity: normal stage: needs patch status: open title: Add the close method for ElementTree.iterparse() object type: resource usage versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 08:58:32 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 23 Nov 2015 13:58:32 +0000 Subject: [issue25688] File leak in ElementTree.iterparse() In-Reply-To: <1448104293.18.0.824435970603.issue25688@psf.upfronthosting.co.za> Message-ID: <1448287112.27.0.660463898131.issue25688@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your review Martin. Opened issue25707 for adding the close method. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 09:07:19 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Mon, 23 Nov 2015 14:07:19 +0000 Subject: [issue4744] asynchat documentation needs to be more precise In-Reply-To: <1448229202.17.0.607837184501.issue4744@psf.upfronthosting.co.za> Message-ID: <20151123140716.GB15060@sg1> St?phane Wirtel added the comment: Hi Martin, About the patch of Nikita, I am going to rewrite it asap. Will you have time to check it ? Thanks -- St?phane Wirtel - http://wirtel.be - @matrixise ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 09:11:55 2015 From: report at bugs.python.org (hiroaki itoh) Date: Mon, 23 Nov 2015 14:11:55 +0000 Subject: [issue25706] problems in library/base64.rst In-Reply-To: <1448285359.37.0.0735251263176.issue25706@psf.upfronthosting.co.za> Message-ID: <1448287915.46.0.153027430279.issue25706@psf.upfronthosting.co.za> hiroaki itoh added the comment: Should be escape by '\\t\\b...' in rst? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 09:15:15 2015 From: report at bugs.python.org (hiroaki itoh) Date: Mon, 23 Nov 2015 14:15:15 +0000 Subject: [issue25706] problems in library/base64.rst In-Reply-To: <1448285359.37.0.0735251263176.issue25706@psf.upfronthosting.co.za> Message-ID: <1448288115.35.0.573402145675.issue25706@psf.upfronthosting.co.za> hiroaki itoh added the comment: escape*d* ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 09:17:12 2015 From: report at bugs.python.org (Emanuel Barry) Date: Mon, 23 Nov 2015 14:17:12 +0000 Subject: [issue25707] Add the close method for ElementTree.iterparse() object In-Reply-To: <1448287045.22.0.0931965485798.issue25707@psf.upfronthosting.co.za> Message-ID: <1448288232.73.0.618998054191.issue25707@psf.upfronthosting.co.za> Emanuel Barry added the comment: I am unable to reproduce the issue on Windows 7 with 3.5.0; I have tried opening a small (non-empty) text. Here's the result: >>> import xml.etree.ElementTree as ET >>> import gc >>> ET.iterparse("E:/New.txt") >>> gc.collect() 59 ---------- nosy: +ebarry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 09:25:45 2015 From: report at bugs.python.org (Zachary Ware) Date: Mon, 23 Nov 2015 14:25:45 +0000 Subject: [issue25704] Update the devguide to 3.5 In-Reply-To: <1448282986.29.0.990424693558.issue25704@psf.upfronthosting.co.za> Message-ID: <1448288745.02.0.343757771945.issue25704@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- title: Update the documentation to 3.5 -> Update the devguide to 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 09:44:11 2015 From: report at bugs.python.org (Alecsandru Patrascu) Date: Mon, 23 Nov 2015 14:44:11 +0000 Subject: [issue25702] Link Time Optimizations support for GCC and CLANG In-Reply-To: <1448269180.86.0.895879966461.issue25702@psf.upfronthosting.co.za> Message-ID: <1448289851.11.0.0853486556478.issue25702@psf.upfronthosting.co.za> Alecsandru Patrascu added the comment: Meanwhile I've added the patches (v02) for LTO enabled only if the "./configure --with-lto" command is issued. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 09:44:20 2015 From: report at bugs.python.org (Alecsandru Patrascu) Date: Mon, 23 Nov 2015 14:44:20 +0000 Subject: [issue25702] Link Time Optimizations support for GCC and CLANG In-Reply-To: <1448269180.86.0.895879966461.issue25702@psf.upfronthosting.co.za> Message-ID: <1448289860.16.0.454161106762.issue25702@psf.upfronthosting.co.za> Changes by Alecsandru Patrascu : Added file: http://bugs.python.org/file41137/lto-cpython2-v02.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 09:44:27 2015 From: report at bugs.python.org (Alecsandru Patrascu) Date: Mon, 23 Nov 2015 14:44:27 +0000 Subject: [issue25702] Link Time Optimizations support for GCC and CLANG In-Reply-To: <1448269180.86.0.895879966461.issue25702@psf.upfronthosting.co.za> Message-ID: <1448289867.55.0.309314113945.issue25702@psf.upfronthosting.co.za> Changes by Alecsandru Patrascu : Added file: http://bugs.python.org/file41138/lto-cpython3-v02.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 09:46:15 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 23 Nov 2015 14:46:15 +0000 Subject: [issue25706] problems in library/base64.rst In-Reply-To: <1448285359.37.0.0735251263176.issue25706@psf.upfronthosting.co.za> Message-ID: <20151123144612.3550.38341@psf.io> Roundup Robot added the comment: New changeset a33d76465a18 by Serhiy Storchaka in branch '3.4': Issue #25706: Fixed markup in the documentation. https://hg.python.org/cpython/rev/a33d76465a18 New changeset f4918e98d085 by Serhiy Storchaka in branch '3.5': Issue #25706: Fixed markup in the documentation. https://hg.python.org/cpython/rev/f4918e98d085 New changeset ebec1a98ab81 by Serhiy Storchaka in branch 'default': Issue #25706: Fixed markup in the documentation. https://hg.python.org/cpython/rev/ebec1a98ab81 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 09:46:20 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 23 Nov 2015 14:46:20 +0000 Subject: [issue25702] Link Time Optimizations support for GCC and CLANG In-Reply-To: <1448281128.84.0.0891852869857.issue25702@psf.upfronthosting.co.za> Message-ID: <565326B8.1090909@free.fr> Antoine Pitrou added the comment: Le 23/11/2015 13:18, Alecsandru Patrascu a ?crit : > > Do you see it as an configure option (using, for example, an > explicit --with-lto flag) rather than using it automatically? That would be nice. This way people can easily test different combinations of flags. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 09:47:04 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 23 Nov 2015 14:47:04 +0000 Subject: [issue25702] Link Time Optimizations support for GCC and CLANG In-Reply-To: <1448289851.11.0.0853486556478.issue25702@psf.upfronthosting.co.za> Message-ID: <565326E6.7070807@free.fr> Antoine Pitrou added the comment: Le 23/11/2015 15:44, Alecsandru Patrascu a ?crit : > > Meanwhile I've added the patches (v02) for LTO enabled only if the "./configure --with-lto" command is issued. Cool, thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 09:49:24 2015 From: report at bugs.python.org (Cal Leeming) Date: Mon, 23 Nov 2015 14:49:24 +0000 Subject: [issue25708] runpy hides traceback for some exceptions Message-ID: <1448290164.96.0.435205932558.issue25708@psf.upfronthosting.co.za> New submission from Cal Leeming: Originally posted here: http://stackoverflow.com/q/33873243/1267398 The problem is caused by this line: # For -m switch, just display the exception info = str(exc) Caused by the following commit in 2008; https://mail.python.org/pipermail/python-checkins/2008-February/066256.html The commit states; "Try to make command line error messages from runpy easier to understand (and suppress traceback cruft from the implicitly invoked runpy machinery)" However by suppressing the traceback it's now impossible to debug what caused the error when running with `runpy` without wrapping the entire `__init__.py` with your own try/except statement. I'd like to propose either displaying the full traceback by default, or adding a CLI option to enable it at runtime. The fact that it only suppresses *some* tracebacks and not all is a flawed approach surely? Thoughts? ---------- components: Interpreter Core messages: 255169 nosy: ncoghlan, sleepycal priority: normal severity: normal status: open title: runpy hides traceback for some exceptions type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 09:54:09 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 23 Nov 2015 14:54:09 +0000 Subject: [issue25706] problems in library/base64.rst In-Reply-To: <1448285359.37.0.0735251263176.issue25706@psf.upfronthosting.co.za> Message-ID: <1448290449.34.0.0105312799202.issue25706@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your report hiroaki itoh. Fixed yet one error in Doc/library/stdtypes.rst. St?phane, the backslash hes special meaning in rst files if not escaped. ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 09:56:23 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 23 Nov 2015 14:56:23 +0000 Subject: [issue25707] Add the close method for ElementTree.iterparse() object In-Reply-To: <1448287045.22.0.0931965485798.issue25707@psf.upfronthosting.co.za> Message-ID: <1448290583.48.0.422177538881.issue25707@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: You have to enable deprecation warnings. Run the interpreter with the -Wa option. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 09:57:19 2015 From: report at bugs.python.org (=?utf-8?b?w4FycMOhZCBLw7NzYQ==?=) Date: Mon, 23 Nov 2015 14:57:19 +0000 Subject: [issue25709] greek alphabet bug it is very disturbing... Message-ID: <1448290639.34.0.0738045056565.issue25709@psf.upfronthosting.co.za> New submission from ?rp?d K?sa: One of my students found this bug. For ascii characters it works as you expect, but for greek alphabet it works unexpectedly. The program works correctly for Python 3.2.x but for 3.4.x and 3.5 it gives erroneous result. ---------- files: greekbug.py messages: 255172 nosy: ?rp?d K?sa priority: normal severity: normal status: open title: greek alphabet bug it is very disturbing... type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file41139/greekbug.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 10:08:12 2015 From: report at bugs.python.org (Emanuel Barry) Date: Mon, 23 Nov 2015 15:08:12 +0000 Subject: [issue25707] Add the close method for ElementTree.iterparse() object In-Reply-To: <1448287045.22.0.0931965485798.issue25707@psf.upfronthosting.co.za> Message-ID: <1448291292.6.0.859632518868.issue25707@psf.upfronthosting.co.za> Emanuel Barry added the comment: Oh, my bad. Ignore my last message, behaviour is identical then. Thanks for clearing that up. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 10:13:59 2015 From: report at bugs.python.org (Stefan Krah) Date: Mon, 23 Nov 2015 15:13:59 +0000 Subject: [issue25455] Some repr implementations don't check for self-referential structures In-Reply-To: <1445455038.6.0.824380060049.issue25455@psf.upfronthosting.co.za> Message-ID: <1448291639.58.0.714944546004.issue25455@psf.upfronthosting.co.za> Stefan Krah added the comment: I think you may have meant Eli Bendersky -- I'm not an elementree expert (Eli, I'm adding you back just to clear this up). ---------- nosy: +eli.bendersky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 10:14:16 2015 From: report at bugs.python.org (Steven D'Aprano) Date: Mon, 23 Nov 2015 15:14:16 +0000 Subject: [issue25709] greek alphabet bug it is very disturbing... In-Reply-To: <1448290639.34.0.0738045056565.issue25709@psf.upfronthosting.co.za> Message-ID: <1448291656.64.0.310551761547.issue25709@psf.upfronthosting.co.za> Steven D'Aprano added the comment: I'm afraid I'm unable to replicate this bug report in Python 3.4. If you are able to replicate it, can you tell us the exact version number of Python you are using? Also, which operating system are you using? ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 10:24:50 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Mon, 23 Nov 2015 15:24:50 +0000 Subject: [issue25706] problems in library/base64.rst In-Reply-To: <1448290449.34.0.0105312799202.issue25706@psf.upfronthosting.co.za> Message-ID: <20151123152447.GC15060@sg1> St?phane Wirtel added the comment: Thanks for your explanation, Serhiy. Now, I know how to fix this kind of issues. On 11/23, Serhiy Storchaka wrote: > > Serhiy Storchaka added the comment: > > Thank you for your report hiroaki itoh. Fixed yet one error in Doc/library/stdtypes.rst. > > St?phane, the backslash hes special meaning in rst files if not escaped. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 10:30:04 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 23 Nov 2015 15:30:04 +0000 Subject: [issue25709] greek alphabet bug it is very disturbing... In-Reply-To: <1448290639.34.0.0738045056565.issue25709@psf.upfronthosting.co.za> Message-ID: <1448292604.61.0.0604380359725.issue25709@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Confirmed on IDLE. >>> s = '' >>> for i in range(5): s += '\xe0' print(s) ? ?? ?? ?? ?? >>> s = '' >>> for i in range(5): s += chr(0xe0) print(s) ? ?? ?? ?? ?? >>> s = '' >>> for i in range(5): s += '\u0107' print(s) ? ?? ?? ?? ?? >>> s = '' >>> for i in range(5): s += chr(0x107) print(s) ? ? ? ? ? This issue can be related to details of IDLE's standard streams and RPC. ---------- assignee: -> serhiy.storchaka components: +IDLE nosy: +kbk, roger.serwy, serhiy.storchaka, terry.reedy versions: +Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 10:44:56 2015 From: report at bugs.python.org (Robert Byrnes) Date: Mon, 23 Nov 2015 15:44:56 +0000 Subject: [issue25710] zipimport is not PEP 3147 or PEP 488 compliant Message-ID: <1448293496.52.0.845434990633.issue25710@psf.upfronthosting.co.za> New submission from Robert Byrnes: zipimport is not PEP 3147 compliant: i.e., it looks for foo.pyc (in the same directory as foo.py) instead of __pycache__/foo.cpython-35.pyc. This is counterintuitive, and unfortunate because it means that installation directories (that obey PEP 3147 conventions) can't be zip archived from filesystems and then used by zipimport. When support for PEP 488 was added to Python 3.5, zipimport was modified to just delete references to .pyo files, but it needs to know about the new .opt-[12] filename components (as well as the PEP 3147 version tags). As far as I can tell, the current version of zipimport can't import optimized bytecode files, using either the old or new filename conventions. Finally, none of this behavior is documented. The zipimport docs still mention .pyo files (which were eliminated by PEP 488), and say nothing about the filename conventions expected within zip archives. ---------- components: Extension Modules messages: 255178 nosy: byrnes priority: normal severity: normal status: open title: zipimport is not PEP 3147 or PEP 488 compliant type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 10:50:56 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 23 Nov 2015 15:50:56 +0000 Subject: [issue25704] Update the devguide to 3.5 In-Reply-To: <1448282986.29.0.990424693558.issue25704@psf.upfronthosting.co.za> Message-ID: <1448293856.83.0.945464181447.issue25704@psf.upfronthosting.co.za> Berker Peksag added the comment: I don't think most of the version numbers are very important here and I wouldn't change them unless there is a valid reason. > -3.4 and 3.5, first fix it in ``3.4`` and then merge ``3.4`` into ``default`` > -(which holds the future 3.5). > +3.5 and 3.6, first fix it in ``3.5`` and then merge ``3.6`` into ``default`` > +(which holds the future 3.6). This change looks wrong to me. In the original text, 3.4 and default are branch names. There won't be a branch named 3.6 until late 2016. > -For versions 3.4 and before, this was conventionally done when the final > -release was cut (for example, 3.4.0 final). > +For versions 3.5 and before, this was conventionally done when the final > +release was cut (for example, 3.5.0 final). This also looks wrong to me. I'm +1 to commit the following changes in devcycle.rst: > -There are 5 open branches right now in the Mercurial repository: > +There are 6 open branches right now in the Mercurial repository: > -- the ``default`` branch holds the future 3.5 version and descends from ``3.4`` > - (RM: Larry Hastings) > +- the ``default`` branch holds the future 3.6 version and descends from ``3.5`` > + (RM: Ned Deily) > +- the ``3.5`` branch holds bug fixes for future 3.5.x maintenance releases > + and descends from ``3.4`` (RM: Larry Hastings) It might also worth to update the build-dep command in setup.rst. ---------- nosy: +berker.peksag stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 10:51:36 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 23 Nov 2015 15:51:36 +0000 Subject: [issue25704] Update the devguide to 3.5 In-Reply-To: <1448282986.29.0.990424693558.issue25704@psf.upfronthosting.co.za> Message-ID: <1448293896.56.0.479371784338.issue25704@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- versions: -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 10:51:42 2015 From: report at bugs.python.org (Mark Lawrence) Date: Mon, 23 Nov 2015 15:51:42 +0000 Subject: [issue4744] asynchat documentation needs to be more precise In-Reply-To: <1230168171.56.0.381937953807.issue4744@psf.upfronthosting.co.za> Message-ID: <1448293902.48.0.524163905655.issue4744@psf.upfronthosting.co.za> Mark Lawrence added the comment: Does it make sense to spend time updating the asychat docs when https://docs.python.org/3/library/asynchat.html states "Note. This module exists for backwards compatibility only. For new code we recommend using asyncio."? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 10:52:03 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 23 Nov 2015 15:52:03 +0000 Subject: [issue25710] zipimport is not PEP 3147 or PEP 488 compliant In-Reply-To: <1448293496.52.0.845434990633.issue25710@psf.upfronthosting.co.za> Message-ID: <1448293923.29.0.387504872181.issue25710@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +brett.cannon, eric.snow, ncoghlan, serhiy.storchaka, twouters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 10:54:09 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 23 Nov 2015 15:54:09 +0000 Subject: [issue23914] pickle fails with SystemError In-Reply-To: <1428756762.72.0.925495036586.issue23914@psf.upfronthosting.co.za> Message-ID: <1448294049.03.0.605692063722.issue23914@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 11:25:45 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 23 Nov 2015 16:25:45 +0000 Subject: [issue25660] tabs don't work correctly in python repl In-Reply-To: <1447876730.91.0.918964104484.issue25660@psf.upfronthosting.co.za> Message-ID: <1448295945.7.0.647268657622.issue25660@psf.upfronthosting.co.za> R. David Murray added the comment: The thing is, when it is a regression it should be fixed before the release is issued, even if it is a more "minor" issue. Otherwise, especially in a x.y.1 release, we look pretty bad. However, this one had been broken in the field so long that rule doesn't really apply, I think :) At least it is better in 3.5 and only affects one platform now, instead of all of them. If people didn't have time to get it fixed and committed before your deadline, that's too bad, I'm afraid :(. David Beazly is going to be pissed, though... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 11:28:28 2015 From: report at bugs.python.org (Eli Bendersky) Date: Mon, 23 Nov 2015 16:28:28 +0000 Subject: [issue25455] Some repr implementations don't check for self-referential structures In-Reply-To: <1445455038.6.0.824380060049.issue25455@psf.upfronthosting.co.za> Message-ID: <1448296108.75.0.756202772575.issue25455@psf.upfronthosting.co.za> Eli Bendersky added the comment: As I've mentioned elsewhere, I'll have to temporarily take myself off these issues as I don't have the time to work on them (even review patches). I think Raymond may have gotten his Stefans mixed up and meant Stefan Behnel, who's also been looking at etree patches. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 11:28:40 2015 From: report at bugs.python.org (Brett Cannon) Date: Mon, 23 Nov 2015 16:28:40 +0000 Subject: [issue25711] Rewrite zipimport from scratch Message-ID: <1448296120.48.0.872112518039.issue25711@psf.upfronthosting.co.za> New submission from Brett Cannon: No one wants to work on zipimport, and yet it's full of bugs. It needs a rewrite so that it's more maintainable. An idea floated at PyCon 2015 was to writing the zip-reading code in C and to keep it as simple as possible -- e.g., don't worry about supporting comments, etc. -- and then write the rest of the code in importlib, making maintenance much easier. All of the various zipimport bugs should be made dependent on this issue as unless they are critical flaws I doubt they will get fixed without the rewrite. ---------- components: Interpreter Core messages: 255183 nosy: brett.cannon, gregory.p.smith, twouters priority: high severity: normal status: open title: Rewrite zipimport from scratch versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 11:28:44 2015 From: report at bugs.python.org (Eli Bendersky) Date: Mon, 23 Nov 2015 16:28:44 +0000 Subject: [issue25455] Some repr implementations don't check for self-referential structures In-Reply-To: <1445455038.6.0.824380060049.issue25455@psf.upfronthosting.co.za> Message-ID: <1448296124.08.0.434785274627.issue25455@psf.upfronthosting.co.za> Changes by Eli Bendersky : ---------- nosy: -eli.bendersky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 11:29:06 2015 From: report at bugs.python.org (Brett Cannon) Date: Mon, 23 Nov 2015 16:29:06 +0000 Subject: [issue25710] zipimport is not PEP 3147 or PEP 488 compliant In-Reply-To: <1448293496.52.0.845434990633.issue25710@psf.upfronthosting.co.za> Message-ID: <1448296146.74.0.298577887221.issue25710@psf.upfronthosting.co.za> Brett Cannon added the comment: Not finding bytecode files is not that big of a deal. While it's a very minor performance loss, it isn't critical to how Python works (and since it looks for bytecode-only files that use-case isn't broken either). But the real problem is that zipimport is such a nasty chunk of code that no one wants to fix it. Yet more evidence we just need to rewrite the whole module. I created issue #25711 to track a rewrite. ---------- dependencies: +Rewrite zipimport from scratch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 11:29:34 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 23 Nov 2015 16:29:34 +0000 Subject: [issue25694] test.libregrtest not installed In-Reply-To: <1448182149.01.0.175316940428.issue25694@psf.upfronthosting.co.za> Message-ID: <1448296174.71.0.542976639436.issue25694@psf.upfronthosting.co.za> R. David Murray added the comment: It used to be there were also changes that needed to be made to the windows build files when a new directory was added. Nosying Steve in case this is still true, assuming there is an option to install the tests (which there might not be, I have no idea not being a Windows user). ---------- nosy: +r.david.murray, steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 11:30:59 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Mon, 23 Nov 2015 16:30:59 +0000 Subject: [issue25704] Update the devguide to 3.5 In-Reply-To: <1448293856.83.0.945464181447.issue25704@psf.upfronthosting.co.za> Message-ID: <20151123163056.GD15060@sg1> St?phane Wirtel added the comment: Hi Berker, Thank you for your review, > I don't think most of the version numbers are very important here and I wouldn't change them unless there is a valid reason. My first opinion when I have read the documentation was "but this doc is out of date". It's my reason, for me, it's valid. In fact, that was not for the pleasure to change some numbers, but to reflect the reality. > > > -3.4 and 3.5, first fix it in ``3.4`` and then merge ``3.4`` into ``default`` > > -(which holds the future 3.5). > > +3.5 and 3.6, first fix it in ``3.5`` and then merge ``3.6`` into ``default`` > > +(which holds the future 3.6). > > This change looks wrong to me. In the original text, 3.4 and default > are branch names. There won't be a branch named 3.6 until late 2016. What do you suggest in this case? > > > -For versions 3.4 and before, this was conventionally done when the final > > -release was cut (for example, 3.4.0 final). > > +For versions 3.5 and before, this was conventionally done when the final > > +release was cut (for example, 3.5.0 final). > > This also looks wrong to me. Ok > > I'm +1 to commit the following changes in devcycle.rst: > > > -There are 5 open branches right now in the Mercurial repository: > > +There are 6 open branches right now in the Mercurial repository: > > > -- the ``default`` branch holds the future 3.5 version and descends from ``3.4`` > > - (RM: Larry Hastings) > > +- the ``default`` branch holds the future 3.6 version and descends from ``3.5`` > > + (RM: Ned Deily) > > +- the ``3.5`` branch holds bug fixes for future 3.5.x maintenance releases > > + and descends from ``3.4`` (RM: Larry Hastings) > > It might also worth to update the build-dep command in setup.rst. I agree, I am going to check that What do you suggest for this patch? Update my patch with the right paragraphes ? Tell me, Thank you ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 11:34:56 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 23 Nov 2015 16:34:56 +0000 Subject: [issue4744] asynchat documentation needs to be more precise In-Reply-To: <1230168171.56.0.381937953807.issue4744@psf.upfronthosting.co.za> Message-ID: <1448296496.11.0.352337152221.issue4744@psf.upfronthosting.co.za> R. David Murray added the comment: Yes. The docs should be accurate, even if the module is deprecated. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 11:36:10 2015 From: report at bugs.python.org (Robert Byrnes) Date: Mon, 23 Nov 2015 16:36:10 +0000 Subject: [issue25711] Rewrite zipimport from scratch In-Reply-To: <1448296120.48.0.872112518039.issue25711@psf.upfronthosting.co.za> Message-ID: <1448296570.01.0.648881713741.issue25711@psf.upfronthosting.co.za> Changes by Robert Byrnes : ---------- nosy: +byrnes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 11:38:16 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Mon, 23 Nov 2015 16:38:16 +0000 Subject: [issue4744] asynchat documentation needs to be more precise In-Reply-To: <1448296496.11.0.352337152221.issue4744@psf.upfronthosting.co.za> Message-ID: <20151123163814.GE15060@sg1> St?phane Wirtel added the comment: Ok, in this case, I will provide the patch On 11/23, R. David Murray wrote: > > R. David Murray added the comment: > > Yes. The docs should be accurate, even if the module is deprecated. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > _______________________________________________ > Python-bugs-list mailing list > Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/stephane%40wirtel.be > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 11:40:36 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Mon, 23 Nov 2015 16:40:36 +0000 Subject: [issue25712] Dead link in the PEP-3147 Message-ID: <20151123164034.GF15060@sg1> New submission from St?phane Wirtel: In the PEP-3147, there is a link to the marshal library. The link is dead because we get a 404 HTTP error. https://www.python.org/dev/peps/pep-3147/ The link is [2] : https://www.python.org/doc/current/library/marshal.html but the link gives a 404 ---------- messages: 255189 nosy: matrixise priority: normal severity: normal status: open title: Dead link in the PEP-3147 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 11:44:54 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 23 Nov 2015 16:44:54 +0000 Subject: [issue25697] Fix rough alphabetical order in Misc/ACKS In-Reply-To: <1448207088.07.0.222703830715.issue25697@psf.upfronthosting.co.za> Message-ID: <1448297094.45.0.206873826506.issue25697@psf.upfronthosting.co.za> R. David Murray added the comment: It says "rough" for a reason. The ascii-only changes are probably fine, but the non-ascii ones may not be (MvL in particular caught my eye, but there was another) may be correct as they stand since those two were consistent (at the end of the alphabet). I don't know, though; I don't know the alphabetization rules for the non-ascii names. In short, it is better to leave the non-ascii names alone unless you are sure of the sorting rules of the native language of the individual involved :) ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 11:52:01 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Mon, 23 Nov 2015 16:52:01 +0000 Subject: [issue4744] asynchat documentation needs to be more precise In-Reply-To: <20151123163814.GE15060@sg1> Message-ID: <20151123165159.GG15060@sg1> St?phane Wirtel added the comment: Martin, About the patch of Nikita, this one has already been applied. I have checked the source. David, maybe we should close this issue. And open a new one if we find an other issue in the documentation. What do you suggest? Should I continue on this issue? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 11:54:02 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 23 Nov 2015 16:54:02 +0000 Subject: [issue25699] Easier way to specify reduced globals for doctest In-Reply-To: <1448225180.77.0.54969716848.issue25699@psf.upfronthosting.co.za> Message-ID: <1448297642.7.0.50301986177.issue25699@psf.upfronthosting.co.za> R. David Murray added the comment: I don't understand what the problem is you are trying to solve. Doctests are designed to run with a copy of the module global scope. If pyflakes does not understand that, it is a pyflakes bug, but it doesn't sound like that's the issue. It sounds like you want to use a different global scope, in which case I think the onus is on you to deal with it. I'm -1 on this request. I don't think the additional complexity is worthwhile. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 11:55:23 2015 From: report at bugs.python.org (Victor van den Elzen) Date: Mon, 23 Nov 2015 16:55:23 +0000 Subject: [issue25320] unittest loader.py TypeError when code directory contains a socket In-Reply-To: <1444063424.79.0.244583020203.issue25320@psf.upfronthosting.co.za> Message-ID: <1448297723.53.0.562170051168.issue25320@psf.upfronthosting.co.za> Victor van den Elzen added the comment: Ping ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 11:57:45 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 23 Nov 2015 16:57:45 +0000 Subject: [issue25709] greek alphabet bug it is very disturbing... In-Reply-To: <1448290639.34.0.0738045056565.issue25709@psf.upfronthosting.co.za> Message-ID: <1448297865.71.0.495032968408.issue25709@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is reproducer without IDLE. Looks as pickle is a culprit. >>> import pickle >>> s = '' >>> for i in range(5): ... s += chr(0xe0) ... print(len(s), s, s.encode(), repr(s)) ... print(' ', pickle.dumps(s)) ... 1 ? b'\xc3\xa0' '?' b'\x80\x03X\x02\x00\x00\x00\xc3\xa0q\x00.' 2 ?? b'\xc3\xa0\xc3\xa0' '??' b'\x80\x03X\x04\x00\x00\x00\xc3\xa0\xc3\xa0q\x00.' 3 ?? b'\xc3\xa0\xc3\xa0' '???' b'\x80\x03X\x04\x00\x00\x00\xc3\xa0\xc3\xa0q\x00.' 4 ?? b'\xc3\xa0\xc3\xa0' '????' b'\x80\x03X\x04\x00\x00\x00\xc3\xa0\xc3\xa0q\x00.' 5 ?? b'\xc3\xa0\xc3\xa0' '?????' b'\x80\x03X\x04\x00\x00\x00\xc3\xa0\xc3\xa0q\x00.' ---------- priority: normal -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 12:04:43 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 23 Nov 2015 17:04:43 +0000 Subject: [issue25697] Fix rough alphabetical order in Misc/ACKS In-Reply-To: <1448207088.07.0.222703830715.issue25697@psf.upfronthosting.co.za> Message-ID: <1448298283.72.0.468989826772.issue25697@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: As Georg Brandl said in msg197962, "L?wis" should be sorted as "Loewis" according to German rules. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 12:09:26 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 23 Nov 2015 17:09:26 +0000 Subject: [issue25694] test.libregrtest not installed In-Reply-To: <1448296174.71.0.542976639436.issue25694@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: R. David Murray added the comment: > It used to be there were also changes that needed to be made to the windows build files when a new directory was added. Nosying Steve in case this is still true, assuming there is an option to install the tests (which there might not be, I have no idea not being a Windows user). I failed to find other test subdirectories in PCbuild/ :-/ I don't think that tests are installed or installable on Windows. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 12:10:15 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 23 Nov 2015 17:10:15 +0000 Subject: [issue25694] test.libregrtest not installed In-Reply-To: <1448182149.01.0.175316940428.issue25694@psf.upfronthosting.co.za> Message-ID: <1448298615.88.0.229074850435.issue25694@psf.upfronthosting.co.za> Steve Dower added the comment: Thanks. For 3.5 and later we automatically grab Lib/**/* (except *.py[co]), with Lib/test/**/* split out into a separate install option. I disliked the manual updating as much as everyone else did :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 12:15:22 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 23 Nov 2015 17:15:22 +0000 Subject: [issue25711] Rewrite zipimport from scratch In-Reply-To: <1448296120.48.0.872112518039.issue25711@psf.upfronthosting.co.za> Message-ID: <1448298922.08.0.794482515797.issue25711@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: FYI I'm at the early stage of rewriting zipimport in Python. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 12:18:25 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 23 Nov 2015 17:18:25 +0000 Subject: [issue4744] asynchat documentation needs to be more precise In-Reply-To: <1230168171.56.0.381937953807.issue4744@psf.upfronthosting.co.za> Message-ID: <1448299105.51.0.853124848524.issue4744@psf.upfronthosting.co.za> R. David Murray added the comment: If you've read through the asynchat docs and don't think any of the other mentions of string are incorrect or ambiguous, then we should close it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 12:19:27 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 23 Nov 2015 17:19:27 +0000 Subject: [issue25697] Fix rough alphabetical order in Misc/ACKS In-Reply-To: <1448207088.07.0.222703830715.issue25697@psf.upfronthosting.co.za> Message-ID: <1448299167.81.0.317027479091.issue25697@psf.upfronthosting.co.za> R. David Murray added the comment: That would be being sure, then :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 12:21:40 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 23 Nov 2015 17:21:40 +0000 Subject: [issue25694] test.libregrtest not installed In-Reply-To: <1448182149.01.0.175316940428.issue25694@psf.upfronthosting.co.za> Message-ID: <1448299300.67.0.533925062557.issue25694@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks for doing that, Steve. It would be lovely to fix the unix make too, but I'm sure there's a reason why it is currently done the way it is done and I don't feel like figuring out why so as to try to make things better :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 12:23:42 2015 From: report at bugs.python.org (Brett Cannon) Date: Mon, 23 Nov 2015 17:23:42 +0000 Subject: [issue25711] Rewrite zipimport from scratch In-Reply-To: <1448296120.48.0.872112518039.issue25711@psf.upfronthosting.co.za> Message-ID: <1448299422.64.0.937224139398.issue25711@psf.upfronthosting.co.za> Brett Cannon added the comment: Are you writing it in such a way that it can be bootstspped in with importlib so the stslib can be loaded from it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 12:40:09 2015 From: report at bugs.python.org (random832) Date: Mon, 23 Nov 2015 17:40:09 +0000 Subject: [issue25709] greek alphabet bug it is very disturbing... In-Reply-To: <1448290639.34.0.0738045056565.issue25709@psf.upfronthosting.co.za> Message-ID: <1448300409.13.0.675647995453.issue25709@psf.upfronthosting.co.za> random832 added the comment: I've looked at the raw bytes [through a ctypes pointer to id(s)] of a string affected by the issue, and decoded enough to be able to tell that the bad string has an incorrect UTF-8 length and data, which pickle presumably relies on. HEAD............length..hash....flgs....wstr....u8len...u8ptr...wstrl...data.... 010000003094ac6403000000ffffffffa40000000000000004000000d814480000000000e0e0e000 010000003094ac6403000000e5d0030ca400006500000000060000008814480000000000e0e0e000 I've omitted the UTF-8 data, but both were null-terminated after four and six bytes respectively. ---------- nosy: +random832 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 12:45:06 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Mon, 23 Nov 2015 17:45:06 +0000 Subject: [issue4744] asynchat documentation needs to be more precise In-Reply-To: <1448299105.51.0.853124848524.issue4744@psf.upfronthosting.co.za> Message-ID: <20151123174503.GB23241@sg1> St?phane Wirtel added the comment: For my part, you can close this issue. I have read the asynchat.rst and asynchat.py files and think the rest of the documentation is clear. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 12:53:49 2015 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 23 Nov 2015 17:53:49 +0000 Subject: [issue25660] tabs don't work correctly in python repl In-Reply-To: <1447876730.91.0.918964104484.issue25660@psf.upfronthosting.co.za> Message-ID: <1448301229.31.0.14469823426.issue25660@psf.upfronthosting.co.za> Yury Selivanov added the comment: > At least it is better in 3.5 and only affects one platform now, instead of all of them. No, it affects any platform where CPython is compiled with libedit instead of readline. And even if it was one platform - OS X is big, bigger than Windows probably in terms of Python users. > If people didn't have time to get it fixed and committed before your deadline, that's too bad, I'm afraid :(. I have a fix (attached to the issue). I think it's OK, but I need someone else to test it and review it. Martin, does the patch fix the problem on Linux with libedit? Do we use libedit on Windows? ---------- components: -Macintosh _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 12:54:36 2015 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 23 Nov 2015 17:54:36 +0000 Subject: [issue25660] tabs don't work correctly in python repl In-Reply-To: <1447876730.91.0.918964104484.issue25660@psf.upfronthosting.co.za> Message-ID: <1448301276.72.0.402127073902.issue25660@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 12:58:50 2015 From: report at bugs.python.org (Eryk Sun) Date: Mon, 23 Nov 2015 17:58:50 +0000 Subject: [issue25709] greek alphabet bug it is very disturbing... In-Reply-To: <1448290639.34.0.0738045056565.issue25709@psf.upfronthosting.co.za> Message-ID: <1448301530.12.0.509882651792.issue25709@psf.upfronthosting.co.za> Eryk Sun added the comment: unicode_modifiable in Objects/unicodeobject.c should return 0 if there's cached PyUnicode_UTF8 data. In this case PyUnicode_Append won't operate in place but instead concatenate a new string. ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 13:04:19 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Mon, 23 Nov 2015 18:04:19 +0000 Subject: [issue25710] zipimport is not PEP 3147 or PEP 488 compliant In-Reply-To: <1448293496.52.0.845434990633.issue25710@psf.upfronthosting.co.za> Message-ID: <1448301859.85.0.390559024968.issue25710@psf.upfronthosting.co.za> Changes by St?phane Wirtel : ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 13:05:52 2015 From: report at bugs.python.org (random832) Date: Mon, 23 Nov 2015 18:05:52 +0000 Subject: [issue25709] greek alphabet bug it is very disturbing... In-Reply-To: <1448290639.34.0.0738045056565.issue25709@psf.upfronthosting.co.za> Message-ID: <1448301952.37.0.0779805258176.issue25709@psf.upfronthosting.co.za> random832 added the comment: I can't reproduce without pickle. I did some further digging, though, and it *looks like*... 1. Pickle causes the built-in UTF-8 representation of a string to be populated, whereas encode('utf-8') does not. Can anyone think of any other operations that do this? 2. After the UTF-8 representation of the 2-character string is populated, concatenating a new character to it does not update or clear it. 3. However, it worked just fine with the 1-character string - concatenating it caused the UTF-8 representation to be cleared. The actual operation that creates an inconsistent string is the concatenate operation, but it only happens with a string that has been "primed" by having its UTF-8 representation materialized. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 13:06:00 2015 From: report at bugs.python.org (James Paget) Date: Mon, 23 Nov 2015 18:06:00 +0000 Subject: [issue25713] Setuptools included with 64-bit Windows installer is outdated Message-ID: <1448301960.52.0.82472871794.issue25713@psf.upfronthosting.co.za> New submission from James Paget: This applies to Python 3.5.1rc1 only. The Windows 64-bit standalone installer installs setuptools 18.2, but the latest version is 18.5. It should be noted that the Python 2.7.11rc1 Windows 64-bit standalone installer installs setuptools 18.5. Other Python 3.5.1.rc1 installers (web based, or for other platforms) may have this problem as well, but I have not tried them out. ---------- components: Extension Modules messages: 255208 nosy: James.Paget priority: normal severity: normal status: open title: Setuptools included with 64-bit Windows installer is outdated type: performance versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 13:15:13 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 23 Nov 2015 18:15:13 +0000 Subject: [issue5680] Command-line arguments when running in IDLE In-Reply-To: <1238798556.38.0.28468201552.issue5680@psf.upfronthosting.co.za> Message-ID: <1448302513.23.0.841526255947.issue5680@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Today on SO: https://stackoverflow.com/questions/33866724/read-data-from-file-idle. Person writing script to open a file given on command line asks 'How to test from IDLE?' He found PyCharm, but I would like to add a better answer than the workaround I gave above. It does not have to be either perfect or necessarily permanent. There are two subissues. 1) Get a command line from the user. 1a. What dialog? 1b. Retain it for as least the current session? Same for all editors? Specific to file? 2) Use the command line. 2a. parse with shlex or custom parser. 2b integrate in ScriptBinding.py when starting user code so code sees arguments in sys.argv. Looking *briefly* at the patches: M.B.: Get command line with new extension module argumentDialog.py. Parse with re.findall(arg_regex). Modifies ScriptBinding, including the deletin of a condition for setting user sys.argv. G.G.: Get command line with tkSimpleDialog._QueryString. Split with shlex. Reuses MB's ScriptBinding patch. S.H.: Get command line with custom dialog. Use custom parser. Add new tests. My inclination is to start as simple as possible. Use a message box to get a single string (no error checking is needed). Set for specific file only, not all. The setting could be added to status bar. Parse with shlex. Question: is basic command line parsing system specific? Does MAC stick with unix/posix rules? Should shlex.split use non-posix mode on Windows? ---------- assignee: asvetlov -> terry.reedy nosy: +markroseman type: behavior -> enhancement versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 13:20:50 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 23 Nov 2015 18:20:50 +0000 Subject: [issue25704] Update the devguide to 3.5 In-Reply-To: <1448282986.29.0.990424693558.issue25704@psf.upfronthosting.co.za> Message-ID: <1448302850.69.0.312290080683.issue25704@psf.upfronthosting.co.za> Berker Peksag added the comment: > My first opinion when I have read the documentation was "but this doc is out of date". Yes, some parts of the devguide is outdated and I already gave +1 to update those parts. But most of the other changes are use 3.4 as an example so changing it to 3.5 won't make the devguide up-to-date. For example, +must not be broken at any point between sibling minor releases (3.5.1, etc.). +For both rules, only rare exceptions are accepted and **must** be discussed +first. and -while the maintenance branch names (``2.7``, ``3.4``, etc) are mapped +while the maintenance branch names (``2.7``, ``3.5``, etc) are mapped >> It might also worth to update the build-dep command in setup.rst. > I agree, I am going to check that You've already changed setup.rst :) But it would great if you could test "sudo apt-get build-dep python3.5" and build Python on a modern Debian/Ubuntu since I'm still on 12.04. It's very hard to point which parts are OK in the patch without Rietveld. I'll update it myself and attach here to save both of us some time :) Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 13:42:19 2015 From: report at bugs.python.org (Matt Bogosian) Date: Mon, 23 Nov 2015 18:42:19 +0000 Subject: [issue25714] Consider isinstance(..., numbers.Integral) instead of isinstance(..., int) or isinstance(..., (int, long)) in datetime.py Message-ID: <1448304139.86.0.253570018979.issue25714@psf.upfronthosting.co.za> New submission from Matt Bogosian: datetime.py is peppered with ``assert`` statements that are two restrictive. Specifically, ``isinstance(..., int)`` does not afford compatibility with alternate ``int``-like implementations (e.g., ``future.types.newint``). Some background: * https://github.com/PythonCharmers/python-future/issues/187 * https://bitbucket.org/pypy/pypy/issues/2193/datetimetimedelta-chokes-on-seconds In all cases that I can find, ``assert isinstance(..., int)`` is unnecessarily restrictive, since it is always followed by another ``assert`` which validates that the boundaries are far smaller than a Python 2 native `int` type. (See, e.g., `datetype.py at line 395 `__). I propose replacing instances of ``assert isinstance(..., int)`` and ``assert isinstance(..., (int, long))`` with ``assert isinstance(..., numbers.Integral)`` akin to `this patch `__. ---------- components: Library (Lib) messages: 255211 nosy: posita priority: normal severity: normal status: open title: Consider isinstance(..., numbers.Integral) instead of isinstance(..., int) or isinstance(..., (int, long)) in datetime.py type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 14:20:56 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 23 Nov 2015 19:20:56 +0000 Subject: [issue25709] greek alphabet bug it is very disturbing... In-Reply-To: <1448290639.34.0.0738045056565.issue25709@psf.upfronthosting.co.za> Message-ID: <1448306456.93.0.706410303519.issue25709@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yes, I have came to the same as random832. String objects have "fast path" for concatenating, and in this path cached UTF8 representation is not cleaned. Pickle is one of simplest ways to reproduce this issue. May be it can be reproduced with compile() or type(), but these ways looks too heavyweighted to me. Here is a patch that fixes strings concatenation. ---------- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file41140/issue25709.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 14:27:47 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 23 Nov 2015 19:27:47 +0000 Subject: [issue16123] IDLE - deprecate running without a subprocess In-Reply-To: <1349302429.82.0.0807471180715.issue16123@psf.upfronthosting.co.za> Message-ID: <1448306867.05.0.603625683202.issue16123@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I have some different ideas for this issue that would not necessarily involve removing -n. While -n is can be an inferior experience for users (user code blocks the GUI, other interference, especially tkinter), the reason given for deprecation is to simplify IDLE maintenance by eliminating alternate code paths. Summary: a new rpc_local module might allow us to simplify code now, without removing -n, and provide a path to switching subprocess communication from sockets to pipes. 1. Simplify maintenance by instead isolating -n code in a new 'rpc_local' module that is imported 'as rpc' when -n is given. (A 'run_local' module might also be needed.) The goal would be to have the rest of IDLE as oblivious as possible as to where user code is executed. Other modules would send messages via rpc and not know whether they go to another process (currently via a socket) or or back to the main thread in the same process. I don't know how far this is possible. It would certainly involve some refactoring. 2. Make rpc_local less of a dummy by executing user code in a separate thread connected by a pair of Queues (and call it rpc_thread). I believe this would solve the problem of user code freezing IDLE. On the other hand, it might make user code importing tkinter worse. If so, I would consider declaring that unsupported and not run code containing 'tkinter'. Perhaps I am overlooking some important reason a thread is not already used. 3. If rpc_thread worked, multiprocessing could be used to turn it into a new rpc remote process module that communicated with pipes instead of socket ports. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 14:41:15 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 23 Nov 2015 19:41:15 +0000 Subject: [issue25709] Problem with string concatenation and utf-8 cache. In-Reply-To: <1448290639.34.0.0738045056565.issue25709@psf.upfronthosting.co.za> Message-ID: <1448307675.77.0.915621087643.issue25709@psf.upfronthosting.co.za> Terry J. Reedy added the comment: It would be good to get this in 3.4.4. ---------- components: +Library (Lib) -IDLE nosy: +benjamin.peterson, ezio.melotti, haypo, lemburg, pitrou -kbk, roger.serwy title: greek alphabet bug it is very disturbing... -> Problem with string concatenation and utf-8 cache. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 15:03:37 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 23 Nov 2015 20:03:37 +0000 Subject: [issue5680] Command-line arguments when running in IDLE In-Reply-To: <1238798556.38.0.28468201552.issue5680@psf.upfronthosting.co.za> Message-ID: <1448309017.43.0.549237649113.issue5680@psf.upfronthosting.co.za> Terry J. Reedy added the comment: When file is run with command line args, it might be nice to add an additional separator line with the line entered. That way, if someone ran a series of experiments with different command lines, they would have the command line and output together as documentation that can be saved. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 15:14:42 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 23 Nov 2015 20:14:42 +0000 Subject: [issue25709] Problem with string concatenation and utf-8 cache. In-Reply-To: <1448290639.34.0.0738045056565.issue25709@psf.upfronthosting.co.za> Message-ID: <1448309682.06.0.809688011181.issue25709@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Added test without using pickle. ---------- nosy: +larry priority: high -> release blocker Added file: http://bugs.python.org/file41141/issue25709_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 15:17:46 2015 From: report at bugs.python.org (Erik Bray) Date: Mon, 23 Nov 2015 20:17:46 +0000 Subject: [issue8256] input() doesn't catch _PyUnicode_AsString() exception; io.StringIO().encoding is None In-Reply-To: <1269807316.51.0.487538621224.issue8256@psf.upfronthosting.co.za> Message-ID: <1448309866.77.0.884521598119.issue8256@psf.upfronthosting.co.za> Erik Bray added the comment: I just recently discovered this myself. In the process of debugging the issue I also noticed the same bug that is now fixed via Issue 24402. While I agree that Issue 24402 mostly mitigates the issue I think this patch is still worthwhile, as the current behavior still leads to cryptic, hard to debug errors. For example (although this is not great code, bear with me...) one could write a stdout wrapper like: >>> class WrappedStream: ... encoding = 'utf8' ... errors = None ... def __getattr__(self, attr): ... return getattr(sys.__stdout__, attr) ... >>> sys.stdout = WrappedStream() >>> sys.stdout.fileno() 1 >>> sys.stdout.isatty() True >>> sys.stdout.errors >>> input('Prompt: ') Traceback (most recent call last): File "", line 1, in TypeError: bad argument type for built-in operation This still goes down the path for ttys, but because the 'errors' attribute does not defer to the underlying stream it still leads to a hard to debug exception. To be clear, I think the above code *should* break, just not as cryptically. ---------- nosy: +erik.bray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 15:19:25 2015 From: report at bugs.python.org (Eryk Sun) Date: Mon, 23 Nov 2015 20:19:25 +0000 Subject: [issue25709] Problem with string concatenation and utf-8 cache. In-Reply-To: <1448290639.34.0.0738045056565.issue25709@psf.upfronthosting.co.za> Message-ID: <1448309965.79.0.286416895555.issue25709@psf.upfronthosting.co.za> Eryk Sun added the comment: Serhiy, when does sharing UTF-8 data occur in a compact object? It has to be ASCII since non-ASCII UTF-8 isn't sharable, but PyASCIIObject doesn't have the utf8 field. So it has to be a PyCompactUnicodeObject. But isn't ASCII always allocated as a PyASCIIObject? I need a bit of help getting from point A to point B. Thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 15:24:42 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 23 Nov 2015 20:24:42 +0000 Subject: [issue25715] Python 3.5.1 installer shows wrong upgrade path Message-ID: <1448310282.68.0.27697601288.issue25715@psf.upfronthosting.co.za> New submission from Steve Dower: When launching the installer to upgrade from a Python 3.5.0 install to 3.5.1, the path shown on the Install button is incorrect. Clicking the button installs to the correct location. This is a regression from 3.5.0 that will cause a lot of confusion. It ought to be fixed. ---------- assignee: steve.dower components: Installation, Windows keywords: 3.5regression messages: 255219 nosy: larry, paul.moore, steve.dower, tim.golden, zach.ware priority: release blocker severity: normal stage: needs patch status: open title: Python 3.5.1 installer shows wrong upgrade path type: behavior versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 15:25:16 2015 From: report at bugs.python.org (Erik Bray) Date: Mon, 23 Nov 2015 20:25:16 +0000 Subject: [issue8256] input() doesn't catch _PyUnicode_AsString() exception; io.StringIO().encoding is None In-Reply-To: <1269807316.51.0.487538621224.issue8256@psf.upfronthosting.co.za> Message-ID: <1448310316.07.0.392547520526.issue8256@psf.upfronthosting.co.za> Erik Bray added the comment: > I think the above code *should* break Actually, I see now that Serhiy's patch would allow this example to just pass through to the non-interactive fallback. So I take it back that my example should break--I think using the fallback would also be fine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 15:33:14 2015 From: report at bugs.python.org (Eric Snow) Date: Mon, 23 Nov 2015 20:33:14 +0000 Subject: [issue25711] Rewrite zipimport from scratch In-Reply-To: <1448296120.48.0.872112518039.issue25711@psf.upfronthosting.co.za> Message-ID: <1448310794.5.0.236857245794.issue25711@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +eric.snow, superluser _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 15:33:48 2015 From: report at bugs.python.org (Eric Snow) Date: Mon, 23 Nov 2015 20:33:48 +0000 Subject: [issue25710] zipimport is not PEP 3147 or PEP 488 compliant In-Reply-To: <1448293496.52.0.845434990633.issue25710@psf.upfronthosting.co.za> Message-ID: <1448310828.63.0.539655362992.issue25710@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +superluser _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 15:38:37 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 23 Nov 2015 20:38:37 +0000 Subject: [issue4744] asynchat documentation needs to be more precise In-Reply-To: <1230168171.56.0.381937953807.issue4744@psf.upfronthosting.co.za> Message-ID: <1448311117.63.0.796544408751.issue4744@psf.upfronthosting.co.za> R. David Murray added the comment: OK, let's close it then. If someone finds something wrong they can open a new issue. ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 15:39:50 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 23 Nov 2015 20:39:50 +0000 Subject: [issue25711] Rewrite zipimport from scratch In-Reply-To: <1448296120.48.0.872112518039.issue25711@psf.upfronthosting.co.za> Message-ID: <1448311190.15.0.438754199405.issue25711@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It was my intension. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 15:40:09 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 23 Nov 2015 20:40:09 +0000 Subject: [issue25711] Rewrite zipimport from scratch In-Reply-To: <1448296120.48.0.872112518039.issue25711@psf.upfronthosting.co.za> Message-ID: <1448311209.61.0.164405152274.issue25711@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- Removed message: http://bugs.python.org/msg255222 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 15:40:34 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 23 Nov 2015 20:40:34 +0000 Subject: [issue25711] Rewrite zipimport from scratch In-Reply-To: <1448296120.48.0.872112518039.issue25711@psf.upfronthosting.co.za> Message-ID: <1448311234.98.0.871119376842.issue25711@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I was my intention. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 15:40:42 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 23 Nov 2015 20:40:42 +0000 Subject: [issue25711] Rewrite zipimport from scratch In-Reply-To: <1448296120.48.0.872112518039.issue25711@psf.upfronthosting.co.za> Message-ID: <1448311242.71.0.988450956209.issue25711@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- Removed message: http://bugs.python.org/msg255223 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 15:41:02 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 23 Nov 2015 20:41:02 +0000 Subject: [issue25711] Rewrite zipimport from scratch In-Reply-To: <1448296120.48.0.872112518039.issue25711@psf.upfronthosting.co.za> Message-ID: <1448311262.84.0.780239382235.issue25711@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It was my intention. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 15:44:35 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 23 Nov 2015 20:44:35 +0000 Subject: [issue25713] Setuptools included with 64-bit Windows installer is outdated In-Reply-To: <1448301960.52.0.82472871794.issue25713@psf.upfronthosting.co.za> Message-ID: <1448311475.81.0.848462649045.issue25713@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +dstufft, larry, steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 15:50:32 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Mon, 23 Nov 2015 20:50:32 +0000 Subject: [issue21475] Support the Sitemap extension in robotparser In-Reply-To: <1399858557.27.0.633505879036.issue21475@psf.upfronthosting.co.za> Message-ID: <1448311832.78.0.676153127888.issue21475@psf.upfronthosting.co.za> St?phane Wirtel added the comment: Add a test with your patch. Thank you ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 16:06:42 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 23 Nov 2015 21:06:42 +0000 Subject: [issue25709] Problem with string concatenation and utf-8 cache. In-Reply-To: <1448290639.34.0.0738045056565.issue25709@psf.upfronthosting.co.za> Message-ID: <1448312802.41.0.229058181087.issue25709@psf.upfronthosting.co.za> STINNER Victor added the comment: I reviewed issue25709_2.patch. > It would be good to get this in 3.4.4. Since it's a major bug in the Unicode implementation, it may be worth to fix it in Python 3.3. The bug was introduced in Python 3.3 by the PEP 393. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 16:09:43 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 23 Nov 2015 21:09:43 +0000 Subject: [issue25709] Problem with string concatenation and utf-8 cache. In-Reply-To: <1448290639.34.0.0738045056565.issue25709@psf.upfronthosting.co.za> Message-ID: <1448312983.79.0.696524208462.issue25709@psf.upfronthosting.co.za> Antoine Pitrou added the comment: 3.3 is presumably in security mode. Anyone using it would have had to live with the bug for a long time already. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 16:17:14 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 23 Nov 2015 21:17:14 +0000 Subject: [issue21475] Support the Sitemap extension in robotparser In-Reply-To: <1399858557.27.0.633505879036.issue21475@psf.upfronthosting.co.za> Message-ID: <1448313434.56.0.602642451871.issue21475@psf.upfronthosting.co.za> Berker Peksag added the comment: Peter didn't write a test because issue 25497 (test_robotparser rewrite) needs to be committed first. See msg253016 in issue 25400 for more information. ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 16:19:37 2015 From: report at bugs.python.org (Alexander Heger) Date: Mon, 23 Nov 2015 21:19:37 +0000 Subject: [issue25150] 3.5: Include/pyatomic.h is incompatible with OpenMP (compilation of the third-party yt module fails on Python 3.5) In-Reply-To: <1442494739.31.0.584117765088.issue25150@psf.upfronthosting.co.za> Message-ID: Alexander Heger added the comment: seems to work now with 3.5.1rc1 On 5 November 2015 at 23:01, STINNER Victor wrote: > > STINNER Victor added the comment: > > "Pyatomic-2.patch solved the problem." > > Great! The good news is that the Python 3.5.1 release has now a schedule: https://www.python.org/dev/peps/pep-0478/ > > "3.5.1 final: December 6, 2015" > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 16:20:28 2015 From: report at bugs.python.org (random832) Date: Mon, 23 Nov 2015 21:20:28 +0000 Subject: [issue25709] Problem with string concatenation and utf-8 cache. In-Reply-To: <1448290639.34.0.0738045056565.issue25709@psf.upfronthosting.co.za> Message-ID: <1448313628.92.0.146584505635.issue25709@psf.upfronthosting.co.za> random832 added the comment: > unicode_modifiable in Objects/unicodeobject.c should return 0 if there's cached PyUnicode_UTF8 data. In this case PyUnicode_Append won't operate in place but instead concatenate a new string. Shouldn't it still operate in place but clear it? Operating in place is only an option if the old string has no references and will be discarded, right? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 16:32:36 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 23 Nov 2015 21:32:36 +0000 Subject: [issue25150] 3.5: Include/pyatomic.h is incompatible with OpenMP (compilation of the third-party yt module fails on Python 3.5) In-Reply-To: Message-ID: STINNER Victor added the comment: cool 2015-11-23 22:19 GMT+01:00 Alexander Heger : > > Alexander Heger added the comment: > > seems to work now with 3.5.1rc1 > > On 5 November 2015 at 23:01, STINNER Victor wrote: >> >> STINNER Victor added the comment: >> >> "Pyatomic-2.patch solved the problem." >> >> Great! The good news is that the Python 3.5.1 release has now a schedule: https://www.python.org/dev/peps/pep-0478/ >> >> "3.5.1 final: December 6, 2015" >> >> ---------- >> >> _______________________________________ >> Python tracker >> >> _______________________________________ > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 16:36:42 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 23 Nov 2015 21:36:42 +0000 Subject: [issue25697] Fix rough alphabetical order in Misc/ACKS In-Reply-To: <1448207088.07.0.222703830715.issue25697@psf.upfronthosting.co.za> Message-ID: <1448314602.19.0.293595810886.issue25697@psf.upfronthosting.co.za> Martin Panter added the comment: FWIW when I said it was okay apart from Ma?kowiak, I guessed the accented letters were in German, Spanish, French and Polish alphabets. According to Wikipedia, sometimes the German ??? (umlaut) is put after Z, but sorting with ?oe? is also done, and I think it is better that way :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 16:42:29 2015 From: report at bugs.python.org (Larry Hastings) Date: Mon, 23 Nov 2015 21:42:29 +0000 Subject: [issue25709] Problem with string concatenation and utf-8 cache. In-Reply-To: <1448290639.34.0.0738045056565.issue25709@psf.upfronthosting.co.za> Message-ID: <1448314949.51.0.400047600737.issue25709@psf.upfronthosting.co.za> Larry Hastings added the comment: I read some comments here and on the patches. Serhiy's patch adds some code and Victor says you can't call that macro on this object and wow this is badly broken. Can someone explain in simpler terms what's so broken, exactly? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 16:48:46 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 23 Nov 2015 21:48:46 +0000 Subject: [issue25709] Problem with string concatenation and utf-8 cache. In-Reply-To: <1448290639.34.0.0738045056565.issue25709@psf.upfronthosting.co.za> Message-ID: <1448315326.73.0.043465644132.issue25709@psf.upfronthosting.co.za> STINNER Victor added the comment: " and wow this is badly broken " I mean the currently code is badly broken. The bug is that sometimes, when a string is resized (which doesn't make sense, strings are immutable, right? :-D), the cached UTF-8 string can become corrupted (old pointer not updated). It occurs if * the string is resized (ex: "s += s2") * the string has a cached UTF-8 byte string (ex: int(s) was called before the resize) * the resize moves the memory block to a new address Ok, it's probably unlikely to get these 3 conditions, but from my point of view, it's a major bug because it's in a Python fundamental type (str), it's not a bug in user code and it cannot be worked around (easily). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 17:44:39 2015 From: report at bugs.python.org (Myron Walker) Date: Mon, 23 Nov 2015 22:44:39 +0000 Subject: [issue25716] typeobject.c call_method & call_maybe can leak references on 'func' Message-ID: <1448318679.04.0.579867693106.issue25716@psf.upfronthosting.co.za> New submission from Myron Walker: The 'call_method' and 'call_maybe' function in typeobject.c are leaking a reference on 'func' in cases where 'args == NULL'. In this case both of these functions exit like so: if (args == NULL) return NULL; When they need to do: if (args == NULL) { Py_DECREF(func); return NULL; } ---------- components: Interpreter Core messages: 255235 nosy: Myron Walker priority: normal severity: normal status: open title: typeobject.c call_method & call_maybe can leak references on 'func' type: resource usage versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 17:47:23 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 23 Nov 2015 22:47:23 +0000 Subject: [issue25709] Problem with string concatenation and utf-8 cache. In-Reply-To: <1448290639.34.0.0738045056565.issue25709@psf.upfronthosting.co.za> Message-ID: <1448318843.84.0.343523077715.issue25709@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: In updated patch fixed a bug found by Victor and addressed other his comments. Many thanks Victor! ---------- Added file: http://bugs.python.org/file41142/issue25709_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 17:52:20 2015 From: report at bugs.python.org (Myron Walker) Date: Mon, 23 Nov 2015 22:52:20 +0000 Subject: [issue25716] typeobject.c call_method & call_maybe can leak references on 'func' In-Reply-To: <1448318679.04.0.579867693106.issue25716@psf.upfronthosting.co.za> Message-ID: <1448319140.18.0.614164422349.issue25716@psf.upfronthosting.co.za> Changes by Myron Walker : ---------- versions: +Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 18:06:22 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 23 Nov 2015 23:06:22 +0000 Subject: [issue25701] Document that tp_setattro and tp_setattr are used for deleting attributes In-Reply-To: <1448261904.1.0.459120146493.issue25701@psf.upfronthosting.co.za> Message-ID: <1448319982.56.0.178140530489.issue25701@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a patch. The same problem happens with getset descriptors: >>> del sys.stdout._CHUNK_SIZE SystemError: null argument to internal routine So I also changed the documentation for ?setter? descriptor functions and the tp_descr_set() method. I only looked at the Python 3 implementation, and I understand Python 2 objects work differently in some cases, so I?m not sure if my changes are apropriate for Python 2. ---------- keywords: +patch nosy: +martin.panter stage: needs patch -> patch review Added file: http://bugs.python.org/file41143/setattr.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 19:40:33 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 24 Nov 2015 00:40:33 +0000 Subject: [issue25663] Make rlcompleter avoid duplicate global names In-Reply-To: <1447899261.09.0.497189339865.issue25663@psf.upfronthosting.co.za> Message-ID: <20151124004030.22380.26481@psf.io> Roundup Robot added the comment: New changeset 4799615f4f26 by Martin Panter in branch '3.4': Issue #25663: Make rlcompleter avoid duplicate global names https://hg.python.org/cpython/rev/4799615f4f26 New changeset 4ed70c568baf by Martin Panter in branch '3.5': Issue #25663: Merge rlcompleter fix from 3.4 into 3.5 https://hg.python.org/cpython/rev/4ed70c568baf New changeset 96fb9daf64a5 by Martin Panter in branch 'default': Issue #25663: Merge rlcompleter fix from 3.5 https://hg.python.org/cpython/rev/96fb9daf64a5 New changeset f742c31491e3 by Martin Panter in branch 'default': Issue #25663: Update rlcompleter test for new 3.6 behaviour https://hg.python.org/cpython/rev/f742c31491e3 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 20:19:07 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 24 Nov 2015 01:19:07 +0000 Subject: [issue25663] Make rlcompleter avoid duplicate global names In-Reply-To: <1447899261.09.0.497189339865.issue25663@psf.upfronthosting.co.za> Message-ID: <20151124011857.31397.52142@psf.io> Roundup Robot added the comment: New changeset d3a9b055206c by Martin Panter in branch '2.7': Issue #25663: Make rlcompleter avoid duplicate global names https://hg.python.org/cpython/rev/d3a9b055206c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 20:30:48 2015 From: report at bugs.python.org (Steven D'Aprano) Date: Tue, 24 Nov 2015 01:30:48 +0000 Subject: [issue25709] Problem with string concatenation and utf-8 cache. In-Reply-To: <1448315326.73.0.043465644132.issue25709@psf.upfronthosting.co.za> Message-ID: <20151124013020.GN3821@ando.pearwood.info> Steven D'Aprano added the comment: On Mon, Nov 23, 2015 at 09:48:46PM +0000, STINNER Victor wrote: > * the string has a cached UTF-8 byte string (ex: int(s) was called before the resize) Why do strings cache their UTF-8 encoding? I presume that some of Python's internals rely on the UTF-8 encoding rather than the internal Latin-1/UCS-2/UTF-32 representation (PEP 393). E.g. I infer from the above that int(s) parses the UTF-8 representation of s rather than the internal representation. Is that right? Nevertheless, I wonder why the UTF-8 representation is cached. Is it that expensive to generate that it can't be done on the fly, as needed? As it stands now, non-ASCII strings may be up to twice as big as they need be, once you include the UTF-8 cache. And, as this bug painfully shows, the problem with caches is that you run the risk of the cache being out of date. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 20:47:36 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 24 Nov 2015 01:47:36 +0000 Subject: [issue25709] Problem with string concatenation and utf-8 cache. In-Reply-To: <20151124013020.GN3821@ando.pearwood.info> Message-ID: STINNER Victor added the comment: Steven D'Aprano added the comment: > the problem with caches is that you run the risk of the cache being out of date. Since strings are immutable, it's not a big deal. We control where strings are modified (unicodeobject.c). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 21:02:11 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 24 Nov 2015 02:02:11 +0000 Subject: [issue25716] typeobject.c call_method & call_maybe can leak references on 'func' In-Reply-To: <1448318679.04.0.579867693106.issue25716@psf.upfronthosting.co.za> Message-ID: <1448330531.71.0.970135752969.issue25716@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks, here is a patch with the proposed fix. I also removed an unused macro. Do you have an easy way to verify this, e.g. by calling a method from Python with invalid arguments? Or is this just something you found by inspection? ---------- keywords: +patch nosy: +martin.panter stage: -> patch review versions: -Python 3.2, Python 3.3 Added file: http://bugs.python.org/file41144/call-leak.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 21:07:50 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 24 Nov 2015 02:07:50 +0000 Subject: [issue25663] Make rlcompleter avoid duplicate global names In-Reply-To: <1447899261.09.0.497189339865.issue25663@psf.upfronthosting.co.za> Message-ID: <1448330870.94.0.0471662890791.issue25663@psf.upfronthosting.co.za> Martin Panter added the comment: I chose to keep my strategy of using the set. Using a dictionary to hold the matches could mess up the order, although it looks like Readline sorts the matches before displaying them. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 21:29:05 2015 From: report at bugs.python.org (Eryk Sun) Date: Tue, 24 Nov 2015 02:29:05 +0000 Subject: [issue25709] Problem with string concatenation and utf-8 cache. In-Reply-To: <1448290639.34.0.0738045056565.issue25709@psf.upfronthosting.co.za> Message-ID: <1448332145.42.0.311582355377.issue25709@psf.upfronthosting.co.za> Eryk Sun added the comment: > Why do strings cache their UTF-8 encoding? Strings also cache the wide-string representation. For example: from ctypes import * s = '\241\242\243' pythonapi.PyUnicode_AsUnicodeAndSize(py_object(s), None) pythonapi.PyUnicode_AsUTF8AndSize(py_object(s), None) >>> hex(id(s)) '0x7ffff69f8e98' (gdb) p *(PyCompactUnicodeObject *)0x7ffff69f8e98 $1 = {_base = {ob_base = {_ob_next = 0x7ffff697f890, _ob_prev = 0x7ffff6a04d40, ob_refcnt = 1, ob_type = 0x89d860 }, length = 3, hash = -5238559198920514942, state = {interned = 0, kind = 1, compact = 1, ascii = 0, ready = 1}, wstr = 0x7ffff69690a0 L"???"}, utf8_length = 6, utf8 = 0x7ffff696b7e8 "???", wstr_length = 3} (gdb) p (char *)((PyCompactUnicodeObject *)0x7ffff69f8e98 + 1) $2 = 0x7ffff69f8ef0 "\241\242\243" This object uses 4 bytes for the null-terminated Latin-1 string, which directly follows the PyCompactUnicodeObject struct. It uses 7 bytes for the UTF-8 string. It uses 16 bytes for the wchar_t string (4 bytes per wchar_t). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 23:04:50 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 24 Nov 2015 04:04:50 +0000 Subject: [issue7990] xml.etree.cElementTree lacks full dir() on Element In-Reply-To: <1266856563.54.0.534391635456.issue7990@psf.upfronthosting.co.za> Message-ID: <1448337890.78.0.473910088338.issue7990@psf.upfronthosting.co.za> Martin Panter added the comment: The patch looks technically good, though I?m not a big fan of the double underscores, like element_get__text(). Maybe element_text_getter() instead, because it has to match the ?getter? signature? Personally, I would say keep the doc strings basic. If you want to add more depth about ?tail?, I suggest to keep it to the main RST documentation (which was updated fairly recently). But it would be good to quickly distinguish text and tail other than by name. Maybe: {"text", ..., "A string of text directly after the start tag, or None"}, {"tail", ..., "A string of text directly after the end tag, or None"}, ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 23:23:44 2015 From: report at bugs.python.org (Hans Lawrenz) Date: Tue, 24 Nov 2015 04:23:44 +0000 Subject: [issue25717] tempfile.TemporaryFile fails when dir option set to directory residing on host OS mount Message-ID: <1448339024.55.0.65158482353.issue25717@psf.upfronthosting.co.za> New submission from Hans Lawrenz: Inside a virtualbox vm, calling tempfile.TemporaryFile(dir=foo) where foo is a directory which resides on a volume mounted from the host OS, a FileNotFoundError exception is thrown. In the following code sample, the second block will print "Path 2: ERROR" on Python 3.5 but not on 3.4 or 2.7 (assuming the vagrant environment provided below): import tempfile try: with tempfile.TemporaryFile() as tf: tf.write("testing testing testing\n".encode('utf-8')) print("Path 1: worked") except FileNotFoundError as e: print("Path 1: ERROR") try: with tempfile.TemporaryFile(dir="/vagrant") as tf: tf.write("testing testing testing\n".encode('utf-8')) print("Path 2: worked") except FileNotFoundError as e: print("Path 2: ERROR") A runnable test case can be found here: https://github.com/hlawrenz/py35tempfiletest ---------- components: Library (Lib) messages: 255246 nosy: Hans Lawrenz priority: normal severity: normal status: open title: tempfile.TemporaryFile fails when dir option set to directory residing on host OS mount type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 23:42:49 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 24 Nov 2015 04:42:49 +0000 Subject: [issue25717] tempfile.TemporaryFile fails when dir option set to directory residing on host OS mount In-Reply-To: <1448339024.55.0.65158482353.issue25717@psf.upfronthosting.co.za> Message-ID: <1448340169.78.0.89078306448.issue25717@psf.upfronthosting.co.za> Martin Panter added the comment: I am unable to produce this on native Linux so far with various kinds of mount points I normally have. What is your guest OS? If you can provide any more details of the failure, such as a traceback, that would be helpful. What is the underlying OS call that is causing the exception? ---------- keywords: +3.5regression nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 00:42:24 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 24 Nov 2015 05:42:24 +0000 Subject: [issue25660] tabs don't work correctly in python repl In-Reply-To: <1447876730.91.0.918964104484.issue25660@psf.upfronthosting.co.za> Message-ID: <1448343744.45.0.252118046251.issue25660@psf.upfronthosting.co.za> Martin Panter added the comment: Regarding the purpose of the ?Readline completer? module, I agree it is inconvenient. But the documentation does say ?without readline, the Completer class . . . can still be used?. I ran into this problem in Issue 25419 where Serhiy pointed it out. OS X is apparently the main platform where Editline is supported. There are even #ifdef __APPLE__ bits to work around bugs. However, people also seem to use Editline on Free BSD. Testing your current patch on Linux + Editline, it is worse than the 3.5 behaviour. Pressing Tab once appears to work, until you type the next key. It seems to invoke the history search mode (normally done with Ctrl+R), except the ?bck:? indicator is not immediately shown. So the next key brings up an old history line, rather than being inserted directly. But if this works fine on OS X?s Editline, then maybe my setup is not right. I also see annoying buffering or flushing problems with my Editline setup. I am using Arch Linux?s libedit-20150325_3.1-1 package. Testing with Linux + Gnu Readline, it seems to work as advertised. I haven?t heard of Editline or Gnu Readline being used on Windows, certainly not in normal setups. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 01:19:23 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 24 Nov 2015 06:19:23 +0000 Subject: [issue25700] namedtuple documentation In-Reply-To: <1448239480.46.0.591822736111.issue25700@psf.upfronthosting.co.za> Message-ID: <20151124061919.648.54889@psf.io> Roundup Robot added the comment: New changeset f611e2244c69 by Raymond Hettinger in branch '3.5': Issue #25700: Clarify that namedtuple property docstrings became writeable in 3.5 https://hg.python.org/cpython/rev/f611e2244c69 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 01:54:31 2015 From: report at bugs.python.org (Hans Lawrenz) Date: Tue, 24 Nov 2015 06:54:31 +0000 Subject: [issue25717] tempfile.TemporaryFile fails when dir option set to directory residing on host OS mount In-Reply-To: <1448339024.55.0.65158482353.issue25717@psf.upfronthosting.co.za> Message-ID: <1448348071.98.0.973891982338.issue25717@psf.upfronthosting.co.za> Hans Lawrenz added the comment: Host OS: Mac OS 10.11.1 Guest OS: Ubuntu Trusty 64 Virtualbox: 4.3.30 Vagrant: 1.7.4 Example with trace thrown: vagrant at vagrant-ubuntu-trusty-64:/vagrant$ cat tt.py import tempfile with tempfile.TemporaryFile(dir="/vagrant") as tf: tf.write("testing testing testing\n".encode('utf-8')) vagrant at vagrant-ubuntu-trusty-64:/vagrant$ python3.5 tt.py Traceback (most recent call last): File "tt.py", line 4, in with tempfile.TemporaryFile(dir="/vagrant") as tf: File "/usr/lib/python3.5/tempfile.py", line 753, in TemporaryFile newline=newline, encoding=encoding) FileNotFoundError: [Errno 2] No such file or directory I think the underlying system call that's causing the error (I attached the full strace in case that's helpful): open("/vagrant", O_RDWR|O_EXCL|O_DIRECTORY|O_NOFOLLOW|O_CLOEXEC|0x400000) = -1 EOPNOTSUPP (Operation not supported) Finally, the mount point looks like this: vagrant on /vagrant type vboxsf (uid=1000,gid=1000,rw) ---------- Added file: http://bugs.python.org/file41145/tempfile-strace.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 02:32:04 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 24 Nov 2015 07:32:04 +0000 Subject: [issue25660] tabs don't work correctly in python repl In-Reply-To: <1447876730.91.0.918964104484.issue25660@psf.upfronthosting.co.za> Message-ID: <1448350324.91.0.558847358503.issue25660@psf.upfronthosting.co.za> Martin Panter added the comment: It seems to be the readline.redisplay() line that triggers the search mode. If I comment out that line, I am back to the 3.5 behaviour that adds extra lines. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 03:07:23 2015 From: report at bugs.python.org (Armin Rigo) Date: Tue, 24 Nov 2015 08:07:23 +0000 Subject: [issue25718] itertools.accumulate __reduce__/__setstate__ bug Message-ID: <1448352443.54.0.731172452763.issue25718@psf.upfronthosting.co.za> New submission from Armin Rigo: itertools.accumulate() has got methods __reduce__() and __setstate__() which fail at saving/restoring the state in all cases. Example: >>> a = itertools.accumulate([0.0, 42]) >>> next(a) 0.0 >>> b = copy.deepcopy(a) >>> next(a) 42.0 >>> next(b) 42 # should have been the same as the previous result More precisely, the problem occurs when the C-level "total" field has some value whose truth-value is false. Then __reduce__/__setstate__ will not restore the value of this field, but keep it NULL. That's why in the example above the intermediate total of 0.0 is forgotten, and the next(b) call will again just pick the next value without doing any addition. (The problem can hurt more than in this example if we use a custom function instead of addition.) A fix is easy but, as far as I can tell, it requires breaking the pickled format of accumulate() iterators that have already started. ---------- components: Extension Modules messages: 255252 nosy: arigo priority: normal severity: normal status: open title: itertools.accumulate __reduce__/__setstate__ bug type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 03:37:58 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 24 Nov 2015 08:37:58 +0000 Subject: [issue21679] Prevent extraneous fstat during open() In-Reply-To: <1402055285.47.0.764387439948.issue21679@psf.upfronthosting.co.za> Message-ID: <1448354278.4.0.823446886411.issue21679@psf.upfronthosting.co.za> Martin Panter added the comment: The change made here no longer tolerates fstat() returning an error, which seems to be the cause of Issue 25717. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 03:39:42 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 24 Nov 2015 08:39:42 +0000 Subject: [issue25717] tempfile.TemporaryFile fails when dir option set to directory residing on host OS mount In-Reply-To: <1448339024.55.0.65158482353.issue25717@psf.upfronthosting.co.za> Message-ID: <1448354382.71.0.39317937893.issue25717@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks for the strace output. I think the actual error is the fstat() call a bit after that first open() call. FileNotFoundError is ENOENT: open("/vagrant/tmpy5ioznh4", O_RDWR|O_CREAT|O_EXCL|O_NOFOLLOW|O_CLOEXEC, 0600) = 4 unlink("/vagrant/tmpy5ioznh4") = 0 fstat(4, 0x7ffc0b326520) = -1 ENOENT (No such file or directory) close(4) = 0 write(2, "Traceback (most recent call last"..., 35Traceback (most recent call last): My theory is that the fstat() call at is failing, probably because the file entry has been removed from its directory. This call was added by revision 3b5279b5bfd1 (Issue 21679). Before this change, fstat() was called twice, but in each case an error was tolerated. Posix does not mention fstat() returning this ENOENT error, so maybe this could be a bug with the Virtual Box or Vagrant driver for the mounted filesystem. But it might be nice to make Python more permissive if fstat() fails, like it was in 3.4. As a workaround, you may be able to use NamedTemporaryFile, if you are happy for the file to have a name and a directory entry. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 03:51:07 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 24 Nov 2015 08:51:07 +0000 Subject: [issue25709] Problem with string concatenation and utf-8 cache. In-Reply-To: <1448290639.34.0.0738045056565.issue25709@psf.upfronthosting.co.za> Message-ID: <1448355067.78.0.230287906971.issue25709@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Fixed yet one bug (thanks Victor again). Test is improved, now it doesn't rely on implementation detail of particular builtin. ---------- Added file: http://bugs.python.org/file41146/issue25709_4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 03:52:52 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 24 Nov 2015 08:52:52 +0000 Subject: [issue25718] itertools.accumulate __reduce__/__setstate__ bug In-Reply-To: <1448352443.54.0.731172452763.issue25718@psf.upfronthosting.co.za> Message-ID: <1448355172.75.0.986941721014.issue25718@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> kristjan.jonsson nosy: +kristjan.jonsson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 03:54:50 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 24 Nov 2015 08:54:50 +0000 Subject: [issue25714] Consider isinstance(..., numbers.Integral) instead of isinstance(..., int) or isinstance(..., (int, long)) in datetime.py In-Reply-To: <1448304139.86.0.253570018979.issue25714@psf.upfronthosting.co.za> Message-ID: <1448355290.86.0.928261148538.issue25714@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- nosy: +tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 03:58:50 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 24 Nov 2015 08:58:50 +0000 Subject: [issue25709] Problem with string concatenation and utf-8 cache. In-Reply-To: <20151124013020.GN3821@ando.pearwood.info> Message-ID: <565426C4.1080100@egenix.com> Marc-Andre Lemburg added the comment: On 24.11.2015 02:30, Steven D'Aprano wrote: > > Steven D'Aprano added the comment: > > On Mon, Nov 23, 2015 at 09:48:46PM +0000, STINNER Victor wrote: > >> * the string has a cached UTF-8 byte string (ex: int(s) was called before the resize) > > Why do strings cache their UTF-8 encoding? > > I presume that some of Python's internals rely on the UTF-8 encoding > rather than the internal Latin-1/UCS-2/UTF-32 representation (PEP 393). > E.g. I infer from the above that int(s) parses the UTF-8 representation > of s rather than the internal representation. Is that right? > > Nevertheless, I wonder why the UTF-8 representation is cached. Is it > that expensive to generate that it can't be done on the fly, as needed? > As it stands now, non-ASCII strings may be up to twice as big as they > need be, once you include the UTF-8 cache. And, as this bug painfully > shows, the problem with caches is that you run the risk of the cache > being out of date. The cache is needed because it's the only way to get a direct C char* to the object's UTF-8 representation without having to worry about memory management on the caller's side. Not having access to this would break a lot of code using the Python C API, since the cache is there per design. The speedup aspect is secondary. Unicode objects are normally immutable, but there are a few corner cases during the initialization of the objects where they are in fact mutable for a short while, e.g. when creating an empty object which is then filled with data and resized to the final length before passing it back to Python. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 04:07:54 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 24 Nov 2015 09:07:54 +0000 Subject: [issue25709] Problem with string concatenation and utf-8 cache. In-Reply-To: <1448290639.34.0.0738045056565.issue25709@psf.upfronthosting.co.za> Message-ID: <1448356074.5.0.156865369935.issue25709@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > Why do strings cache their UTF-8 encoding? Mainly for compatibility with existing C API. Common way to parse function arguments in implemented in C function is to use special argument parsing API: PyArg_ParseTuple, PyArg_ParseTupleAndKeywords, or PyArg_Parse. Most format codes for Unicode strings returned a C pointer to char array. For that encoded Unicode strings should be kept somewhere at least for the time of executing C function. As well as PyArg_Parse* functions doesn't allow user to specify a storage for encoded string, it should be saved in Unicode object. That is not new to PEP 393 or Python 3, in Python 2 the Unicode objects also keep cached encoded version. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 04:10:44 2015 From: report at bugs.python.org (Bill Tutt) Date: Tue, 24 Nov 2015 09:10:44 +0000 Subject: [issue25034] string.Formatter accepts empty fields but displays wrong when nested In-Reply-To: <1441740193.79.0.679577096269.issue25034@psf.upfronthosting.co.za> Message-ID: <1448356244.6.0.157854935691.issue25034@psf.upfronthosting.co.za> Bill Tutt added the comment: I don't suppose this change could make it into 2.7.11 as well? Thanks, Bill ---------- nosy: +Bill Tutt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 05:25:25 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 24 Nov 2015 10:25:25 +0000 Subject: [issue25709] Problem with string concatenation and utf-8 cache. In-Reply-To: <1448290639.34.0.0738045056565.issue25709@psf.upfronthosting.co.za> Message-ID: <1448360725.15.0.391266212138.issue25709@psf.upfronthosting.co.za> STINNER Victor added the comment: issue25709_4.patch now looks good to me, but I added some minor comments on the review. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 05:54:19 2015 From: report at bugs.python.org (Florin Papa) Date: Tue, 24 Nov 2015 10:54:19 +0000 Subject: [issue25719] Deprecate spitfire benchmark Message-ID: <1448362459.17.0.918374944074.issue25719@psf.upfronthosting.co.za> New submission from Florin Papa: Hi all, This is Florin Papa from the Server Languages Optimizations Team at Intel Corporation. The patch submitted here deprecates the spitfire benchmark, which uses psyco. Psyco is "unmaintained and dead", according to their website (http://psyco.sourceforge.net/) and it has not received any updates since 2012. The spitfire benchmark crashes because psyco does not have support for x64 architectures. To apply the patch please follow these steps: hg clone https://hg.python.org/benchmarks cd benchmarks/ copy deprecate_spitfire.patch to the current directory hg import --no-commit deprecate_spitfire.patch Thank you, Florin Papa ---------- components: Benchmarks files: deprecate_spitfire.patch keywords: patch messages: 255260 nosy: brett.cannon, florin.papa, pitrou priority: normal severity: normal status: open title: Deprecate spitfire benchmark type: crash versions: Python 2.7 Added file: http://bugs.python.org/file41147/deprecate_spitfire.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 06:39:08 2015 From: report at bugs.python.org (Ismail Donmez) Date: Tue, 24 Nov 2015 11:39:08 +0000 Subject: [issue25720] Fix curses module compilation with ncurses6 Message-ID: <1448365148.0.0.732837314732.issue25720@psf.upfronthosting.co.za> New submission from Ismail Donmez: ncurses6 turned on NCURSES_OPAQUE, so now you have to use some helper functions instead of accessing the structs directly. This _should_ be compatible with ncurses5 though I didn't test it. Original patch is from openSUSE. ---------- components: Extension Modules files: curses-ncurses6.patch keywords: patch messages: 255261 nosy: donmez priority: normal severity: normal status: open title: Fix curses module compilation with ncurses6 versions: Python 3.5 Added file: http://bugs.python.org/file41148/curses-ncurses6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 07:06:23 2015 From: report at bugs.python.org (Florin Papa) Date: Tue, 24 Nov 2015 12:06:23 +0000 Subject: [issue25721] Fix pybench always_display error Message-ID: <1448366783.46.0.677910180147.issue25721@psf.upfronthosting.co.za> New submission from Florin Papa: Hi all, This is Florin Papa from the Server Languages Optimizations Team at Intel Corporation. The patch submitted here solves a crash occurring on Python 2.7 after running pybench from perf.py (python perf.py -r -b pybench base_python modified_python). The error appears when trying to display the results of the run because the PyBenchBenchmarkResult class does not include the attribute "always_display". Here is the error message received: File "../benchmarks/perf.py", line 2574, in main if result.always_display: AttributeError: 'PyBenchBenchmarkResult' object has no attribute 'always_display' To apply the patch please follow these steps: hg clone https://hg.python.org/benchmarks cd benchmarks/ copy fix_pybench_results.patch to the current directory hg import --no-commit fix_pybench_results.patch Thank you, Florin Papa ---------- components: Benchmarks messages: 255262 nosy: brett.cannon, florin.papa, pitrou priority: normal severity: normal status: open title: Fix pybench always_display error versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 07:06:54 2015 From: report at bugs.python.org (Florin Papa) Date: Tue, 24 Nov 2015 12:06:54 +0000 Subject: [issue25721] Fix pybench always_display error In-Reply-To: <1448366783.46.0.677910180147.issue25721@psf.upfronthosting.co.za> Message-ID: <1448366814.66.0.746535305026.issue25721@psf.upfronthosting.co.za> Changes by Florin Papa : ---------- type: -> crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 07:32:37 2015 From: report at bugs.python.org (SpaceOne) Date: Tue, 24 Nov 2015 12:32:37 +0000 Subject: [issue20923] ConfigParser should nested [] in section names. In-Reply-To: <1394806905.89.0.637343755468.issue20923@psf.upfronthosting.co.za> Message-ID: <1448368357.41.0.310155394869.issue20923@psf.upfronthosting.co.za> SpaceOne added the comment: IMHO your rejection is stupid. User input should always be validated. At least a ValueError should be raised if add_section() is called with a string containing ']\x00\n['. As this will always create a broken configuration. Otherwise ConfigParser cannot be used to write new config files without having deeper knowledge about the implementation. ---------- nosy: +spaceone _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 07:32:51 2015 From: report at bugs.python.org (Florin Papa) Date: Tue, 24 Nov 2015 12:32:51 +0000 Subject: [issue25721] Fix pybench always_display error In-Reply-To: <1448366783.46.0.677910180147.issue25721@psf.upfronthosting.co.za> Message-ID: <1448368371.33.0.0675919353489.issue25721@psf.upfronthosting.co.za> Changes by Florin Papa : ---------- keywords: +patch Added file: http://bugs.python.org/file41149/fix_pybench_results.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 07:41:25 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 24 Nov 2015 12:41:25 +0000 Subject: [issue25300] Enable Intel MPX (Memory protection Extensions) feature In-Reply-To: <1443788737.62.0.174147088714.issue25300@psf.upfronthosting.co.za> Message-ID: <1448368885.28.0.344750258363.issue25300@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Hi, I've reviewed the latest patch. I have a more general question: the patch sprinkles some Py_INIT_BOUNDS() calls in various places. What the macro does is set the pointer's bounds to "INIT", which basically means disable any checks (the pointer is allowed to access all memory). Is there a reason for that? MPX checks for out-of-bounds accesses, so setting pointer bounds to "INIT" seems to defeat the point. (if MPX otherwise complains about out-of-bounds accesses in CPython, perhaps they are genuine bugs that deserve fixing, or perhaps the annotations in the patch are not good enough) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 08:37:38 2015 From: report at bugs.python.org (Alexander Todorov) Date: Tue, 24 Nov 2015 13:37:38 +0000 Subject: [issue25722] Lib/ssl.py breaks certificate validation for wildcard domains, e.g. *.s3.amazonaws.com Message-ID: <1448372258.01.0.348498754399.issue25722@psf.upfronthosting.co.za> New submission from Alexander Todorov: The latest ssl.py file tries to validate hostnames vs certificates but includes a faulty regexp which causes any wildcard domains (e.g. *.s3.amazonaws.com) to fail validation. Steps to Reproduce: >>> import ssl >>> ssl._dnsname_match("*.s3.amazonaws.com", "planet.sofiavalley.com.s3.amazonaws.com") >>> >From Python's documentation: [] Used to indicate a set of characters. In a set: ... Special characters lose their special meaning inside sets. For example, [(+*)] will match any of the literal characters '(', '+', '*', or ')'. ^^^^^^^^^ this is the cause of the error I've found this after an upgrade to RHEL 7.2 which contains the faulty code broke s3cmd for me. The result - one of my sites was outdated for a couple of days. For more info and proposed patch see: https://bugzilla.redhat.com/show_bug.cgi?id=1284916 https://bugzilla.redhat.com/show_bug.cgi?id=1284930 Note: As far as I can tell this affects upstream Python 2.7.10 and 3.5.0, however in the packages Red Hat distributes the code is different between 2 and 3 while upstream is more consistent. ---------- messages: 255265 nosy: Alexander Todorov priority: normal severity: normal status: open title: Lib/ssl.py breaks certificate validation for wildcard domains, e.g. *.s3.amazonaws.com versions: Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 08:47:49 2015 From: report at bugs.python.org (Christian Heimes) Date: Tue, 24 Nov 2015 13:47:49 +0000 Subject: [issue25722] Lib/ssl.py breaks certificate validation for wildcard domains, e.g. *.s3.amazonaws.com In-Reply-To: <1448372258.01.0.348498754399.issue25722@psf.upfronthosting.co.za> Message-ID: <1448372869.79.0.158378490254.issue25722@psf.upfronthosting.co.za> Christian Heimes added the comment: This is not a bug. It's actually the way how wildcards in X.509 certificates work. For hostnames a wildcard only matches one label. There can only be one wildcard and the wildcard must be in the left-most label. https://tools.ietf.org/html/rfc6125#section-6.4.3 This means that "*.s3.amazonaws.com" matches "com.s3.amazonaws.com" but doesn't match "planet.sofiavalley.com.s3.amazonaws.com". ---------- nosy: +christian.heimes resolution: -> not a bug stage: -> resolved status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 09:00:25 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 24 Nov 2015 14:00:25 +0000 Subject: [issue25720] Fix curses module compilation with ncurses6 In-Reply-To: <1448365148.0.0.732837314732.issue25720@psf.upfronthosting.co.za> Message-ID: <1448373625.37.0.449753408067.issue25720@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka, twouters stage: -> patch review type: -> compile error _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 09:54:55 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 24 Nov 2015 14:54:55 +0000 Subject: [issue25714] Consider isinstance(..., numbers.Integral) instead of isinstance(..., int) or isinstance(..., (int, long)) in datetime.py In-Reply-To: <1448304139.86.0.253570018979.issue25714@psf.upfronthosting.co.za> Message-ID: <1448376895.39.0.293090826465.issue25714@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: C implementation almost everywhere (except strftime/strptime) accepts long as well as int, but not general integral numbers. Python implementation of the datetime module is not entire compatible with C implementation (default in CPython), therefore alternative Python implementations that doesn't use an accelerator is incompatible with CPython. I consider this as a bug and think that we should weak some of checks isinstance(..., int) to isinstance(..., (int, long)). numbers.Integral is too wide type, C implementation doesn't support it. ---------- nosy: +belopolsky, serhiy.storchaka stage: -> needs patch type: enhancement -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 10:09:35 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 24 Nov 2015 15:09:35 +0000 Subject: [issue25660] tabs don't work correctly in python repl In-Reply-To: <1447876730.91.0.918964104484.issue25660@psf.upfronthosting.co.za> Message-ID: <1448377775.73.0.324632406902.issue25660@psf.upfronthosting.co.za> R. David Murray added the comment: We try our best to support libedit, but support for it did come after readline, so there are issues with the support. However, if we are (as we are) enabling completion by default, I think that has to work with libedit, since that's what is used on OSX which, as Yury said, is a major platform for Python. IIRC, on windows one has to install something 3rd party (pyreadline?) to get readline support. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 10:21:41 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 24 Nov 2015 15:21:41 +0000 Subject: [issue20923] ConfigParser should nested [] in section names. In-Reply-To: <1394806905.89.0.637343755468.issue20923@psf.upfronthosting.co.za> Message-ID: <1448378501.13.0.592370399602.issue20923@psf.upfronthosting.co.za> R. David Murray added the comment: The enhancement request was rejected. At this point I think it would be better to open a new bug requesting that an error be raised if the supplied section name contains a ']'. The question there is if there are backward compatibility issues. That can be discussed on the new issue you open. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 10:31:44 2015 From: report at bugs.python.org (SpaceOne) Date: Tue, 24 Nov 2015 15:31:44 +0000 Subject: [issue25723] ConfigParser should never write broken configurations Message-ID: <1448379104.29.0.433011869224.issue25723@psf.upfronthosting.co.za> New submission from SpaceOne: >>> from configparser import ConfigParser >>> from io import StringIO >>> from configparser import ConfigParser >>> c = ConfigParser() >>> c.add_section('foo]\nbar=baz\n[bar') >>> fd = StringIO() >>> c.write(fd) >>> print(fd.getvalue()) [foo] bar=baz [bar] User input should always be validated. At least a ValueError should be raised if add_section() is called with a string containing anything like ']\x00\n[' or any other non-printable string. As this will always create a broken configuration or might lead to ini-injections. Otherwise ConfigParser cannot be used to write new config files without having deeper knowledge about the implementation. See also: http://bugs.python.org/issue23301 http://bugs.python.org/issue20923 ---------- components: Library (Lib) messages: 255270 nosy: spaceone priority: normal severity: normal status: open title: ConfigParser should never write broken configurations type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 10:32:04 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 24 Nov 2015 15:32:04 +0000 Subject: [issue25709] Problem with string concatenation and utf-8 cache. In-Reply-To: <1448290639.34.0.0738045056565.issue25709@psf.upfronthosting.co.za> Message-ID: <1448379124.92.0.885939633761.issue25709@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Georg, I ask for applying this fix to 3.3. ---------- nosy: +georg.brandl versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 10:32:51 2015 From: report at bugs.python.org (SpaceOne) Date: Tue, 24 Nov 2015 15:32:51 +0000 Subject: [issue25723] ConfigParser should never write broken configurations In-Reply-To: <1448379104.29.0.433011869224.issue25723@psf.upfronthosting.co.za> Message-ID: <1448379171.83.0.166285877435.issue25723@psf.upfronthosting.co.za> SpaceOne added the comment: I would have expected something like ValueError('A section must not contain any of ...') or at least that the characters are simply stripped. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 10:38:38 2015 From: report at bugs.python.org (Hans Lawrenz) Date: Tue, 24 Nov 2015 15:38:38 +0000 Subject: [issue25717] tempfile.TemporaryFile fails when dir option set to directory residing on host OS mount In-Reply-To: <1448339024.55.0.65158482353.issue25717@psf.upfronthosting.co.za> Message-ID: <1448379518.95.0.315170569471.issue25717@psf.upfronthosting.co.za> Hans Lawrenz added the comment: Unfortunately changing the tempfile call isn't an easy option for me. The situation in which I'm encountering the error is running tox on our project which is mounted in the /vagrant directory in the VM (this is standard for vagrant). Tox makes its own temp directory--presumably for test isolation--in the .tox directory in the project root. The actual call to tempfile.TemporaryFile() which is triggering the error is in a third party library that is called during a test run. I was able to work around the issue by changing the tox workdir setting to outside the mount. However, I'd like to mention that developing in vagrant in this fashion isn't uncommon and once 3.5 gains adoption I would guess this issue may affect a good number of people. I'm happy to take a stab at writing a patch but looking at the code it's somewhat out of my comfort zone and I worry I'd make a hash of it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 10:40:22 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 24 Nov 2015 15:40:22 +0000 Subject: [issue25723] ConfigParser should never write broken configurations In-Reply-To: <1448379104.29.0.433011869224.issue25723@psf.upfronthosting.co.za> Message-ID: <1448379622.4.0.951613667308.issue25723@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +lukasz.langa versions: -Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 10:44:59 2015 From: report at bugs.python.org (Marc Deslauriers) Date: Tue, 24 Nov 2015 15:44:59 +0000 Subject: [issue25724] SSLv3 test failure on Ubuntu 16.04 LTS Message-ID: <1448379899.26.0.590688499284.issue25724@psf.upfronthosting.co.za> New submission from Marc Deslauriers: In order to disable SSLv3 in OpenSSL without breaking ABI, Ubuntu 16.04 LTS will ship with OP_NO_SSLv3 forced on by default. This is causing the test_ssl.py test to fail. Attached is a patch to fix the issue. ---------- components: Tests files: fix-sslv3-test.diff keywords: patch messages: 255274 nosy: mdeslaur priority: normal severity: normal status: open title: SSLv3 test failure on Ubuntu 16.04 LTS versions: Python 3.5 Added file: http://bugs.python.org/file41150/fix-sslv3-test.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 10:51:19 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 24 Nov 2015 15:51:19 +0000 Subject: [issue25717] tempfile.TemporaryFile fails when dir option set to directory residing on host OS mount In-Reply-To: <1448339024.55.0.65158482353.issue25717@psf.upfronthosting.co.za> Message-ID: <1448380279.48.0.0557472507037.issue25717@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What is exact version of you Python? I can't identify the line in the traceback. There are few lines "newline=newline, encoding=encoding)" in tempfile.py, but no one is closer to line 753. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 11:07:13 2015 From: report at bugs.python.org (Emanuel Barry) Date: Tue, 24 Nov 2015 16:07:13 +0000 Subject: [issue25717] tempfile.TemporaryFile fails when dir option set to directory residing on host OS mount In-Reply-To: <1448339024.55.0.65158482353.issue25717@psf.upfronthosting.co.za> Message-ID: <1448381233.74.0.228231560217.issue25717@psf.upfronthosting.co.za> Emanuel Barry added the comment: I'm with Serhiy, the line number is inane. Could you put the exact contents of your /usr/lib/python3.5/tempfile.py file somewhere for us to see? Output of sys.version would be nice, too. ---------- nosy: +ebarry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 11:16:49 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 24 Nov 2015 16:16:49 +0000 Subject: [issue20923] ConfigParser should nested [] in section names. In-Reply-To: <1394806905.89.0.637343755468.issue20923@psf.upfronthosting.co.za> Message-ID: <1448381809.43.0.9628558025.issue20923@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Sebastian: you have it backwards. A paraphrase of Postel's recommendation (calling it a Law is wrong) is 'accept dirty data, emit clean data'. This is the current behavior. See https://en.wikipedia.org/wiki/Robustness_principle. This article also explains the opposite viewpoint, that dirty data should be rejected, as SpaceOne is suggesting. SpaceOne: unless it is your intention to discourage people from volunteering their time to respond to issues raised on the tracker, you should read what they write more carefully and think more carefully about how you express your opinions. If you really want a ValueError here, open an new enhancement issue for 3.6. ---------- type: behavior -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 11:32:02 2015 From: report at bugs.python.org (SpaceOne) Date: Tue, 24 Nov 2015 16:32:02 +0000 Subject: [issue20923] ConfigParser should nested [] in section names. In-Reply-To: <1394806905.89.0.637343755468.issue20923@psf.upfronthosting.co.za> Message-ID: <1448382722.1.0.472559106314.issue20923@psf.upfronthosting.co.za> SpaceOne added the comment: Sorry about that! I created http://bugs.python.org/issue25723. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 11:33:05 2015 From: report at bugs.python.org (Sebastian Bank) Date: Tue, 24 Nov 2015 16:33:05 +0000 Subject: [issue20923] ConfigParser should nested [] in section names. In-Reply-To: <1394806905.89.0.637343755468.issue20923@psf.upfronthosting.co.za> Message-ID: <1448382785.05.0.369145209843.issue20923@psf.upfronthosting.co.za> Sebastian Bank added the comment: Terry: I am not so sure about that interpretation. Do we agree that the INI-files are the data/message? ConfigParser refuses to accept dirty INI-Files (with ']' in section names) but will produce this kind of files. I we see the arguments given to ConfigParser as data/message, it does indeed accept dirty data as you say, but still it does not emit clean one in that case, right? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 11:37:09 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 24 Nov 2015 16:37:09 +0000 Subject: [issue25718] itertools.accumulate __reduce__/__setstate__ bug In-Reply-To: <1448352443.54.0.731172452763.issue25718@psf.upfronthosting.co.za> Message-ID: <1448383029.96.0.715722589184.issue25718@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: __reduce__() and __setstate__() methods of itertools.accumulate() look correct. The problem is not in itertools.accumulate(), but in the copy module. It uses the same __reduce__ protocol as pickle, but in different way. In the pickle module (in both Python and C implementations) state value is ignored only if it is None. In the copy module any state with boolean value is False is ignored. Proposed patch fixes the copy module. ---------- components: +Library (Lib) -Extension Modules nosy: +alexandre.vassalotti, serhiy.storchaka stage: -> patch review versions: +Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 11:37:25 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 24 Nov 2015 16:37:25 +0000 Subject: [issue25718] itertools.accumulate __reduce__/__setstate__ bug In-Reply-To: <1448352443.54.0.731172452763.issue25718@psf.upfronthosting.co.za> Message-ID: <1448383045.96.0.529815931388.issue25718@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +patch Added file: http://bugs.python.org/file41151/copy_state_is_false.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 11:46:05 2015 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 24 Nov 2015 16:46:05 +0000 Subject: [issue20923] ConfigParser should nested [] in section names. In-Reply-To: <1394806905.89.0.637343755468.issue20923@psf.upfronthosting.co.za> Message-ID: <1448383565.95.0.703644048033.issue20923@psf.upfronthosting.co.za> Mark Lawrence added the comment: Why the debate on an issue that was closed over 18 months ago? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 12:22:01 2015 From: report at bugs.python.org (Steve Dower) Date: Tue, 24 Nov 2015 17:22:01 +0000 Subject: [issue25715] Python 3.5.1 installer shows wrong upgrade path In-Reply-To: <1448310282.68.0.27697601288.issue25715@psf.upfronthosting.co.za> Message-ID: <1448385721.6.0.373033438457.issue25715@psf.upfronthosting.co.za> Steve Dower added the comment: Fix attached: * moves the UI update to the correct time (*after* we've detected the path) * fixes a launcher detection issue I noticed * removes a duplicated function ---------- keywords: +patch Added file: http://bugs.python.org/file41152/25715_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 12:43:56 2015 From: report at bugs.python.org (Hans Lawrenz) Date: Tue, 24 Nov 2015 17:43:56 +0000 Subject: [issue25717] tempfile.TemporaryFile fails when dir option set to directory residing on host OS mount In-Reply-To: <1448339024.55.0.65158482353.issue25717@psf.upfronthosting.co.za> Message-ID: <1448387036.17.0.136927579197.issue25717@psf.upfronthosting.co.za> Hans Lawrenz added the comment: Serhiy and Emanuel, I'll paste below the surrounding code and attach the exact tempfile.py. It is the version distributed with the 3.5.0 release. If you take a look at the github repo I linked in the first comment you can also try it out for yourself if you've got vagrant and virtualbox installed. I was able to recreate the error with the provisioning compiling python and with it installing from a ppa. You can see the details in the Vagrantfile. I also had a coworker test in a nearly identical environment and he had the same result. (fd, name) = _mkstemp_inner(dir, prefix, suffix, flags, output_type) try: _os.unlink(name) return _io.open(fd, mode, buffering=buffering, newline=newline, encoding=encoding) except: _os.close(fd) raise One final note. I decided to try this out with a windows host and the only clarity this test adds is that the problem doesn't show up there but it fails for its own reasons on all the python versions I tried. See below for reference: Last login: Tue Nov 24 17:16:12 2015 from 10.0.2.2 vagrant at vagrant-ubuntu-trusty-64:~$ cat /vagrant/foo.py import tempfile with tempfile.TemporaryFile(dir="/vagrant") as tf: tf.write("testing testing testing\n".encode('utf-8')) print("Path 2: worked") vagrant at vagrant-ubuntu-trusty-64:~$ python /vagrant/foo.py Traceback (most recent call last): File "/vagrant/foo.py", line 4, in with tempfile.TemporaryFile(dir="/vagrant") as tf: File "/usr/lib/python2.7/tempfile.py", line 495, in TemporaryFile _os.unlink(name) OSError: [Errno 26] Text file busy: '/vagrant/tmpvx7Mie' vagrant at vagrant-ubuntu-trusty-64:~$ python2.7 /vagrant/foo.py Traceback (most recent call last): File "/vagrant/foo.py", line 4, in with tempfile.TemporaryFile(dir="/vagrant") as tf: File "/usr/lib/python2.7/tempfile.py", line 495, in TemporaryFile _os.unlink(name) OSError: [Errno 26] Text file busy: '/vagrant/tmpNXQ6Cf' vagrant at vagrant-ubuntu-trusty-64:~$ python3.4 /vagrant/foo.py Traceback (most recent call last): File "/vagrant/foo.py", line 4, in with tempfile.TemporaryFile(dir="/vagrant") as tf: File "/usr/lib/python3.4/tempfile.py", line 638, in TemporaryFile _os.unlink(name) OSError: [Errno 26] Text file busy: '/vagrant/tmpfwhj7ip4' vagrant at vagrant-ubuntu-trusty-64:~$ python3.5 /vagrant/foo.py Traceback (most recent call last): File "/vagrant/foo.py", line 4, in with tempfile.TemporaryFile(dir="/vagrant") as tf: File "/usr/lib/python3.5/tempfile.py", line 751, in TemporaryFile _os.unlink(name) OSError: [Errno 26] Text file busy: '/vagrant/tmp02s19r_a' vagrant at vagrant-ubuntu-trusty-64:~$ python2.7 --version Python 2.7.6 vagrant at vagrant-ubuntu-trusty-64:~$ python3.4 --version Python 3.4.3 vagrant at vagrant-ubuntu-trusty-64:~$ python3.5 --version Python 3.5.0 ---------- Added file: http://bugs.python.org/file41153/tempfile.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 13:55:28 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 24 Nov 2015 18:55:28 +0000 Subject: [issue25701] Document that tp_setattro and tp_setattr are used for deleting attributes In-Reply-To: <1448261904.1.0.459120146493.issue25701@psf.upfronthosting.co.za> Message-ID: <1448391328.69.0.699158735144.issue25701@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Martin. In general the patch LGTM, but I'm not expert in English writing. There are other functions and slots with twofold purpose: PyObject_SetItem, PySequence_SetItem, PySequence_SetSlice, PyMapping_SetItemString, PySequenceMethods.sq_ass_item, PyMappingMethods.mp_ass_subscript. May be address them in this issue? I'm not sure about documenting the deletion for PyObject_SetAttr and like. All these functions have Del-counterpart. Deleting by Set-function with NULL may be a side effect and be deprecated in future. May be worth to discuss this on Python-Dev. For PySys_SetObject the deletion if value is NULL already is documented, but there is no PySys_DelObject. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 14:06:27 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 24 Nov 2015 19:06:27 +0000 Subject: [issue25717] tempfile.TemporaryFile fails when dir option set to directory residing on host OS mount In-Reply-To: <1448339024.55.0.65158482353.issue25717@psf.upfronthosting.co.za> Message-ID: <1448391987.1.0.899872991039.issue25717@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Is your file system NFS? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 14:24:32 2015 From: report at bugs.python.org (Brett Cannon) Date: Tue, 24 Nov 2015 19:24:32 +0000 Subject: [issue25721] Fix pybench always_display error In-Reply-To: <1448366783.46.0.677910180147.issue25721@psf.upfronthosting.co.za> Message-ID: <1448393072.09.0.328464589617.issue25721@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- type: crash -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 14:32:36 2015 From: report at bugs.python.org (Brett Cannon) Date: Tue, 24 Nov 2015 19:32:36 +0000 Subject: [issue25712] Dead link in the PEP-3147 In-Reply-To: <20151123164034.GF15060@sg1> Message-ID: <1448393556.44.0.664847003255.issue25712@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- assignee: -> brett.cannon nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 14:38:21 2015 From: report at bugs.python.org (Emanuel Barry) Date: Tue, 24 Nov 2015 19:38:21 +0000 Subject: [issue25717] tempfile.TemporaryFile fails when dir option set to directory residing on host OS mount In-Reply-To: <1448339024.55.0.65158482353.issue25717@psf.upfronthosting.co.za> Message-ID: <1448393901.71.0.262767495394.issue25717@psf.upfronthosting.co.za> Emanuel Barry added the comment: Your file has a lot of shenanigans that are triggered if 'shutil' fails to be imported, adding an extra 139 lines at the top of the file, which is exactly how offset your traceback is compared to our lines. The rest of the file is virtually identical. This makes me wonder, however, why you have these differences (and that this might not be the only different file). I would still like the output of sys.version, which, unlike 'python --version' contains the build date and time, among other things. Bonus points for the 'sys.implementation' output. It's unlikely to be of relevance, but I would rather explore every possibility. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 14:40:55 2015 From: report at bugs.python.org (Hans Lawrenz) Date: Tue, 24 Nov 2015 19:40:55 +0000 Subject: [issue25717] tempfile.TemporaryFile fails when dir option set to directory residing on host OS mount In-Reply-To: <1448339024.55.0.65158482353.issue25717@psf.upfronthosting.co.za> Message-ID: <1448394055.15.0.14853861313.issue25717@psf.upfronthosting.co.za> Hans Lawrenz added the comment: The file system causing the problem is of type vboxsf which is the Virtualbox shared folder file system type. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 14:58:27 2015 From: report at bugs.python.org (Hans Lawrenz) Date: Tue, 24 Nov 2015 19:58:27 +0000 Subject: [issue25717] tempfile.TemporaryFile fails when dir option set to directory residing on host OS mount In-Reply-To: <1448339024.55.0.65158482353.issue25717@psf.upfronthosting.co.za> Message-ID: <1448395107.25.0.357740379494.issue25717@psf.upfronthosting.co.za> Hans Lawrenz added the comment: Emanuel, sorry, I missed the request for sys.version earlier. The tempfile.py I attached earlier is from the python 3.5 pulled from a ppa. I wouldn't be surprised if it has some patches applied by debian/ubuntu. To be clear though the problem also presents itself with a python 3.5 I compiled. The Vagrantfile in the github repository shows exactly how I compiled it. Here it is from the version from the ppa: Python 3.5.0 (default, Sep 17 2015, 00:00:00) [GCC 4.8.4] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.version '3.5.0 (default, Sep 17 2015, 00:00:00) \n[GCC 4.8.4]' >>> sys.implementation namespace(_multiarch='x86_64-linux-gnu', cache_tag='cpython-35', hexversion=50659568, name='cpython', version=sys.version_info(major=3, minor=5, micro=0, releaselevel='final', serial=0)) Here are the same for the version I compiled: vagrant at vagrant-ubuntu-trusty-64:~$ python3.5 Python 3.5.0 (default, Nov 24 2015, 19:50:42) [GCC 4.8.4] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.version '3.5.0 (default, Nov 24 2015, 19:50:42) \n[GCC 4.8.4]' >>> sys.implementation namespace(cache_tag='cpython-35', hexversion=50659568, name='cpython', version=sys.version_info(major=3, minor=5, micro=0, releaselevel='final', serial=0)) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 15:49:41 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 24 Nov 2015 20:49:41 +0000 Subject: [issue25725] Memory leak on unpickling bogus data Message-ID: <1448398181.68.0.540062768953.issue25725@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: New tests added in issue23914 exposed memory leak on unpickling TUPLE1..TUPLE3 opcodes with insufficient stack. Proposed patch fixes the leak. ---------- assignee: serhiy.storchaka components: Library (Lib) keywords: patch messages: 255289 nosy: alexandre.vassalotti, pitrou, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Memory leak on unpickling bogus data type: resource usage versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file41154/load_counted_tuple_leak.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 15:50:19 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 24 Nov 2015 20:50:19 +0000 Subject: [issue25725] Memory leak on unpickling bogus data In-Reply-To: <1448398181.68.0.540062768953.issue25725@psf.upfronthosting.co.za> Message-ID: <1448398219.1.0.430764793391.issue25725@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 15:51:45 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 24 Nov 2015 20:51:45 +0000 Subject: [issue25725] Memory leak on unpickling bogus data In-Reply-To: <1448398181.68.0.540062768953.issue25725@psf.upfronthosting.co.za> Message-ID: <1448398305.19.0.457729184027.issue25725@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: $ ./python -m test.regrtest -R 3:3 -m test_bad_stack test_pickle [1/1] test_pickle beginning 6 repetitions 123456 ...... test_pickle leaked [20, 20, 20] references, sum=60 test_pickle leaked [12, 14, 14] memory blocks, sum=40 1 test failed: test_pickle ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 16:04:06 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 24 Nov 2015 21:04:06 +0000 Subject: [issue25701] Document that tp_setattro and tp_setattr are used for deleting attributes In-Reply-To: <1448261904.1.0.459120146493.issue25701@psf.upfronthosting.co.za> Message-ID: <1448399046.71.0.824985145053.issue25701@psf.upfronthosting.co.za> Martin Panter added the comment: I agree it might be safer not to document that PyObject_SetAttr etc can delete (move that change to the tp_setattro etc method slot). I?ll also review the other functions you mentioned when I get a chance. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 17:10:46 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 24 Nov 2015 22:10:46 +0000 Subject: [issue25717] tempfile.TemporaryFile fails when dir option set to directory residing on host OS mount In-Reply-To: <1448339024.55.0.65158482353.issue25717@psf.upfronthosting.co.za> Message-ID: <1448403046.13.0.755873874803.issue25717@psf.upfronthosting.co.za> Martin Panter added the comment: This patch restores the previous behaviour of tolerating fstat() failures other than EBADF. Hans, if you are able to apply it to your compiled version of Python, it might prove that my fstat() theory is correct. ---------- keywords: +patch Added file: http://bugs.python.org/file41155/fstat-failure.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 17:16:03 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 24 Nov 2015 22:16:03 +0000 Subject: [issue25717] tempfile.TemporaryFile fails when dir option set to directory residing on host OS mount In-Reply-To: <1448339024.55.0.65158482353.issue25717@psf.upfronthosting.co.za> Message-ID: <1448403363.42.0.535373296598.issue25717@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 17:17:10 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 24 Nov 2015 22:17:10 +0000 Subject: [issue25695] test___all__ and test_support alter execution environment In-Reply-To: <1448182737.98.0.235138945354.issue25695@psf.upfronthosting.co.za> Message-ID: <20151124221704.81854.45421@psf.io> Roundup Robot added the comment: New changeset fb72d6d7703c by Martin Panter in branch 'default': Issue #25695: Defer creation of TESTDIRN until the test case is run https://hg.python.org/cpython/rev/fb72d6d7703c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 17:37:36 2015 From: report at bugs.python.org (Steve Dower) Date: Tue, 24 Nov 2015 22:37:36 +0000 Subject: [issue25715] Python 3.5.1 installer shows wrong upgrade path In-Reply-To: <1448310282.68.0.27697601288.issue25715@psf.upfronthosting.co.za> Message-ID: <1448404656.26.0.881419864219.issue25715@psf.upfronthosting.co.za> Steve Dower added the comment: Launcher detection still isn't quite right - another patch coming. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 17:42:31 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 24 Nov 2015 22:42:31 +0000 Subject: [issue25725] Memory leak on unpickling bogus data In-Reply-To: <1448398181.68.0.540062768953.issue25725@psf.upfronthosting.co.za> Message-ID: <1448404951.18.0.0489954082579.issue25725@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh... I didn't notice that you wrote a patch :-) I started to write a similar patch: see attached pickle.patch. ---------- Added file: http://bugs.python.org/file41156/pickle.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 17:44:24 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 24 Nov 2015 22:44:24 +0000 Subject: [issue25695] test___all__ and test_support alter execution environment In-Reply-To: <1448182737.98.0.235138945354.issue25695@psf.upfronthosting.co.za> Message-ID: <1448405064.0.0.0928690279552.issue25695@psf.upfronthosting.co.za> Martin Panter added the comment: This should be fixed now. Thanks for the report Arfrever and the analysis Ghost. I still get these warnings, but they are discussed in Issue 18383: Warning -- warnings.filters was modified by test___all__ Warning -- warnings.filters was modified by test_warnings ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 17:45:12 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 24 Nov 2015 22:45:12 +0000 Subject: [issue25725] Memory leak on unpickling bogus data In-Reply-To: <1448398181.68.0.540062768953.issue25725@psf.upfronthosting.co.za> Message-ID: <1448405112.5.0.874930777522.issue25725@psf.upfronthosting.co.za> STINNER Victor added the comment: I reviewed load_counted_tuple_leak.patch. Forget my patch, Serhiy's patch is better. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 17:49:06 2015 From: report at bugs.python.org (Vinay Sajip) Date: Tue, 24 Nov 2015 22:49:06 +0000 Subject: [issue25664] Unexpected UnicodeDecodeError in logging module In-Reply-To: <1447911382.32.0.466398267316.issue25664@psf.upfronthosting.co.za> Message-ID: <1448405346.91.0.950313216769.issue25664@psf.upfronthosting.co.za> Vinay Sajip added the comment: I cannot reproduce, see below. Which exact version of Python are you using, and on what platform, and with what locale? $ more logtest9.py # coding=utf-8 import logging logger = logging.getLogger(u'??') logger.error(u'??') $ python2.7 logtest9.py No handlers could be found for logger "??" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 18:03:12 2015 From: report at bugs.python.org (Vinay Sajip) Date: Tue, 24 Nov 2015 23:03:12 +0000 Subject: [issue25668] Deadlock in logging caused by a possible race condition with "format" In-Reply-To: <1447942973.46.0.788007678714.issue25668@psf.upfronthosting.co.za> Message-ID: <1448406192.11.0.819635226067.issue25668@psf.upfronthosting.co.za> Vinay Sajip added the comment: handle() and emit() are high level methods of a handler, and format() is at a lower level. Not all emit() methods will call format(). For example, socket-based and queue-based handlers don't. So it is not in general possible to separate format() out - you will need to have a customised handler to deal with your somewhat unusual use case, and do whatever you need in there. Threading is a complex area and while logging is one specific case you may have come across, it's entirely possible to have a situation with any other lock (e.g. in your application) where acquiring the lock and calling __unicode__() on one of your objects will also result in a deadlock. So your proposal wouldn't fix the problem in a general way - just move it so that you might avoid the problem, but a more esoteric use of locks wouldn't necessarily work. In general, to avoid deadlocks, you have to acquire locks in a fixed order, and only you know what those locks are - so you can implement the appropriate acquisition and release code in your handle(). ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 18:03:24 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 24 Nov 2015 23:03:24 +0000 Subject: [issue25725] Memory leak on unpickling bogus data In-Reply-To: <1448398181.68.0.540062768953.issue25725@psf.upfronthosting.co.za> Message-ID: <1448406204.32.0.268590213296.issue25725@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: You patch is just the first version of my patch. :-) But tests are crashed with it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 18:04:27 2015 From: report at bugs.python.org (Stefan Seefeld) Date: Tue, 24 Nov 2015 23:04:27 +0000 Subject: [issue25726] sys.setprofile / sys.getprofile asymetry Message-ID: <1448406267.14.0.484592445826.issue25726@psf.upfronthosting.co.za> New submission from Stefan Seefeld: I'm using the `cProfile` module to profile my code. I tried to temporarily disable the profiler by using: prof = sys.getprofile() sys.setprofile(None) ... sys.setprofile(prof) resulting in an error. The reason is that with `cProfile`, `sys.getprofile` returns the profile object itself, which isn't suitable as argument for `sys.setprofile` (which expects a callable). Notice that if I use the `profile` module instead of `cProfile`, the above works fine. ---------- messages: 255301 nosy: stefan priority: normal severity: normal status: open title: sys.setprofile / sys.getprofile asymetry type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 18:07:24 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 24 Nov 2015 23:07:24 +0000 Subject: =?utf-8?q?=5Bissue25576=5D_Remove_=E2=80=9CContent-Type=3A_application/x-?= =?utf-8?q?www-form-urlencoded=3B_charset=E2=80=9D_advice?= In-Reply-To: <1446885820.73.0.0514095635951.issue25576@psf.upfronthosting.co.za> Message-ID: <20151124230720.29819.62271@psf.io> Roundup Robot added the comment: New changeset 16fec577fd8b by Martin Panter in branch '3.4': Issue #25576: Remove application/x-www-form-urlencoded charset advice https://hg.python.org/cpython/rev/16fec577fd8b New changeset 95ae5262d27c by Martin Panter in branch '3.5': Issue #25576: Merge www-form-urlencoded doc from 3.4 into 3.5 https://hg.python.org/cpython/rev/95ae5262d27c New changeset d52521d13a64 by Martin Panter in branch 'default': Issue #25576: Merge www-form-urlencoded doc from 3.5 https://hg.python.org/cpython/rev/d52521d13a64 New changeset 671429cc1d96 by Martin Panter in branch 'default': Issue #25576: Apply fix to new urlopen() doc string https://hg.python.org/cpython/rev/671429cc1d96 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 18:24:33 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 24 Nov 2015 23:24:33 +0000 Subject: [issue25508] LogRecord attributes are not tuple, when logging only dict In-Reply-To: <1446114122.71.0.187409652652.issue25508@psf.upfronthosting.co.za> Message-ID: <20151124232429.22378.75891@psf.io> Roundup Robot added the comment: New changeset a365fb0dd5e1 by Vinay Sajip in branch '2.7': Issue #25508: Clarify documentation on LogRecord args attribute. https://hg.python.org/cpython/rev/a365fb0dd5e1 New changeset 01998efb605a by Vinay Sajip in branch '3.4': Issue #25508: Clarify documentation on LogRecord args attribute. https://hg.python.org/cpython/rev/01998efb605a New changeset ca512b568368 by Vinay Sajip in branch '3.5': Issue #25508: Merged documentation fix from 3.4. https://hg.python.org/cpython/rev/ca512b568368 New changeset 1da622f4630b by Vinay Sajip in branch 'default': Closes #25508: Merged documentation fix from 3.5. https://hg.python.org/cpython/rev/1da622f4630b ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 18:37:00 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 24 Nov 2015 23:37:00 +0000 Subject: [issue20923] ConfigParser should nested [] in section names. In-Reply-To: <1394806905.89.0.637343755468.issue20923@psf.upfronthosting.co.za> Message-ID: <1448408220.9.0.150519052999.issue20923@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Discussion continues because my close message was, I now realize, incomplete and therefore unsatisfying. Ditto for the doc. So I complete my close message here and reopen issue to augment the doc. The discussion has so far has glossed over the key question: "What is a legal section name?" Pulling the answer from the doc was a challenge. It uses 'legal section name', once, as if one should already know. Reading further, I found the answer: there is no (fixed) answer! The legal section name for a particular parser is determined by its .SECTCRE class attribute. '''configparser.SECTCRE A compiled regular expression used to parse section headers. The default matches [section] to the name "section".''' (This neglects to say whether the closing ']' is the first or last ']' on the line after the opening '['.) A non-verbose version of the default is re.compile(r"\[(?P
[^]]+)\]"). I propose adding near the top of the doc: "By default, a legal section name can be any string that does not contain '\n' or ']'. To change this, see configparser.SECTCRE." So my response to Milo? should have been to set SECTCRE to something like p below. >>> p = re.compile(r"\[(?P
.*)\]") >>> m = p.search("[Test[2]_foo]") >>> m.group('header') 'Test[2]_foo' Additional note: Postel's principle was formulated for internet protocols, which .ini files are not. In any case, it is not a Python design principle. Neither is "always check user input", which amounts to 'look before you leap'. So I will not debate these. However, "Errors should never pass silently." is #10 on the Zen of Python ('import this') and that I do attend to. ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python resolution: rejected -> stage: test needed -> needs patch status: closed -> open versions: +Python 2.7, Python 3.4, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 18:38:26 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 24 Nov 2015 23:38:26 +0000 Subject: =?utf-8?q?=5Bissue25576=5D_Remove_=E2=80=9CContent-Type=3A_application/x-?= =?utf-8?q?www-form-urlencoded=3B_charset=E2=80=9D_advice?= In-Reply-To: <1446885820.73.0.0514095635951.issue25576@psf.upfronthosting.co.za> Message-ID: <1448408306.48.0.933078892995.issue25576@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 18:42:09 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 24 Nov 2015 23:42:09 +0000 Subject: [issue25723] ConfigParser should never write broken configurations In-Reply-To: <1448379104.29.0.433011869224.issue25723@psf.upfronthosting.co.za> Message-ID: <1448408529.44.0.485560612364.issue25723@psf.upfronthosting.co.za> Terry J. Reedy added the comment: This strikes me as an overt bug. .add_section should add one new empty section, not a section with an item and a second section. Since a section name cannot contain \n, I would agree that passing a string containing \n should raise ValueError("Section names cannot contain newlines."). Since anything else without ']' is valid and since even that can be accommodated with a custom section name re, that is the only check that should be done. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 18:46:04 2015 From: report at bugs.python.org (Elizabeth Myers) Date: Tue, 24 Nov 2015 23:46:04 +0000 Subject: [issue25727] os.startfile implementation for other OS'es besides Windows Message-ID: <1448408764.04.0.983609943062.issue25727@psf.upfronthosting.co.za> New submission from Elizabeth Myers: os.startfile can be implemented on other OS'es besides Windows relatively easily (although the operation parameter should probably be limited to Windows; it can be implemented elsewhere, but is probably not worth the trouble). On Unix-like operating systems besides OS X, an attempt to use xdg-open can be used and will attempt to open the file in a chosen program; this is the freedesktop.org standard open utility. See also http://linux.die.net/man/1/xdg-open and https://wiki.archlinux.org/index.php/Xdg-open (not specific to ArchLinux). On OS X, open can be used, with similar results to xdg-open (in fact, xdg-open seems inspired by it). See also https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/open.1.html. ---------- components: Library (Lib) messages: 255306 nosy: Elizacat priority: normal severity: normal status: open title: os.startfile implementation for other OS'es besides Windows type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 18:57:41 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 24 Nov 2015 23:57:41 +0000 Subject: [issue25727] os.startfile implementation for other OS'es besides Windows In-Reply-To: <1448408764.04.0.983609943062.issue25727@psf.upfronthosting.co.za> Message-ID: <1448409461.76.0.609347723093.issue25727@psf.upfronthosting.co.za> R. David Murray added the comment: Duplicate of Issue 3177, which has quite a bit of discussion and some patch proposals. You might want to add yourself as nosy to that issue and see what you think of the proposals (I did not read through it to see what the status is...there hasn't been any activity on it for a long time, so it is ripe for someone new to pick it up and carry it forward). ---------- nosy: +r.david.murray resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Add shutil.open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 19:00:17 2015 From: report at bugs.python.org (Tom F) Date: Wed, 25 Nov 2015 00:00:17 +0000 Subject: [issue16198] IDLE - tabbing in a string always brings up file completion window In-Reply-To: <1349974121.21.0.319562901545.issue16198@psf.upfronthosting.co.za> Message-ID: <1448409617.1.0.50361218951.issue16198@psf.upfronthosting.co.za> Tom F added the comment: I've found this to be annoying as well especially in docstrings, hopefully this will help in the meantime. If you SHIFT + Tab it will at least resolve the problem of bringing up files and remains as the usual tab function. It makes me wonder if it is a bug at all though? ---------- nosy: +Tom F _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 19:04:36 2015 From: report at bugs.python.org (Forest) Date: Wed, 25 Nov 2015 00:04:36 +0000 Subject: [issue25728] email parser ignores inner multipart boundary when outer message duplicates it Message-ID: <1448409876.66.0.930152855615.issue25728@psf.upfronthosting.co.za> New submission from Forest: When a multipart message erroneously defines a boundary string that conflicts with an inner message's boundary string, the parser ignores the (correct) inner message's boundary, and treats all matching boundary lines as if they belong to the (defective) outer message. This file from the test_email suite demonstrates the problem: Python-3.5.0/Lib/test/test_email/data/msg_15.txt Consequentially, the inner multipart/alternative message is parsed with is_multipart() returning False, and a truncated payload. Moreover, unit tests like test_same_boundary_inner_outer() expect to find the StartBoundaryNotFoundDefect defect on the inner message in that file, which seems wrong to me, since the inner message is not defective. According to the RFCs, the outer message should have been generated with a boundary string that does not appear anywhere in its encoded body (including the inner message). The outer message is therefore the defective one. ---------- components: email messages: 255309 nosy: barry, forest, r.david.murray priority: normal severity: normal status: open title: email parser ignores inner multipart boundary when outer message duplicates it type: behavior versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 19:18:47 2015 From: report at bugs.python.org (Forest) Date: Wed, 25 Nov 2015 00:18:47 +0000 Subject: [issue25728] email parser ignores inner multipart boundary when outer message duplicates it In-Reply-To: <1448409876.66.0.930152855615.issue25728@psf.upfronthosting.co.za> Message-ID: <1448410727.13.0.786461636539.issue25728@psf.upfronthosting.co.za> Forest added the comment: I thought at first that this might be deliberate behavior in order to comply with RFC 2046 section 5.1.2. https://tools.ietf.org/html/rfc2046#section-5.1.2 After carefully re-reading that section, I see that it is just making sure an outer message's boundary will still be recognized if an inner multipart message is missing its boundary markers (for example if the inner message was truncated). It does not describe any circumstances under which the inner message's boundary markers should be ignored when they are present. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 19:21:19 2015 From: report at bugs.python.org (Elizabeth Myers) Date: Wed, 25 Nov 2015 00:21:19 +0000 Subject: [issue25727] os.startfile implementation for other OS'es besides Windows In-Reply-To: <1448408764.04.0.983609943062.issue25727@psf.upfronthosting.co.za> Message-ID: <1448410879.66.0.266078009879.issue25727@psf.upfronthosting.co.za> Elizabeth Myers added the comment: I'm not going to reopen that can of worms. Sorry to waste your time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 19:39:29 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 25 Nov 2015 00:39:29 +0000 Subject: [issue25728] email parser ignores inner multipart boundary when outer message duplicates it In-Reply-To: <1448409876.66.0.930152855615.issue25728@psf.upfronthosting.co.za> Message-ID: <1448411969.69.0.317097203826.issue25728@psf.upfronthosting.co.za> R. David Murray added the comment: Who is to say that the outer message is defective and not the inner one? How can a parser decide which part belongs to which message? It isn't an AI. The whole message is defective, so all bets are off :) The library can't successfully parse such a message, though it goes to significant pains to make sure it never generates one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 20:05:43 2015 From: report at bugs.python.org (Forest) Date: Wed, 25 Nov 2015 01:05:43 +0000 Subject: [issue25728] email parser ignores inner multipart boundary when outer message duplicates it In-Reply-To: <1448409876.66.0.930152855615.issue25728@psf.upfronthosting.co.za> Message-ID: <1448413543.42.0.139096589659.issue25728@psf.upfronthosting.co.za> Forest added the comment: RFC 2046 says that the outer message is defective, since it uses a boundary delimiter that is quite obviously present inside one of the encapsulated parts: https://tools.ietf.org/html/rfc2046#section-5.1 "The boundary delimiter MUST NOT appear inside any of the encapsulated parts, on a line by itself or as the prefix of any line." ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 20:08:51 2015 From: report at bugs.python.org (Forest) Date: Wed, 25 Nov 2015 01:08:51 +0000 Subject: [issue25728] email parser ignores inner multipart boundary when outer message duplicates it In-Reply-To: <1448409876.66.0.930152855615.issue25728@psf.upfronthosting.co.za> Message-ID: <1448413731.14.0.406118207956.issue25728@psf.upfronthosting.co.za> Forest added the comment: > The library can't successfully parse such a message It could successfully parse such a message, if it matched against inner message boundaries before outer message boundaries. (One implementation would be to keep a list of all ancestor boundaries and traverse the list from most recent to least recent, but there might be more efficient ways to do it.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 21:23:57 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 25 Nov 2015 02:23:57 +0000 Subject: [issue25300] Enable Intel MPX (Memory protection Extensions) feature In-Reply-To: <1443788737.62.0.174147088714.issue25300@psf.upfronthosting.co.za> Message-ID: <1448418237.94.0.522686116952.issue25300@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I'm wary of making such extensive changes throughout the codebase for an optional processor-specific feature of limited benefit and unproven worth. With each new macro and trick (Py_VARIABLE_SIZE and Py_INIT_BOUNDS), we make it harder for people to read, create, and maintain our code. The barrier to entry is getting too high IMO. If this were just a makefile change, it would be different. But it touches a lot of code in ways that will be unfamiliar looking to most C programmers: Py_ssize_t ob_array[1] Py_VARIABLE_SIZE; /* Looks weird and confusing */ A surprising number of files are being modified: --- a/Include/asdl.h Mon Nov 02 09:17:08 2015 -0800 --- a/Include/bytesobject.h Mon Nov 02 09:17:08 2015 -0800 --- a/Include/frameobject.h Mon Nov 02 09:17:08 2015 -0800 --- a/Include/longintrepr.h Mon Nov 02 09:17:08 2015 -0800 --- a/Include/memoryobject.h Mon Nov 02 09:17:08 2015 -0800 --- a/Include/object.h Mon Nov 02 09:17:08 2015 -0800 --- a/Include/objimpl.h Mon Nov 02 09:17:08 2015 -0800 --- a/Include/pyport.h Mon Nov 02 09:17:08 2015 -0800 --- a/Include/tupleobject.h Mon Nov 02 09:17:08 2015 -0800 --- a/Makefile.pre.in Mon Nov 02 09:17:08 2015 -0800 --- a/Modules/_ctypes/ctypes.h Mon Nov 02 09:17:08 2015 -0800 --- a/Modules/_tracemalloc.c Mon Nov 02 09:17:08 2015 -0800 --- a/Modules/expat/xmlparse.c Mon Nov 02 09:17:08 2015 -0800 --- a/Modules/mathmodule.c Mon Nov 02 09:17:08 2015 -0800 --- a/Modules/sre.h Mon Nov 02 09:17:08 2015 -0800 --- a/Modules/sre_lib.h Mon Nov 02 09:17:08 2015 -0800 --- a/Modules/winreparse.h Mon Nov 02 09:17:08 2015 -0800 --- a/Objects/dict-common.h Mon Nov 02 09:17:08 2015 -0800 --- a/Objects/dictobject.c Mon Nov 02 09:17:08 2015 -0800 --- a/Objects/listobject.c Mon Nov 02 09:17:08 2015 -0800 --- a/Objects/longobject.c Mon Nov 02 09:17:08 2015 -0800 --- a/Objects/memoryobject.c Mon Nov 02 09:17:08 2015 -0800 --- a/Objects/object.c Mon Nov 02 09:17:08 2015 -0800 --- a/Objects/obmalloc.c Mon Nov 02 09:17:08 2015 -0800 --- a/Objects/typeobject.c Mon Nov 02 09:17:08 2015 -0800 --- a/Objects/unicodeobject.c Mon Nov 02 09:17:08 2015 -0800 --- a/Parser/grammar.c Mon Nov 02 09:17:08 2015 -0800 --- a/Python/ast.c Mon Nov 02 09:17:08 2015 -0800 --- a/Python/dtoa.c Mon Nov 02 09:17:08 2015 -0800 --- a/Python/pyhash.c Mon Nov 02 09:17:08 2015 -0800 --- a/configure Mon Nov 02 09:17:08 2015 -0800 --- a/configure.ac Mon Nov 02 09:17:08 2015 -0800 --- a/pyconfig.h.in Mon Nov 02 09:17:08 2015 -0800 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 21:24:57 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 25 Nov 2015 02:24:57 +0000 Subject: [issue10796] Improve doc for readline.set_completer_delims() In-Reply-To: <1293714489.48.0.717157988045.issue10796@psf.upfronthosting.co.za> Message-ID: <1448418297.46.0.274935488516.issue10796@psf.upfronthosting.co.za> Martin Panter added the comment: I propose to address this with the general documentation bug, Issue 6953 ---------- dependencies: +readline documenation needs work nosy: +martin.panter title: readline completion flaw -> Improve doc for readline.set_completer_delims() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 22:15:16 2015 From: report at bugs.python.org (Zephor Wu) Date: Wed, 25 Nov 2015 03:15:16 +0000 Subject: [issue25664] Unexpected UnicodeDecodeError in logging module In-Reply-To: <1447911382.32.0.466398267316.issue25664@psf.upfronthosting.co.za> Message-ID: <1448421316.68.0.861540124983.issue25664@psf.upfronthosting.co.za> Zephor Wu added the comment: sorry, i forgot this: logging.basicConfig(format='%(name)s %(message)s') the error raised at the processing of the format while the name is 'utf-8' encoded and the message is an unicode ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 22:16:49 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 25 Nov 2015 03:16:49 +0000 Subject: [issue6953] readline documenation needs work In-Reply-To: <1253456012.32.0.661240289209.issue6953@psf.upfronthosting.co.za> Message-ID: <1448421409.86.0.499443749977.issue6953@psf.upfronthosting.co.za> Martin Panter added the comment: This patch addresses the following points: 1: Moved add_history() into new ?History file? section with related functions. 2: Documented that remove_ and replace_history_item() are zero-based. 3: Documented that get_history_item() is one-based. 4: Listed the main underlying Readline function or variable that each Python function accesses. In many cases it should be fairly obvious because the name is essentially the same, but not always. I added them all for consistency. 5: Added six new sections to group functions: Init file, Line buffer, History file, History list, Startup hooks, and Completer. 7: Clarify that the parse_and_bind() line comes directly from the string argument, not a file. 8: Changed ?command line? to ?line buffer?. 9: read_init_file() also executes the bindings it reads; it does not return anything. 10: read_history_file() appends to the history list, contrary to what Andy suggested. 11: write_history_file() overwrites any existing file, and writes the history list 12: clear_history() is conditionally compiled in 13: Combined get_ and set_history_length() entries 14: Differentiated lines in the history file from history list items, which can be multi-line if an item includes a line break. 15: Added brief description of word completion in the new section. Entry get_completion_type() refers to the rl_completion_type variable, so it should be refer back to the Gnu documentation. Referred beginning and ending indexes to the corresponding callback arguments (these are affected by Issue 16182). Suggested that the word delimiters determine the word completion scope. 16: Whether libedit (Editline) is used or not really only depends on the -lreadline library at run time (out of Python?s hands). I clarified that its detection is what is implemented on OS X. See also Issue 13501 for expanding this support. Another change: 17: Expanded information on setting up the completion word delimiters for a custom completer, to address Issue 10796. Not addressed in my patch: 6: Init file information. May be better to just refer to the Gnu documentation and Editline documentation (does this exist?). 8: I do not know what ?the last filename used? means for read_init_file(). It passes a null pointer as the filename in this case. I suspect the answer may actually be it uses the INPUTRC config file instead. 12: I do not know what Readline version clear_history() is available in. Anyway, this might vary between Gnu and Editline implementations. ---------- keywords: +patch nosy: +martin.panter Added file: http://bugs.python.org/file41157/readline-doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 22:17:20 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 25 Nov 2015 03:17:20 +0000 Subject: [issue6953] readline documenation needs work In-Reply-To: <1253456012.32.0.661240289209.issue6953@psf.upfronthosting.co.za> Message-ID: <1448421440.87.0.728959087968.issue6953@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- stage: -> patch review versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 22:28:25 2015 From: report at bugs.python.org (Zephor Wu) Date: Wed, 25 Nov 2015 03:28:25 +0000 Subject: [issue25664] Unexpected UnicodeDecodeError in logging module In-Reply-To: <1447911382.32.0.466398267316.issue25664@psf.upfronthosting.co.za> Message-ID: <1448422105.19.0.929880129746.issue25664@psf.upfronthosting.co.za> Zephor Wu added the comment: here is the case, sorry again for just typing it before and not testing it myself :) # coding=utf-8 import logging logging.basicConfig(format='%(name)s %(message)s') logger = logging.getLogger(u'??') logger.error(u'??') btw, i'm using python2.7.10, mac osx 10.11, but i think this can effect all python2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 00:31:33 2015 From: report at bugs.python.org (Zachary Ware) Date: Wed, 25 Nov 2015 05:31:33 +0000 Subject: [issue25705] Fix regex_compile benchmark crash In-Reply-To: <1448283925.8.0.456132903966.issue25705@psf.upfronthosting.co.za> Message-ID: <1448429493.03.0.895507686964.issue25705@psf.upfronthosting.co.za> Zachary Ware added the comment: Fixed in f7283190e896. I had actually already fixed this in my sandbox repo for speed.python.org; I just went ahead and pushed it (and a couple other very minor changes) to the main benchmark repo. Thanks for the report and patch! ---------- nosy: +zach.ware resolution: -> fixed stage: -> resolved status: open -> closed versions: -Python 2.7, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 00:39:43 2015 From: report at bugs.python.org (Zachary Ware) Date: Wed, 25 Nov 2015 05:39:43 +0000 Subject: [issue25719] Deprecate spitfire benchmark In-Reply-To: <1448362459.17.0.918374944074.issue25719@psf.upfronthosting.co.za> Message-ID: <1448429983.74.0.251967536734.issue25719@psf.upfronthosting.co.za> Zachary Ware added the comment: +1 Unless anybody else objects in the next couple days, I'll commit this. ---------- nosy: +zach.ware stage: -> commit review versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 02:52:26 2015 From: report at bugs.python.org (Brian Kearns) Date: Wed, 25 Nov 2015 07:52:26 +0000 Subject: [issue25729] update pure python datetime.timedelta creation Message-ID: <1448437946.34.0.869547453804.issue25729@psf.upfronthosting.co.za> New submission from Brian Kearns: Brings timedelta creation up to par with the (simpler) C equivalent. Gives a nice speed boost on the pure-py version (not worth much on CPython but useful on other implementations like PyPy). Included in a few other small bug fixes/cleanups, should be self-explanatory. ---------- files: timedelta.patch keywords: patch messages: 255322 nosy: bdkearns priority: normal severity: normal status: open title: update pure python datetime.timedelta creation versions: Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file41158/timedelta.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 02:52:27 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 25 Nov 2015 07:52:27 +0000 Subject: [issue25664] Unexpected UnicodeDecodeError in logging module In-Reply-To: <1447911382.32.0.466398267316.issue25664@psf.upfronthosting.co.za> Message-ID: <1448437947.9.0.404447093489.issue25664@psf.upfronthosting.co.za> STINNER Victor added the comment: $ cat x.py # coding=utf-8 import logging logging.basicConfig(format='%(name)s %(message)s') logger = logging.getLogger(u'??') logger.error(u'??') $ python2.7 x.py Traceback (most recent call last): File "/usr/lib64/python2.7/logging/__init__.py", line 859, in emit msg = self.format(record) File "/usr/lib64/python2.7/logging/__init__.py", line 732, in format return fmt.format(record) File "/usr/lib64/python2.7/logging/__init__.py", line 474, in format s = self._fmt % record.__dict__ UnicodeDecodeError: 'ascii' codec can't decode byte 0xe6 in position 0: ordinal not in range(128) Logged from file x.py, line 8 ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 02:57:38 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 25 Nov 2015 07:57:38 +0000 Subject: [issue25723] ConfigParser should never write broken configurations In-Reply-To: <1448379104.29.0.433011869224.issue25723@psf.upfronthosting.co.za> Message-ID: <1448438258.47.0.694056318336.issue25723@psf.upfronthosting.co.za> STINNER Victor added the comment: Terry: "Since anything else without ']' is valid (...)" A Python script can be used to generate a configuration read by another application. This application can more more strict on the configuration format than Python, so I would prefer to deny '\n', '[' and ']' characters in section names. I'm not sure that it's ok to modify Python < 3.6 since it can break applications relying on this ugly "feature". I propose to only modify Python 3.6. If you need strict ConfigParser, you can inherit from the class to override add_section() to add checks on the section name. @SpaceOne: Are you interested to work on a patch? ---------- nosy: +haypo versions: -Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 02:59:09 2015 From: report at bugs.python.org (Brian Kearns) Date: Wed, 25 Nov 2015 07:59:09 +0000 Subject: [issue25729] update pure python datetime.timedelta creation In-Reply-To: <1448437946.34.0.869547453804.issue25729@psf.upfronthosting.co.za> Message-ID: <1448438349.52.0.937022723353.issue25729@psf.upfronthosting.co.za> Changes by Brian Kearns : Removed file: http://bugs.python.org/file41158/timedelta.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 02:59:27 2015 From: report at bugs.python.org (Brian Kearns) Date: Wed, 25 Nov 2015 07:59:27 +0000 Subject: [issue25729] update pure python datetime.timedelta creation In-Reply-To: <1448437946.34.0.869547453804.issue25729@psf.upfronthosting.co.za> Message-ID: <1448438367.38.0.989040697986.issue25729@psf.upfronthosting.co.za> Changes by Brian Kearns : Added file: http://bugs.python.org/file41159/timedelta.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 02:59:57 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 25 Nov 2015 07:59:57 +0000 Subject: [issue20923] ConfigParser should nested [] in section names. In-Reply-To: <1394806905.89.0.637343755468.issue20923@psf.upfronthosting.co.za> Message-ID: <1448438397.88.0.780007780961.issue20923@psf.upfronthosting.co.za> STINNER Victor added the comment: > It would be good if ConfigParser supported angled brackets in section names by being greedy when parsing. I agree with Terry, it's the opposite: we must explicitly reject them to be compatible with other applications. Please move the discussion to issue #25723. ---------- nosy: +haypo resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 03:00:16 2015 From: report at bugs.python.org (Brian Kearns) Date: Wed, 25 Nov 2015 08:00:16 +0000 Subject: [issue25729] update pure python datetime.timedelta creation In-Reply-To: <1448437946.34.0.869547453804.issue25729@psf.upfronthosting.co.za> Message-ID: <1448438416.98.0.229370861999.issue25729@psf.upfronthosting.co.za> Changes by Brian Kearns : Removed file: http://bugs.python.org/file41159/timedelta.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 03:04:14 2015 From: report at bugs.python.org (Brian Kearns) Date: Wed, 25 Nov 2015 08:04:14 +0000 Subject: [issue25729] update pure python datetime.timedelta creation In-Reply-To: <1448437946.34.0.869547453804.issue25729@psf.upfronthosting.co.za> Message-ID: <1448438654.24.0.727446570631.issue25729@psf.upfronthosting.co.za> Brian Kearns added the comment: Correct patch uploaded ---------- Added file: http://bugs.python.org/file41160/timedelta.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 03:40:38 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Nov 2015 08:40:38 +0000 Subject: [issue25729] update pure python datetime.timedelta creation In-Reply-To: <1448437946.34.0.869547453804.issue25729@psf.upfronthosting.co.za> Message-ID: <1448440838.2.0.809470186833.issue25729@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Does the patch fixes any bugs? If no, it can be applied only to developed version. If yes, needed tests. ---------- components: +Library (Lib) nosy: +belopolsky, serhiy.storchaka stage: -> patch review type: -> enhancement versions: -Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 04:56:22 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 25 Nov 2015 09:56:22 +0000 Subject: [issue25712] Dead link in the PEP-3147 In-Reply-To: <20151123164034.GF15060@sg1> Message-ID: <20151125095620.654.69256@psf.io> Roundup Robot added the comment: New changeset a34df6445747 by Victor Stinner in branch 'default': Issue #25712: Fix link to the marshal doc in PEP 3147 https://hg.python.org/peps/rev/a34df6445747 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 04:57:05 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 25 Nov 2015 09:57:05 +0000 Subject: [issue25712] Dead link in the PEP-3147 In-Reply-To: <20151123164034.GF15060@sg1> Message-ID: <1448445425.97.0.733821662039.issue25712@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 04:59:06 2015 From: report at bugs.python.org (Armin Rigo) Date: Wed, 25 Nov 2015 09:59:06 +0000 Subject: [issue25718] itertools.accumulate __reduce__/__setstate__ bug In-Reply-To: <1448352443.54.0.731172452763.issue25718@psf.upfronthosting.co.za> Message-ID: <1448445546.73.0.377434581403.issue25718@psf.upfronthosting.co.za> Armin Rigo added the comment: Ok, then with pickle you can have the same problem but only with None-vs-no-total. Here is an artificial example: import itertools, pickle def foo(a, b): print(a, b) a = itertools.accumulate([3, 4, 5], foo) next(a) next(a) # prints: 3, 4 b = pickle.loads(pickle.dumps(a)) next(a) # prints: None, 5 next(b) # foo() is not called at all ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 05:23:43 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 25 Nov 2015 10:23:43 +0000 Subject: [issue25721] Fix pybench always_display error In-Reply-To: <1448366783.46.0.677910180147.issue25721@psf.upfronthosting.co.za> Message-ID: <1448447023.2.0.0858235389828.issue25721@psf.upfronthosting.co.za> STINNER Victor added the comment: Thanks for your bug report. I fixed the issue differently, by adding a base class to benchmark result classes. I also implemented the format output format for pybench. By the way, perf.py badly handles errors :-/ CSV output and table output fail to handle errors. pybench output with my change: ******************* $ ./perf.py -f -r -b pybench python2.7 python2.7 (...) ### pybench ### Min: 285 -> 284: 1.00x faster Avg: 289 -> 292: 1.01x slower $ ./perf.py -f --csv=pybench.csv -r -b pybench python2.7 python2.7 (...) ### pybench ### Min: 283 -> 286: 1.01x slower Avg: 287 -> 290: 1.01x slower $ cat pybench.csv Benchmark,Base,Changed pybench,283.000000,286.000000 $ ./perf.py -f -O table -r -b pybench python2.7 python2.7 (...) +-----------+-----------+-----------+--------------+ | Benchmark | python2.7 | python2.7 | Change | +===========+===========+===========+==============+ | pybench | 288.0 | 289.0 | 1.00x slower | +-----------+-----------+-----------+--------------+ ******************* ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 05:23:51 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 25 Nov 2015 10:23:51 +0000 Subject: [issue25721] Fix pybench always_display error In-Reply-To: <1448366783.46.0.677910180147.issue25721@psf.upfronthosting.co.za> Message-ID: <20151125102348.31391.90535@psf.io> Roundup Robot added the comment: New changeset e77ed7d18a68 by Victor Stinner in branch 'default': Issue #25721: Fixes for pybench https://hg.python.org/benchmarks/rev/e77ed7d18a68 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 05:24:19 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 25 Nov 2015 10:24:19 +0000 Subject: [issue25721] Fix pybench always_display error In-Reply-To: <1448366783.46.0.677910180147.issue25721@psf.upfronthosting.co.za> Message-ID: <1448447059.33.0.674349222627.issue25721@psf.upfronthosting.co.za> STINNER Victor added the comment: Is it ok for you Florin? (Can I close the issue?) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 05:27:07 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 25 Nov 2015 10:27:07 +0000 Subject: [issue25300] Enable Intel MPX (Memory protection Extensions) feature In-Reply-To: <1448418237.94.0.522686116952.issue25300@psf.upfronthosting.co.za> Message-ID: <56558CF6.1010800@free.fr> Antoine Pitrou added the comment: Le 25/11/2015 03:23, Raymond Hettinger a ?crit : > > I'm wary of making such extensive changes throughout the codebase > for > an optional processor-specific feature of limited benefit and unproven > worth. This is indeed non-trivial. What I'm willing to known is if it helps detect unknown bugs and vulnerabilities in the code base (for example when running the test suite or sample workloads). The Py_VARIABLE_SIZE macro is trivial to understand, and is actually a useful annotation to the code (a kind of executable documentation). The BOUNDS macros are a bit more interesting, but their semantics look simple if you don't want to think too much about the underlying HW implementation :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 05:47:41 2015 From: report at bugs.python.org (hiroaki itoh) Date: Wed, 25 Nov 2015 10:47:41 +0000 Subject: [issue25730] invisible sidebar content with code snippets Message-ID: <1448448461.72.0.524937822108.issue25730@psf.upfronthosting.co.za> New submission from hiroaki itoh: I think this is maybe known problem, but checking duplication of this issue is very hard because searching it with keyword 'sidebar' hit too many. Please see details in https://bitbucket.org/hhsprings/nothing.but.only.for.some.kind.of.collabo/wiki/%5Bdocs.python.org%5D%20invisible%20sidebar%20content%20with%20code%20snippets . I think, this can be fixed by inserting style overriding background to default.css. ---------- messages: 255334 nosy: xwhhsprings priority: normal severity: normal status: open title: invisible sidebar content with code snippets versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 06:00:00 2015 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 25 Nov 2015 11:00:00 +0000 Subject: [issue25730] invisible sidebar content with code snippets In-Reply-To: <1448448461.72.0.524937822108.issue25730@psf.upfronthosting.co.za> Message-ID: <1448449200.8.0.0686439754041.issue25730@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python, ezio.melotti, georg.brandl, terry.reedy stage: -> needs patch type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 06:14:36 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Nov 2015 11:14:36 +0000 Subject: [issue25701] Document that tp_setattro and tp_setattr are used for deleting attributes In-Reply-To: <1448261904.1.0.459120146493.issue25701@psf.upfronthosting.co.za> Message-ID: <1448450076.03.0.822217500855.issue25701@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Python-Dev discussion: http://comments.gmane.org/gmane.comp.python.devel/155474 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 06:23:53 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Nov 2015 11:23:53 +0000 Subject: [issue25718] itertools.accumulate __reduce__/__setstate__ bug In-Reply-To: <1448352443.54.0.731172452763.issue25718@psf.upfronthosting.co.za> Message-ID: <1448450633.71.0.413220433898.issue25718@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: In this case yes, you are unlucky. But this is an artificial example, and I don't think this happens in any real code. However specific meaning of None should be documented (there are other wrong words about __getstate__). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 07:29:50 2015 From: report at bugs.python.org (=?utf-8?q?Stanis=C5=82aw_Skonieczny_=28Uosiu=29?=) Date: Wed, 25 Nov 2015 12:29:50 +0000 Subject: [issue25731] Assigning and deleting __new__ attr on the class does not allow to create instances of this class Message-ID: <1448454590.41.0.350843358205.issue25731@psf.upfronthosting.co.za> New submission from Stanis?aw Skonieczny (Uosiu): When moving from python 2.7 to 3.5 I have found a problem with patching __new__ method on the class. It was done this way: ''' patch('foo.bar.MyClass.__new__', return_value=mocked_instance) ''' In works with python 2.7, but in 3.5 it fails with: ''' TypeError: object() takes no parameters ''' I have created minimal scenario that ilustrates this bug cause: ''' class X: def __init__(self, a): pass def new(cls, a): pass X(1) X.__new__ = new X(1) del X.__new__ X(1) ''' Setting __new__ attribute and then deleting it has some side effect. ---------- components: Interpreter Core files: new_patch_fails.py messages: 255337 nosy: Stanis?aw Skonieczny (Uosiu) priority: normal severity: normal status: open title: Assigning and deleting __new__ attr on the class does not allow to create instances of this class type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file41161/new_patch_fails.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 08:08:53 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 25 Nov 2015 13:08:53 +0000 Subject: [issue25725] Memory leak on unpickling bogus data In-Reply-To: <1448398181.68.0.540062768953.issue25725@psf.upfronthosting.co.za> Message-ID: <20151125130814.87881.57345@psf.io> Roundup Robot added the comment: New changeset c85eca74f3a5 by Serhiy Storchaka in branch '3.4': Issue #25725: Fixed a reference leak in pickle.loads() when unpickling https://hg.python.org/cpython/rev/c85eca74f3a5 New changeset 88ad2b8480b1 by Serhiy Storchaka in branch '3.5': Issue #25725: Fixed a reference leak in pickle.loads() when unpickling https://hg.python.org/cpython/rev/88ad2b8480b1 New changeset 935debb548a3 by Serhiy Storchaka in branch 'default': Issue #25725: Fixed a reference leak in pickle.loads() when unpickling https://hg.python.org/cpython/rev/935debb548a3 New changeset 9a4db1ac5e10 by Serhiy Storchaka in branch '2.7': Issue #25725: Fixed a reference leak in cPickle.loads() when unpickling https://hg.python.org/cpython/rev/9a4db1ac5e10 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 08:09:28 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Nov 2015 13:09:28 +0000 Subject: [issue25725] Memory leak on unpickling bogus data In-Reply-To: <1448398181.68.0.540062768953.issue25725@psf.upfronthosting.co.za> Message-ID: <1448456968.72.0.722916443507.issue25725@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 08:12:49 2015 From: report at bugs.python.org (David Seddon) Date: Wed, 25 Nov 2015 13:12:49 +0000 Subject: [issue25732] functools.total_ordering does not correctly implement not equal behaviour Message-ID: <1448457169.16.0.121144285875.issue25732@psf.upfronthosting.co.za> New submission from David Seddon: The documentation for functools.total_ordering states that rich comparison can be enabled on a class by specifying an __eq__ method, and one of __lt__(), __le__(), __gt__(), or __ge__(). If these instructions are followed, this results in an incorrect evaluation of the not equal operator: Here's an example: from functools import total_ordering @total_ordering class Value(object): def __init__(self, value): self.value = value def __eq__(self, other): return self.value == other.value def __lt__(self, other): return self.value < other.value >>> a = Value(3) >>> b = Value(3) >>> a == b True >>> a != b True I've tested this on 2.7.10. Either the documentation or the behaviour should be corrected. https://docs.python.org/2/library/functools.html#functools.total_ordering ---------- messages: 255339 nosy: David Seddon priority: normal severity: normal status: open title: functools.total_ordering does not correctly implement not equal behaviour type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 08:20:10 2015 From: report at bugs.python.org (Florin Papa) Date: Wed, 25 Nov 2015 13:20:10 +0000 Subject: [issue25721] Fix pybench always_display error In-Reply-To: <1448366783.46.0.677910180147.issue25721@psf.upfronthosting.co.za> Message-ID: <1448457610.63.0.334846427313.issue25721@psf.upfronthosting.co.za> Florin Papa added the comment: Yes, thank you for fixing this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 08:22:28 2015 From: report at bugs.python.org (Florin Papa) Date: Wed, 25 Nov 2015 13:22:28 +0000 Subject: [issue25705] Fix regex_compile benchmark crash In-Reply-To: <1448283925.8.0.456132903966.issue25705@psf.upfronthosting.co.za> Message-ID: <1448457747.99.0.618332847217.issue25705@psf.upfronthosting.co.za> Florin Papa added the comment: No problem. Thank you for fixing this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 08:24:11 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 25 Nov 2015 13:24:11 +0000 Subject: [issue25572] _ssl doesn't build on OSX 10.11 In-Reply-To: <1446845399.36.0.0648529481801.issue25572@psf.upfronthosting.co.za> Message-ID: <1448457851.14.0.78097242527.issue25572@psf.upfronthosting.co.za> STINNER Victor added the comment: > Homebrew supports OpenSSL and LibreSSL, but OpenSSL is in /usr/local/opt/openssl and not in /usr/local/ssl (see setup.py) Does it make sense to add a configure option to specify the path to OpenSSL? > So, the next point, I am not sure, but the headers of OpenSSL has not provided with OSX 10.11 Is it possible or not to get headers of the OpenSSL system library? ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 08:27:17 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 25 Nov 2015 13:27:17 +0000 Subject: [issue21224] BaseHTTPRequestHandler, update the protocol version to http 1.1 by default? In-Reply-To: <1397508232.09.0.0337317788686.issue21224@psf.upfronthosting.co.za> Message-ID: <1448458037.92.0.230793012179.issue21224@psf.upfronthosting.co.za> STINNER Victor added the comment: For HTTP 2, I consider that the protocol is too young. I prefer to move fast on a library hosted on PyPI, rather than puting something is the stable and "frozen" stdlib. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 08:29:21 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 25 Nov 2015 13:29:21 +0000 Subject: [issue7990] xml.etree.cElementTree lacks full dir() on Element In-Reply-To: <1266856563.54.0.534391635456.issue7990@psf.upfronthosting.co.za> Message-ID: <20151125132850.81858.54390@psf.io> Roundup Robot added the comment: New changeset fef7f041c1a7 by Serhiy Storchaka in branch 'default': Issue #7990: dir() on ElementTree.Element now lists properties: "tag", https://hg.python.org/cpython/rev/fef7f041c1a7 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 08:29:41 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 25 Nov 2015 13:29:41 +0000 Subject: [issue21224] BaseHTTPRequestHandler, update the protocol version to http 1.1 by default? In-Reply-To: <1397508232.09.0.0337317788686.issue21224@psf.upfronthosting.co.za> Message-ID: <1448458181.13.0.458532495733.issue21224@psf.upfronthosting.co.za> STINNER Victor added the comment: > Similarly, I understand HTTP 1.1 requires chunked encoding support for requests, but there is no support for that in the Python implementation. Hum, I don't understand exactly this issue. I understood that Python only has a "partial" implementation of the HTTP 1.1 protocol for the server side, and maybe even for the client side. Because of that, I don't think that it's good idea to switch to HTTP 1.1 by default. We have to implement missing features server and client side before. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 08:30:41 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Nov 2015 13:30:41 +0000 Subject: [issue7990] xml.etree.cElementTree lacks full dir() on Element In-Reply-To: <1266856563.54.0.534391635456.issue7990@psf.upfronthosting.co.za> Message-ID: <1448458241.64.0.145677783483.issue7990@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Martin. Committed with both your suggestions. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 08:30:58 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 25 Nov 2015 13:30:58 +0000 Subject: [issue25571] Improve the lltrace feature with the Py_Debug mode In-Reply-To: <1446844426.01.0.118649403374.issue25571@psf.upfronthosting.co.za> Message-ID: <1448458258.94.0.190212300113.issue25571@psf.upfronthosting.co.za> STINNER Victor added the comment: What is lltrace? I never used it :-( Is it documented? Can you give examples of output before/after? We may make your change optional to give the choice of the output. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 08:32:45 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 25 Nov 2015 13:32:45 +0000 Subject: [issue21475] Support the Sitemap extension in robotparser In-Reply-To: <1399858557.27.0.633505879036.issue21475@psf.upfronthosting.co.za> Message-ID: <1448458365.54.0.407549716751.issue21475@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- dependencies: +Rewrite test_robotparser _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 08:38:49 2015 From: report at bugs.python.org (Emanuel Barry) Date: Wed, 25 Nov 2015 13:38:49 +0000 Subject: [issue25683] __context__ for yields inside except clause In-Reply-To: <1448036986.79.0.682793402944.issue25683@psf.upfronthosting.co.za> Message-ID: <1448458729.77.0.14461902711.issue25683@psf.upfronthosting.co.za> Emanuel Barry added the comment: This is due to the fact that Python 3 added the ability to define only __eq__ and get a free __ne__ defined. If my memory serves me right, functools.total_ordering was added in 3.2 and then backported to 2.x - where the relationship with __eq__ and __ne__ is not present. total_ordering doesn't do anything to touch __ne__ as it expects Python itself to do so (which it doesn't in 2.x). ---------- nosy: +ebarry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 08:39:24 2015 From: report at bugs.python.org (Emanuel Barry) Date: Wed, 25 Nov 2015 13:39:24 +0000 Subject: [issue25683] __context__ for yields inside except clause In-Reply-To: <1448036986.79.0.682793402944.issue25683@psf.upfronthosting.co.za> Message-ID: <1448458764.81.0.0282514818745.issue25683@psf.upfronthosting.co.za> Emanuel Barry added the comment: Oops, that was *completely* the wrong issue. I apologize for the noise. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 08:39:44 2015 From: report at bugs.python.org (Emanuel Barry) Date: Wed, 25 Nov 2015 13:39:44 +0000 Subject: [issue25732] functools.total_ordering does not correctly implement not equal behaviour In-Reply-To: <1448457169.16.0.121144285875.issue25732@psf.upfronthosting.co.za> Message-ID: <1448458784.25.0.248750701927.issue25732@psf.upfronthosting.co.za> Emanuel Barry added the comment: This is due to the fact that Python 3 added the ability to define only __eq__ and get a free __ne__ defined. If my memory serves me right, functools.total_ordering was added in 3.2 and then backported to 2.x - where the relationship with __eq__ and __ne__ is not present. total_ordering doesn't do anything to touch __ne__ as it expects Python itself to do so (which it doesn't in 2.x). ---------- nosy: +ebarry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 08:56:49 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 25 Nov 2015 13:56:49 +0000 Subject: [issue24731] Incorrect assert in str_subtype_new In-Reply-To: <1437952885.56.0.72690112679.issue24731@psf.upfronthosting.co.za> Message-ID: <20151125135646.658.67282@psf.io> Roundup Robot added the comment: New changeset d8e0b54ece62 by Serhiy Storchaka in branch '3.4': Issue #24731: Fixed crash on converting objects with special methods https://hg.python.org/cpython/rev/d8e0b54ece62 New changeset 80efe5cc8934 by Serhiy Storchaka in branch '3.5': Issue #24731: Fixed crash on converting objects with special methods https://hg.python.org/cpython/rev/80efe5cc8934 New changeset 1c4d256cc370 by Serhiy Storchaka in branch 'default': Issue #24731: Fixed crash on converting objects with special methods https://hg.python.org/cpython/rev/1c4d256cc370 New changeset 37158c067b25 by Serhiy Storchaka in branch '2.7': Issue #24731: Fixed crash on converting objects with special methods https://hg.python.org/cpython/rev/37158c067b25 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 08:57:02 2015 From: report at bugs.python.org (Hans Lawrenz) Date: Wed, 25 Nov 2015 13:57:02 +0000 Subject: [issue25717] tempfile.TemporaryFile fails when dir option set to directory residing on host OS mount In-Reply-To: <1448339024.55.0.65158482353.issue25717@psf.upfronthosting.co.za> Message-ID: <1448459822.34.0.060031444316.issue25717@psf.upfronthosting.co.za> Hans Lawrenz added the comment: Martin, I applied your patch and it proved your hypothesis. See below for how I tested. I also updated the github repo for others to reproduce if they wish. cd wget https://www.python.org/ftp/python/3.5.0/Python-3.5.0.tar.xz mkdir ~/dist cd ~/dist tar xJf ~/Python-3.5.0.tar.xz cd Python-3.5.0 ./configure --prefix=/home/vagrant/py35/dist && \ make && make install mkdir ~/patch cd ~/patch tar xJf ~/Python-3.5.0.tar.xz cd Python-3.5.0 patch -p1 < /vagrant/fstat-failure.patch ./configure --prefix=/home/vagrant/py35/patch && \ make && make install vagrant at vagrant-ubuntu-trusty-64:~$ ./py35/dist/bin/python3.5 /vagrant/temptest.py Path 1: worked Path 2: ERROR vagrant at vagrant-ubuntu-trusty-64:~$ ./py35/patch/bin/python3.5 /vagrant/temptest.py Path 1: worked Path 2: worked ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 08:57:54 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Nov 2015 13:57:54 +0000 Subject: [issue24731] Incorrect assert in str_subtype_new In-Reply-To: <1437952885.56.0.72690112679.issue24731@psf.upfronthosting.co.za> Message-ID: <1448459874.02.0.790871144556.issue24731@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 09:03:14 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Nov 2015 14:03:14 +0000 Subject: [issue25732] functools.total_ordering does not correctly implement not equal behaviour In-Reply-To: <1448457169.16.0.121144285875.issue25732@psf.upfronthosting.co.za> Message-ID: <1448460194.02.0.0579610307569.issue25732@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Library (Lib) nosy: +ncoghlan, rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 09:14:30 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 25 Nov 2015 14:14:30 +0000 Subject: [issue25697] Fix rough alphabetical order in Misc/ACKS In-Reply-To: <1448207088.07.0.222703830715.issue25697@psf.upfronthosting.co.za> Message-ID: <20151125141421.13413.24609@psf.io> Roundup Robot added the comment: New changeset 68c7c6ac82d9 by Serhiy Storchaka in branch '3.4': Issue #25697: Fixed rough alphabetical order in Misc/ACKS. https://hg.python.org/cpython/rev/68c7c6ac82d9 New changeset 9925fb41c1d9 by Serhiy Storchaka in branch '3.5': Issue #25697: Fixed rough alphabetical order in Misc/ACKS. https://hg.python.org/cpython/rev/9925fb41c1d9 New changeset e61a864b703c by Serhiy Storchaka in branch 'default': Issue #25697: Fixed rough alphabetical order in Misc/ACKS. https://hg.python.org/cpython/rev/e61a864b703c New changeset 8bdf8e7dd085 by Serhiy Storchaka in branch '2.7': Issue #25697: Fixed rough alphabetical order in Misc/ACKS. https://hg.python.org/cpython/rev/8bdf8e7dd085 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 09:17:06 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Nov 2015 14:17:06 +0000 Subject: [issue25697] Fix rough alphabetical order in Misc/ACKS In-Reply-To: <1448207088.07.0.222703830715.issue25697@psf.upfronthosting.co.za> Message-ID: <1448461026.21.0.306691424403.issue25697@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your review Martin. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 2.7, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 09:17:10 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 25 Nov 2015 14:17:10 +0000 Subject: [issue25643] Python tokenizer rewriting In-Reply-To: <1447723653.14.0.424824913135.issue25643@psf.upfronthosting.co.za> Message-ID: <1448461030.47.0.279490207527.issue25643@psf.upfronthosting.co.za> STINNER Victor added the comment: "especially for issues with null byte" I don't think that we should put to much energy in handling correctly NUL bytes. I see NUL bytes in code as bugs in the code, not in the Python parser. We *might* try to give warnings or better error messages to the user, that's all. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 09:20:26 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 25 Nov 2015 14:20:26 +0000 Subject: [issue25703] test_sys is failed if standard stream is redirected in 2.7 In-Reply-To: <1448271347.53.0.201659881218.issue25703@psf.upfronthosting.co.za> Message-ID: <20151125142023.670.46582@psf.io> Roundup Robot added the comment: New changeset eb9d2e5bc8dc by Serhiy Storchaka in branch '2.7': Issue #25703: Skip test_43581 if one of stdout or stderr is redirected. https://hg.python.org/cpython/rev/eb9d2e5bc8dc ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 09:20:42 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Nov 2015 14:20:42 +0000 Subject: [issue25703] test_sys is failed if standard stream is redirected in 2.7 In-Reply-To: <1448271347.53.0.201659881218.issue25703@psf.upfronthosting.co.za> Message-ID: <1448461242.82.0.0190645101252.issue25703@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 09:21:32 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 25 Nov 2015 14:21:32 +0000 Subject: [issue25721] Fix pybench always_display error In-Reply-To: <1448366783.46.0.677910180147.issue25721@psf.upfronthosting.co.za> Message-ID: <1448461292.96.0.365705942553.issue25721@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 09:22:24 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 25 Nov 2015 14:22:24 +0000 Subject: [issue25728] email parser ignores inner multipart boundary when outer message duplicates it In-Reply-To: <1448409876.66.0.930152855615.issue25728@psf.upfronthosting.co.za> Message-ID: <1448461344.49.0.928336144014.issue25728@psf.upfronthosting.co.za> R. David Murray added the comment: I am open to (and will review) a patch that applies simple heuristics to trying to guess correctly about such messages, but only if it doesn't add too much complexity to the parser. I'm not certain I would consider it for a bug fix release, but I'll postpone that decision until I review the patch (the issue is: would it have the potential to break applications that are currently working? I'm guessing not, but I tend to be cautious about such issues.) ---------- stage: -> needs patch versions: +Python 3.5, Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 09:26:38 2015 From: report at bugs.python.org (ppperry) Date: Wed, 25 Nov 2015 14:26:38 +0000 Subject: [issue25733] Idle does not handle non-standard compile errors Message-ID: <1448461598.38.0.392041411432.issue25733@psf.upfronthosting.co.za> New submission from ppperry: The following code: for a in range(26): for b in range(26): for c in range(26): for d in range(26): for e in range(26): for f in range(26): for g in range(26): for h in range(26): for i in range(26): for j in range(26): for k in range(26): for l in range(26): for m in range(26): for o in range(26): for p in range(26): for q in range(26): for r in range(26): for s in range(26): for t in range(26): for u in range(26): for v in range(26): for w in range(26): pass fails to compile with `SystemError: too many statically nested blocks` when typed in the standard interpreter. When typed in an IDLE shell , pressing enter will not try to run the code, instead printing the SystemError to the console from which idle was started, instead of to the IDLE shell, which would be expected. ---------- components: IDLE, Interpreter Core messages: 255358 nosy: ppperry priority: normal severity: normal status: open title: Idle does not handle non-standard compile errors versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 09:29:40 2015 From: report at bugs.python.org (ppperry) Date: Wed, 25 Nov 2015 14:29:40 +0000 Subject: [issue25733] Idle does not handle non-standard compile errors In-Reply-To: <1448461598.38.0.392041411432.issue25733@psf.upfronthosting.co.za> Message-ID: <1448461780.27.0.837659206758.issue25733@psf.upfronthosting.co.za> Changes by ppperry : ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 09:31:10 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 25 Nov 2015 14:31:10 +0000 Subject: [issue25696] "MAKEFLAGS=-j9 make install" fails because bininstall target requires the libainstall target In-Reply-To: <1448202702.88.0.964294450431.issue25696@psf.upfronthosting.co.za> Message-ID: <1448461870.32.0.476550670712.issue25696@psf.upfronthosting.co.za> STINNER Victor added the comment: To be clear: the bug doesn't occur when Python is not installed "in parallel" (without MAKEFLAGS=-j9). "For consistency with other things, I would suggest to add the following at the beginning of bininstall target (instead of making bininstall target depend on libainstall target):" Ok. Does my new patch look better? Should I apply my fix to Python 2.7, 3.4, 3.5 and default (3.6)? ---------- title: "make install" fails because bininstall target requires the libainstall target -> "MAKEFLAGS=-j9 make install" fails because bininstall target requires the libainstall target Added file: http://bugs.python.org/file41162/bininstall-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 09:31:54 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 25 Nov 2015 14:31:54 +0000 Subject: [issue25696] "make -j9 install" fails because bininstall target requires the libainstall target In-Reply-To: <1448202702.88.0.964294450431.issue25696@psf.upfronthosting.co.za> Message-ID: <1448461914.91.0.731148202797.issue25696@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: "MAKEFLAGS=-j9 make install" fails because bininstall target requires the libainstall target -> "make -j9 install" fails because bininstall target requires the libainstall target _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 09:42:22 2015 From: report at bugs.python.org (SpaceOne) Date: Wed, 25 Nov 2015 14:42:22 +0000 Subject: [issue25723] ConfigParser should never write broken configurations In-Reply-To: <1448379104.29.0.433011869224.issue25723@psf.upfronthosting.co.za> Message-ID: <1448462542.98.0.630624255976.issue25723@psf.upfronthosting.co.za> SpaceOne added the comment: I added also a rejection of '\r' and '\x00': https://github.com/spaceone/cpython/commit/41d6e278e4ffa95577d843e0d50d4c43b5ac46ef It's only my opinion but I would prefer to reject all of these non printable characters: '\x00\x01\x02\x03\x04\x05\x06\x07\x08\t\n\x0b\x0c\r\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f[]\x7f' But as the _parse currently detects them as valid and your opinion is probably a very different one I will not add these characters. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 09:43:46 2015 From: report at bugs.python.org (Alberto Galera) Date: Wed, 25 Nov 2015 14:43:46 +0000 Subject: [issue25734] fnmatch regular expression can be improved Message-ID: <1448462626.73.0.555480375618.issue25734@psf.upfronthosting.co.za> New submission from Alberto Galera: # https://hg.python.org/cpython/file/tip/Lib/fnmatch.py fnmatch reviewing the code I've noticed that the outcome of the regular expression all returns generated in the first result l97: res = res + '.*' to: res = res + '.*?' l100: return res + '\Z(?ms)' to: return res + '$(?ms)' example test: import re import fnmatch urls = ['example/l1/l2/test3-1.py', 'example/l1/test2-1.py', 'example/l1/test2-2.py', 'example/l1/l2/l3/test4-1.py'] regex = fnmatch.translate('example/*') # 'example\\/.*\\Z(?ms)' re.findall(regex, "\n".join(urls)) # return ['example/l1/l2/test3-1.py\nexample/l1/test2-1.py\nexample/l1/test2-2.py\nexample/l1/l2/l3/test4-1.py'] # suggested change re.findall('example\\/.*?$(?ms)', "\n".join(urls)) # return ['example/l1/l2/test3-1.py', # 'example/l1/test2-1.py', # 'example/l1/test2-2.py', # 'example/l1/l2/l3/test4-1.py'] ---------- components: Library (Lib) messages: 255361 nosy: Alberto Galera priority: normal severity: normal status: open title: fnmatch regular expression can be improved type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 09:44:08 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 25 Nov 2015 14:44:08 +0000 Subject: [issue25732] functools.total_ordering does not correctly implement not equal behaviour In-Reply-To: <1448457169.16.0.121144285875.issue25732@psf.upfronthosting.co.za> Message-ID: <1448462648.09.0.515049732994.issue25732@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 09:52:04 2015 From: report at bugs.python.org (Emanuel Barry) Date: Wed, 25 Nov 2015 14:52:04 +0000 Subject: [issue25732] functools.total_ordering does not correctly implement not equal behaviour In-Reply-To: <1448457169.16.0.121144285875.issue25732@psf.upfronthosting.co.za> Message-ID: <1448463124.3.0.950653010025.issue25732@psf.upfronthosting.co.za> Changes by Emanuel Barry : ---------- assignee: docs at python -> components: -Documentation nosy: -docs at python _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 10:06:27 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 25 Nov 2015 15:06:27 +0000 Subject: [issue25734] fnmatch regular expression can be improved In-Reply-To: <1448462626.73.0.555480375618.issue25734@psf.upfronthosting.co.za> Message-ID: <1448463987.66.0.539814366405.issue25734@psf.upfronthosting.co.za> R. David Murray added the comment: That would be a backward incompatible behavior change. The patterns are designed to be used on single filenames, not on newline separated filenames. ---------- nosy: +r.david.murray resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 10:10:02 2015 From: report at bugs.python.org (Chi Hsuan Yen) Date: Wed, 25 Nov 2015 15:10:02 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> Message-ID: <1448464202.3.0.537906535556.issue23496@psf.upfronthosting.co.za> Changes by Chi Hsuan Yen : ---------- nosy: +Chi Hsuan Yen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 10:12:44 2015 From: report at bugs.python.org (Chi Hsuan Yen) Date: Wed, 25 Nov 2015 15:12:44 +0000 Subject: [issue16255] subrocess.Popen needs /bin/sh but Android only has /system/bin/sh In-Reply-To: <1350421202.49.0.905467284446.issue16255@psf.upfronthosting.co.za> Message-ID: <1448464364.79.0.0913922271032.issue16255@psf.upfronthosting.co.za> Changes by Chi Hsuan Yen : ---------- nosy: +Chi Hsuan Yen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 10:13:26 2015 From: report at bugs.python.org (Chi Hsuan Yen) Date: Wed, 25 Nov 2015 15:13:26 +0000 Subject: [issue16353] add function to os module for getting path to default shell In-Reply-To: <1351473560.4.0.147895276383.issue16353@psf.upfronthosting.co.za> Message-ID: <1448464406.88.0.655877312714.issue16353@psf.upfronthosting.co.za> Changes by Chi Hsuan Yen : ---------- nosy: +Chi Hsuan Yen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 10:14:41 2015 From: report at bugs.python.org (Chi Hsuan Yen) Date: Wed, 25 Nov 2015 15:14:41 +0000 Subject: [issue22100] Use $HOSTPYTHON when determining candidate interpreter for $PYTHON_FOR_BUILD. In-Reply-To: <1406648042.0.0.0162670058613.issue22100@psf.upfronthosting.co.za> Message-ID: <1448464481.86.0.421035138148.issue22100@psf.upfronthosting.co.za> Changes by Chi Hsuan Yen : ---------- nosy: +Chi Hsuan Yen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 10:20:37 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Nov 2015 15:20:37 +0000 Subject: [issue25616] Extract OrderedDict tests into separate file In-Reply-To: <1447419681.57.0.354121086978.issue25616@psf.upfronthosting.co.za> Message-ID: <1448464837.58.0.807469003201.issue25616@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 10:20:38 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 25 Nov 2015 15:20:38 +0000 Subject: [issue25616] Extract OrderedDict tests into separate file In-Reply-To: <1447419681.57.0.354121086978.issue25616@psf.upfronthosting.co.za> Message-ID: <20151125151954.59391.41433@psf.io> Roundup Robot added the comment: New changeset 8d9a0540adf9 by Serhiy Storchaka in branch '3.4': Issue #25616: Tests for OrderedDict are extracted from test_collections https://hg.python.org/cpython/rev/8d9a0540adf9 New changeset 46e95e0eaae5 by Serhiy Storchaka in branch '3.5': Issue #25616: Tests for OrderedDict are extracted from test_collections https://hg.python.org/cpython/rev/46e95e0eaae5 New changeset 81fa901162f9 by Serhiy Storchaka in branch 'default': Issue #25616: Tests for OrderedDict are extracted from test_collections https://hg.python.org/cpython/rev/81fa901162f9 New changeset afaad8dc8edf by Serhiy Storchaka in branch '2.7': Issue #25616: Tests for OrderedDict are extracted from test_collections https://hg.python.org/cpython/rev/afaad8dc8edf ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 10:30:48 2015 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 25 Nov 2015 15:30:48 +0000 Subject: [issue25572] _ssl doesn't build on OSX 10.11 In-Reply-To: <1446845399.36.0.0648529481801.issue25572@psf.upfronthosting.co.za> Message-ID: <1448465448.25.0.633562287705.issue25572@psf.upfronthosting.co.za> Ronald Oussoren added the comment: Apple no longer ships headers for OpenSSL in OSX SDK as shipped with Xcode 7.1, and I'd be surprised if that changes (without having any inside knowledge about this). W.r.t. adding configure option for OpenSSL: That would be fine although that makes the detection of openssl even more convoluted that it currently is: there's also a search list in setup.py. In the long run its probably better to move all library detection code to configure. See also Issue8406, Issue7713 and possibly more. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 11:23:20 2015 From: report at bugs.python.org (Brett Cannon) Date: Wed, 25 Nov 2015 16:23:20 +0000 Subject: [issue25719] Deprecate spitfire benchmark In-Reply-To: <1448362459.17.0.918374944074.issue25719@psf.upfronthosting.co.za> Message-ID: <1448468600.24.0.0342751582501.issue25719@psf.upfronthosting.co.za> Brett Cannon added the comment: I don't object and I'm on vacation without my laptop so I won't beat you to committing it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 11:36:16 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 25 Nov 2015 16:36:16 +0000 Subject: [issue24097] Use after free in PyObject_GetState In-Reply-To: <1430489135.55.0.4914099481.issue24097@psf.upfronthosting.co.za> Message-ID: <20151125163603.81874.74467@psf.io> Roundup Robot added the comment: New changeset eed36e19f8b8 by Serhiy Storchaka in branch '3.4': Issue #24097: Fixed crash in object.__reduce__() if slot name is freed inside https://hg.python.org/cpython/rev/eed36e19f8b8 New changeset 99839a1c9c6d by Serhiy Storchaka in branch '3.5': Issue #24097: Fixed crash in object.__reduce__() if slot name is freed inside https://hg.python.org/cpython/rev/99839a1c9c6d New changeset 502465d22522 by Serhiy Storchaka in branch 'default': Issue #24097: Fixed crash in object.__reduce__() if slot name is freed inside https://hg.python.org/cpython/rev/502465d22522 New changeset 4a201d0d4d1e by Serhiy Storchaka in branch '2.7': Issue #24097: Fixed crash in object.__reduce__() if slot name is freed inside https://hg.python.org/cpython/rev/4a201d0d4d1e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 11:37:39 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Nov 2015 16:37:39 +0000 Subject: [issue24097] Use after free in PyObject_GetState In-Reply-To: <1430489135.55.0.4914099481.issue24097@psf.upfronthosting.co.za> Message-ID: <1448469459.52.0.867483523009.issue24097@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 11:54:31 2015 From: report at bugs.python.org (Hideaki Takahashi) Date: Wed, 25 Nov 2015 16:54:31 +0000 Subject: [issue6953] readline documenation needs work In-Reply-To: <1253456012.32.0.661240289209.issue6953@psf.upfronthosting.co.za> Message-ID: <1448470471.86.0.882585496974.issue6953@psf.upfronthosting.co.za> Changes by Hideaki Takahashi : ---------- nosy: +hideaki_t _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 12:24:06 2015 From: report at bugs.python.org (Brian Kearns) Date: Wed, 25 Nov 2015 17:24:06 +0000 Subject: [issue25729] update pure python datetime.timedelta creation In-Reply-To: <1448437946.34.0.869547453804.issue25729@psf.upfronthosting.co.za> Message-ID: <1448472246.97.0.648625071138.issue25729@psf.upfronthosting.co.za> Brian Kearns added the comment: Bug fixes are to the test suite itself, and the name cleanup, minor. Best classified as enhancement, apply where applicable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 12:26:24 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 25 Nov 2015 17:26:24 +0000 Subject: [issue20923] ConfigParser should nested [] in section names. In-Reply-To: <1394806905.89.0.637343755468.issue20923@psf.upfronthosting.co.za> Message-ID: <1448472384.97.0.0544069682988.issue20923@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Victor, I reopened this a a doc issue to add the sentence that would have cut short the discussion. Please leave it. ---------- resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 12:28:59 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 25 Nov 2015 17:28:59 +0000 Subject: [issue20923] ConfigParser should nested [] in section names. In-Reply-To: <1394806905.89.0.637343755468.issue20923@psf.upfronthosting.co.za> Message-ID: <1448472539.02.0.960386637651.issue20923@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- assignee: docs at python -> terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 12:31:23 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 25 Nov 2015 17:31:23 +0000 Subject: [issue20923] Explain ConfigParser 'valid section name' and .SECTCRE In-Reply-To: <1394806905.89.0.637343755468.issue20923@psf.upfronthosting.co.za> Message-ID: <1448472683.5.0.154726707173.issue20923@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- title: ConfigParser should nested [] in section names. -> Explain ConfigParser 'valid section name' and .SECTCRE _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 12:36:11 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 25 Nov 2015 17:36:11 +0000 Subject: [issue20923] Explain ConfigParser 'valid section name' and .SECTCRE In-Reply-To: <1394806905.89.0.637343755468.issue20923@psf.upfronthosting.co.za> Message-ID: <1448472971.91.0.879995243749.issue20923@psf.upfronthosting.co.za> R. David Murray added the comment: Yes, the doc issue is separate from the other bug, since that one will apply only to 3.6, and the doc changes apply to all maintenance releases. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 12:42:16 2015 From: report at bugs.python.org (Mark Lawrence) Date: Wed, 25 Nov 2015 17:42:16 +0000 Subject: [issue6953] readline documentation needs work In-Reply-To: <1253456012.32.0.661240289209.issue6953@psf.upfronthosting.co.za> Message-ID: <1448473336.09.0.548339843543.issue6953@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- title: readline documenation needs work -> readline documentation needs work _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 12:44:49 2015 From: report at bugs.python.org (Michael Layzell) Date: Wed, 25 Nov 2015 17:44:49 +0000 Subject: [issue25677] Syntax error caret confused by indentation In-Reply-To: <1447998656.06.0.471632717786.issue25677@psf.upfronthosting.co.za> Message-ID: <1448473489.12.0.895225234885.issue25677@psf.upfronthosting.co.za> Michael Layzell added the comment: Sorry for the delay, I finally got around to adding a test. I'm mildly concerned about the portability of the check, but it seems to work locally. If people have suggestions about how to make the check more portable, let me know! ---------- Added file: http://bugs.python.org/file41163/cpython25677.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 12:47:18 2015 From: report at bugs.python.org (Eryk Sun) Date: Wed, 25 Nov 2015 17:47:18 +0000 Subject: [issue25731] Assigning and deleting __new__ attr on the class does not allow to create instances of this class In-Reply-To: <1448454590.41.0.350843358205.issue25731@psf.upfronthosting.co.za> Message-ID: <1448473638.59.0.581945004588.issue25731@psf.upfronthosting.co.za> Eryk Sun added the comment: For "del X.__new__", type_setattro in Objects/typeobject.c indirectly calls update_one_slot. This finds object.__new__ fom the base object class when it looks up __new__ on the type. Since __new__ for built-in types is special-cased to be a built-in method instead of a slot wrapper, update_one_slot takes the branch for "Py_TYPE(descr) == &PyCFunction_Type", which assigns the existing tp_new to "specific". In this case that's slot_tp_new instead of object_new due to the previous assignment of the "new" function to X.__new__. slot_tp_new looks up and calls __new__, which in this case, as noted above, is object.__new__. This built-in method calls tp_new_wrapper, which calls the wrapped tp_new function. In this case that's object_new. If the type's tp_init is object_init (i.e. not overridden) or tp_new is not object_new (i.e. overridden), then object_new raises a TypeError when called with arguments. The problem in this case is that __new__ isn't overridden anymore. It seems to me that update_one_slot needs to install the tp_new that tp_new_wrapper would call, e.g. specific = (void *)( (PyTypeObject *)PyCFunction_GET_SELF(descr))->tp_new; In this case that's object_new. Thus after "del X.__new__", X would be restored as if __new__ was never overridden. ---------- nosy: +eryksun versions: +Python 2.7, Python 3.4, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 12:48:28 2015 From: report at bugs.python.org (Brian Kearns) Date: Wed, 25 Nov 2015 17:48:28 +0000 Subject: [issue25729] update pure python datetime.timedelta creation In-Reply-To: <1448437946.34.0.869547453804.issue25729@psf.upfronthosting.co.za> Message-ID: <1448473708.9.0.00271594438991.issue25729@psf.upfronthosting.co.za> Brian Kearns added the comment: Updated patch per review ---------- Added file: http://bugs.python.org/file41164/timedelta2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 13:03:47 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 25 Nov 2015 18:03:47 +0000 Subject: [issue25723] ConfigParser should never write broken configurations In-Reply-To: <1448379104.29.0.433011869224.issue25723@psf.upfronthosting.co.za> Message-ID: <1448474627.76.0.322924449712.issue25723@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Newline (\n) and possibly \x00, if it necessarily causes an actual problem, are the only characters that we might reject by default. Rejecting anything else is unwarrented editorializing about what people 'should' use. As you said, people who want something stricter can replace .add_section. (This would be most useful in a group or corporate setting which might, for instance, want to severely limit the character set allowed.) In particular, I showed in #20923 how to replace .SECTCRE to make "[Test[2]_foo]" yield "Test[2]_foo". The OP for that issue filed it after seeing an application that used such section names and they are not at all unreasonable. Python should be able to continue writing .ini files for that application as well as any others. Victor, your point that even a minimal change could break working code is a good one. It suggests to me that we should maybe do nothing. This issue is motivated by a theoretical principle "User input should always be validated" that is not a Python design principle (what is valid, who decides), not by actual problems in the field. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 13:14:42 2015 From: report at bugs.python.org (SpaceOne) Date: Wed, 25 Nov 2015 18:14:42 +0000 Subject: [issue25723] ConfigParser should never write broken configurations In-Reply-To: <1448379104.29.0.433011869224.issue25723@psf.upfronthosting.co.za> Message-ID: <1448475282.89.0.0943244452972.issue25723@psf.upfronthosting.co.za> SpaceOne added the comment: Isn't is an actual problem in the field? We had a vulnerability in our code due to this as we only sanitized the config values and didn't recognized that add_section() does no validation of input. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 13:18:43 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 25 Nov 2015 18:18:43 +0000 Subject: [issue19687] Fixes for elementtree integer overflow In-Reply-To: <1385078611.06.0.503563950207.issue19687@psf.upfronthosting.co.za> Message-ID: <20151125181840.22394.42480@psf.io> Roundup Robot added the comment: New changeset e5eac1d692ad by Serhiy Storchaka in branch '3.4': Issue #19687: Fixed possible integer overflows in ElementTree. https://hg.python.org/cpython/rev/e5eac1d692ad New changeset 745fd5550bc0 by Serhiy Storchaka in branch '2.7': Issue #19687: Fixed possible integer overflows in ElementTree. https://hg.python.org/cpython/rev/745fd5550bc0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 13:19:22 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 25 Nov 2015 18:19:22 +0000 Subject: [issue25677] Syntax error caret confused by indentation In-Reply-To: <1447998656.06.0.471632717786.issue25677@psf.upfronthosting.co.za> Message-ID: <1448475562.08.0.343088006639.issue25677@psf.upfronthosting.co.za> R. David Murray added the comment: Two options on portability, I think: either use splitlines() on the decoded result, or add a 'universal_newlines' keyword argument to assert_python_failure and friends that would get passed to Popen. I'd favor the latter, as other users of script_helpers may find it useful. On the other hand, that may involve a whole separate discussion, so you could use splitlines here and we could open a new issue for a script_helpers enhancement :) Also, rather than a direct re, I'd use assertRegex. That will give a more useful error message if the test fails. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 13:19:46 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Nov 2015 18:19:46 +0000 Subject: [issue19687] Fixes for elementtree integer overflow In-Reply-To: <1385078611.06.0.503563950207.issue19687@psf.upfronthosting.co.za> Message-ID: <1448475586.08.0.399396567735.issue19687@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Possible integer overflows in 3.5 was already fixed by issue23450. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 13:20:44 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 25 Nov 2015 18:20:44 +0000 Subject: [issue25730] invisible sidebar content with code snippets In-Reply-To: <1448448461.72.0.524937822108.issue25730@psf.upfronthosting.co.za> Message-ID: <1448475644.1.0.497746970581.issue25730@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Hiroaki, please include a bit of text explanation. What 'default.css' are you referring to? If it is a Sphinx file and not in the CPython repository /Doc, then this should be closed here and reopened on the separate Sphinx tracker. In any case, this is not a security issue for python code, and hence not for 3.2, 3,3. 3.4 will be security patch only in a few weeks. ---------- versions: -Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 13:33:08 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Nov 2015 18:33:08 +0000 Subject: [issue25729] update pure python datetime.timedelta creation In-Reply-To: <1448437946.34.0.869547453804.issue25729@psf.upfronthosting.co.za> Message-ID: <1448476388.12.0.971654709431.issue25729@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Looks you are missed Victor's and my comments. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 13:51:55 2015 From: report at bugs.python.org (Brian Kearns) Date: Wed, 25 Nov 2015 18:51:55 +0000 Subject: [issue25729] update pure python datetime.timedelta creation In-Reply-To: <1448437946.34.0.869547453804.issue25729@psf.upfronthosting.co.za> Message-ID: <1448477515.32.0.855518694442.issue25729@psf.upfronthosting.co.za> Brian Kearns added the comment: Updated again ---------- Added file: http://bugs.python.org/file41165/timedelta3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 14:12:17 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 25 Nov 2015 19:12:17 +0000 Subject: [issue25698] test regressions introduced with the fix for #22995 In-Reply-To: <1448218706.46.0.334921108763.issue25698@psf.upfronthosting.co.za> Message-ID: <1448478737.87.0.0494379226906.issue25698@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 14:41:31 2015 From: report at bugs.python.org (hiroaki itoh) Date: Wed, 25 Nov 2015 19:41:31 +0000 Subject: [issue25730] invisible sidebar content with code snippets In-Reply-To: <1448448461.72.0.524937822108.issue25730@psf.upfronthosting.co.za> Message-ID: <1448480491.54.0.749623339733.issue25730@psf.upfronthosting.co.za> hiroaki itoh added the comment: Ah, sorry I'd mistaked. I don't know if this is Sphinx issue, but CPython repo has Doc/tools/static, Doc/tools/templates, so I still think, this can be fixed by customizing these, for example overriding style at layout.html. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 14:44:31 2015 From: report at bugs.python.org (John Yeung) Date: Wed, 25 Nov 2015 19:44:31 +0000 Subject: [issue25735] math.factorial doc should mention integer return type Message-ID: <1448480671.49.0.139605050425.issue25735@psf.upfronthosting.co.za> New submission from John Yeung: The math module docs state Except when explicitly noted otherwise, all return values are floats. But math.factorial isn't what I would call explicit about returning int: math.factorial(x) Return x factorial. Raises ValueError if x is not integral or is negative. At minimum, shouldn't the first sentence be "Return x factorial as an int."? I haven't tested on all Python versions, but math.factorial on 2.7 and 3.2 definitely return int (or long in Python 2 when necessary). ---------- assignee: docs at python components: Documentation messages: 255382 nosy: John.Yeung, docs at python priority: normal severity: normal status: open title: math.factorial doc should mention integer return type versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 15:25:36 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 25 Nov 2015 20:25:36 +0000 Subject: [issue25730] invisible sidebar content with code snippets In-Reply-To: <1448448461.72.0.524937822108.issue25730@psf.upfronthosting.co.za> Message-ID: <1448483136.02.0.091243046975.issue25730@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Can you create either a specific patch or perhaps more important a test that fails now but should pass with a proper patch? ---------- stage: needs patch -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 15:31:34 2015 From: report at bugs.python.org (Ateik Al-Zehla) Date: Wed, 25 Nov 2015 20:31:34 +0000 Subject: [issue25251] Unknown MS Compiler version 1900 In-Reply-To: <1443392264.43.0.443478210283.issue25251@psf.upfronthosting.co.za> Message-ID: <1448483494.86.0.798368526752.issue25251@psf.upfronthosting.co.za> Ateik Al-Zehla added the comment: thanks Matt for your replay. But I copied the lines to cygwinccompiler.py and it didn't work. and it pretend as there is no change happened to the file. To see if the execution goes through the code I changed message if raise ValueError to "God Help Me %s " instead of "Unknown MS Compiler version %s " I saved the file, and it looks fine in the Editor. but when I executed the command: pip install Numpy. It return the old error Message "Unknown MS Compiler version 1900" I'm tired. I spend three days to solve this issue but without success. plz help ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 15:34:10 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 25 Nov 2015 20:34:10 +0000 Subject: [issue25730] invisible sidebar content with code snippets In-Reply-To: <1448448461.72.0.524937822108.issue25730@psf.upfronthosting.co.za> Message-ID: <1448483650.72.0.794770157284.issue25730@psf.upfronthosting.co.za> R. David Murray added the comment: Since it is a visual issue and we have no infrastructure for that kind of web view testing, I don't think a test is possible. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 15:35:33 2015 From: report at bugs.python.org (Ateik Al-Zehla) Date: Wed, 25 Nov 2015 20:35:33 +0000 Subject: [issue25251] Unknown MS Compiler version 1900 In-Reply-To: <1443392264.43.0.443478210283.issue25251@psf.upfronthosting.co.za> Message-ID: <1448483733.34.0.628164233868.issue25251@psf.upfronthosting.co.za> Ateik Al-Zehla added the comment: forget to tell you that even i deleted the cache, but nothing happened. it use the old code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 15:47:58 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 25 Nov 2015 20:47:58 +0000 Subject: [issue25723] ConfigParser should never write broken configurations In-Reply-To: <1448379104.29.0.433011869224.issue25723@psf.upfronthosting.co.za> Message-ID: <1448484478.66.0.148696479848.issue25723@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Can you explain how passing \n createda vulnerability (to who, doing what) that flagging \n would prevent? Your opening example (nicely presented, by the way) shows that passing \n allows one to do with one call what would otherwise take (in the case of the example) three calls. But the result is identical, so the shortcut seems harmless. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 16:36:15 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 25 Nov 2015 21:36:15 +0000 Subject: [issue25723] ConfigParser should never write broken configurations In-Reply-To: <1448379104.29.0.433011869224.issue25723@psf.upfronthosting.co.za> Message-ID: <1448487375.17.0.0180264224285.issue25723@psf.upfronthosting.co.za> R. David Murray added the comment: The issue would be if the section name came from user input. Then an attacker could craft a section name that would result in inserting arbitrary names and values into the config file. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 16:57:53 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 25 Nov 2015 21:57:53 +0000 Subject: [issue21224] BaseHTTPRequestHandler, update the protocol version to http 1.1 by default? In-Reply-To: <1397508232.09.0.0337317788686.issue21224@psf.upfronthosting.co.za> Message-ID: <1448488673.43.0.96673982049.issue21224@psf.upfronthosting.co.za> Martin Panter added the comment: Victor, that chunked support for server requests is optional, and not actually required (my quote was wrong; see my message after the one you quoted). The client already does HTTP 1.1 by default: >>> http.client.HTTPConnection._http_vsn_str 'HTTP/1.1' It is already possible to make a working HTTP 1.1 server by setting protocol_version. What things do you think would make the HTTP 1.1 server implementation more complete? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 17:01:32 2015 From: report at bugs.python.org (Stefan Krah) Date: Wed, 25 Nov 2015 22:01:32 +0000 Subject: [issue25300] Enable Intel MPX (Memory protection Extensions) feature In-Reply-To: <1443788737.62.0.174147088714.issue25300@psf.upfronthosting.co.za> Message-ID: <1448488892.96.0.957029834553.issue25300@psf.upfronthosting.co.za> Stefan Krah added the comment: > Py_ssize_t ob_array[1] Py_VARIABLE_SIZE; /* Looks weird and confusing */ Yes, I dislike that, too. The question is why gcc has supported the "struct hack" for more than 20 years but needs an annotation just for MPX. Is the annotation also needed for the C99 version (ob_array[])? Which brings me again to the topic that the MPX support needs to stabilize in gcc. ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 18:08:33 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 25 Nov 2015 23:08:33 +0000 Subject: [issue21224] BaseHTTPRequestHandler, update the protocol version to http 1.1 by default? In-Reply-To: <1448488673.43.0.96673982049.issue21224@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Sorry, I read the issue very quickly. I don't understand why the default is not changed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 18:08:35 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 25 Nov 2015 23:08:35 +0000 Subject: [issue25715] Python 3.5.1 installer shows wrong upgrade path In-Reply-To: <1448310282.68.0.27697601288.issue25715@psf.upfronthosting.co.za> Message-ID: <1448492915.66.0.340096404367.issue25715@psf.upfronthosting.co.za> Steve Dower added the comment: Man, dealing with the launcher is hard. But I've got it about as good as I can: * when installing 3.5.1 over 3.5.0, user has the option to update/not update the launcher (no option to uninstall at that time) * after installing 3.5.1, launcher can be added via Modify, but not removed - the checkbox is now disabled with this change * with 3.5.1, the launcher has its own entry in Programs and Features (from a different bug) * uninstalling 3.5.1 does not automatically uninstall the launcher This patch updates the help text in the installer to better explain what's going on, and now gets the "requires admin" icon correct. Larry - this change is fully contained to the installer and (along with the original part of the issue above) should avoid a lot of confusion once we release. Can I have it in 3.5.1? I'm happy to rebase and push directly to your repo. ---------- Added file: http://bugs.python.org/file41166/25715_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 18:58:23 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 25 Nov 2015 23:58:23 +0000 Subject: [issue25696] "make -j9 install" fails because bininstall target requires the libainstall target In-Reply-To: <1448202702.88.0.964294450431.issue25696@psf.upfronthosting.co.za> Message-ID: <1448495903.45.0.998238614851.issue25696@psf.upfronthosting.co.za> Martin Panter added the comment: $(LIBPC) is a single directory name, so I suggest dropping the ?for? loop. Patch 2 should avoid the practical race condition. But there is technically still a race with ?libainstall? and ?bininstall? both testing and creating the same directory. Maybe we should factor it out, something like: $(DESTDIR)$(LIBPC): @echo "Creating directory $@" @$(INSTALL) -d -m $(DIRMODE) $@ . . . bininstall: altbininstall $(DESTDIR)$(LIBPC) . . . libainstall: all python-config $(DESTDIR)$(LIBPC) @for i in $(LIBDIR) $(LIBPL); \ . . . Looking at the history, the test-then-install code comes from 20 years ago: . I would say calling install unconditionally (without a test or echo message) might be simpler, but that?s probably getting out of scope here. ---------- nosy: +martin.panter stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 19:05:54 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 26 Nov 2015 00:05:54 +0000 Subject: [issue25638] Verify the etree_parse and etree_iterparse benchmarks are working appropriately In-Reply-To: <1447702883.28.0.950037808414.issue25638@psf.upfronthosting.co.za> Message-ID: <1448496354.31.0.0209357974648.issue25638@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Updated to tip. ---------- Added file: http://bugs.python.org/file41167/etree_iterparse_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 19:41:24 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 26 Nov 2015 00:41:24 +0000 Subject: [issue22100] Use $HOSTPYTHON when determining candidate interpreter for $PYTHON_FOR_BUILD. In-Reply-To: <1406648042.0.0.0162670058613.issue22100@psf.upfronthosting.co.za> Message-ID: <1448498484.71.0.172768911858.issue22100@psf.upfronthosting.co.za> Martin Panter added the comment: What is $HOSTPYTHON? It does not appear to be used or mentioned anywhere. You mention it as if it is commonly known, but if you are proposing a new configuration variable, perhaps you should document it. The Gnu version of ?which? seems to work fine with relative paths, though I know it is not a standardized command. Can you explain what your problem with relative paths is? Maybe we can find a cleaner way to check if a command exists, e.g. use ?command -v?. $ which ./python && echo Success /media/disk/home/proj/python/cpython/python Success Can you explain the problem with PYTHONPATH and the ?S addition? If we really need it, a comment would be good. What is the difference between your $HOSTPYTHON case and the original python3 etc cases, where it is not needed? Also, did you test your patch? Your ?S argument uses a UTF-8 em dash, which would be interpreted as a script file name, rather than an ASCII dash for the -S option. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 20:12:52 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 26 Nov 2015 01:12:52 +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: <1448500372.04.0.774555922108.issue14044@psf.upfronthosting.co.za> Martin Panter added the comment: Closing this as being a bug in the web server, rather than Python. If someone wants to add a way to force a HTTP 1.0 response, or a way to get all valid data before raising the exception, I suggest opening a new report. ---------- resolution: -> third party status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 20:18:25 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 26 Nov 2015 01:18:25 +0000 Subject: [issue25677] Syntax error caret confused by indentation In-Reply-To: <1447998656.06.0.471632717786.issue25677@psf.upfronthosting.co.za> Message-ID: <1448500705.94.0.494070266084.issue25677@psf.upfronthosting.co.za> Martin Panter added the comment: Another way to get universal newlines I have used in other cases is to use TextIOWrapper. It might be easier if you really need that multi-line RE search: text = TextIOWrapper(BytesIO(stderr), "ascii").read() ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 21:00:27 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 26 Nov 2015 02:00:27 +0000 Subject: [issue21224] BaseHTTPRequestHandler, update the protocol version to http 1.1 by default? In-Reply-To: <1397508232.09.0.0337317788686.issue21224@psf.upfronthosting.co.za> Message-ID: <1448503227.74.0.00314783299141.issue21224@psf.upfronthosting.co.za> Martin Panter added the comment: Changing it could break existing code written for the HTTP 1.0 behaviour. The main effect mentioned at is that in HTTP 1.0 mode, a server may send a response without Content-Length, because its connection will be automatically shut down when it is done. In HTTP 1.1 mode, the server code has to manually set close_connection = True (or indicate the end of the response some other way). Looking at the source code, changing protocol_version to "HTTP/1.1": * Allows close_connection to be False by default (causing the problem above) * Enables Expect: 100-continue handling (no problem) * Changes the version actually used in the HTTP protocol (probably acceptable if everything else keeps working with a HTTP 1.1 client) * Affects the SERVER_PROTOCOL variable for CGI scripts (unsure of the consequences) Perhaps one way forward would be to use HTTP 1.1 by default, but still set close_connection = True. But then someone may come along and say Python should support persistent connections by default! It does not seem worth enabling HTTP 1.1 with non-persistent connections as the default. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 21:56:39 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 26 Nov 2015 02:56:39 +0000 Subject: [issue25622] Enable ctypes.test.test_values.Win_ValuesTestCase for non-Windows In-Reply-To: <1447450134.96.0.43104915369.issue25622@psf.upfronthosting.co.za> Message-ID: <20151126025636.650.46627@psf.io> Roundup Robot added the comment: New changeset 6a8fbb97c8d8 by Martin Panter in branch 'default': Issue #25622: Rename to PythonValuesTestCase and enable for non-Windows https://hg.python.org/cpython/rev/6a8fbb97c8d8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 23:56:36 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 26 Nov 2015 04:56:36 +0000 Subject: [issue25723] ConfigParser should never write broken configurations In-Reply-To: <1448379104.29.0.433011869224.issue25723@psf.upfronthosting.co.za> Message-ID: <1448513796.66.0.0259403187575.issue25723@psf.upfronthosting.co.za> Terry J. Reedy added the comment: We all know that blindly inserting external data into a database can be a bad idea. But raising ValueError if the data contains \n barely scratches the surface of a real defense. The external data should be checked before passing it to .add_section or as part of a derived method in a subclass. I already suggested the possibility of allowing only a restricted set of letter characters. Such a check comes after defending against the possibility of someone submitting 'a'*1000000 as, in this case, a section name. configparser is permissive by design, not by accident. The un-abbreviated verbose re for ConfigParser.SECTCRE say so. (?P
[^]]+) # very permissive! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 02:42:20 2015 From: report at bugs.python.org (=?utf-8?q?Ervin_Heged=C3=BCs?=) Date: Thu, 26 Nov 2015 07:42:20 +0000 Subject: [issue25736] smtplib can't send 8bit encoded utf-8 message Message-ID: <1448523740.68.0.442451319254.issue25736@psf.upfronthosting.co.za> Changes by Ervin Heged?s : ---------- nosy: airween priority: normal severity: normal status: open title: smtplib can't send 8bit encoded utf-8 message type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 02:46:32 2015 From: report at bugs.python.org (=?utf-8?q?Ervin_Heged=C3=BCs?=) Date: Thu, 26 Nov 2015 07:46:32 +0000 Subject: [issue25736] smtplib can't send 8bit encoded utf-8 message Message-ID: <1448523992.32.0.105956858988.issue25736@psf.upfronthosting.co.za> New submission from Ervin Heged?s: Looks like smtplib can send only messages, which contains only 7bit (ascii) characters. Here is the example: # -*- coding: utf8 -*- import time import smtplib mailfrom = "my at mydomain.com" rcptto = "me at otherdomain.com" msg = """%s From: Me <%s> To: %s Subject: Plain text e-mail MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit happy New Year ??????????? ?? ??? ???? ??????????????? ? ????? ????? """ % (time.strftime('%a, %d %b %Y %H:%M:%S +0100', time.localtime()), mailfrom, rcptto) server = smtplib.SMTP('localhost') server.sendmail(mailfrom, rcptto, msg) server.quit() With Python2 (Python 2.7), this script finished succesfully. With Python3 (Python 3.4), I've got this execption: Traceback (most recent call last): File "8bittest.py", line 28, in server.sendmail(mailfrom, rcptto, msg) File "/usr/lib/python3.4/smtplib.py", line 765, in sendmail msg = _fix_eols(msg).encode('ascii') UnicodeEncodeError: 'ascii' codec can't encode characters in position 261-271: ordinal not in range(128) Basicly, I don't understand, why smtplib allows only ascii encoded messages in Python 3. That worked (and works) in Python 2, and I think, that's the correct behavior. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 03:44:38 2015 From: report at bugs.python.org (=?utf-8?q?Ervin_Heged=C3=BCs?=) Date: Thu, 26 Nov 2015 08:44:38 +0000 Subject: [issue25736] smtplib can't send 8bit encoded utf-8 message In-Reply-To: <1448523992.32.0.105956858988.issue25736@psf.upfronthosting.co.za> Message-ID: <1448527478.18.0.501697222968.issue25736@psf.upfronthosting.co.za> Ervin Heged?s added the comment: Here is a workaround: server.sendmail(mailfrom, rcptto, msg.encode("utf8")) May be this would be better inside of smtplib? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 04:06:57 2015 From: report at bugs.python.org (hiroaki itoh) Date: Thu, 26 Nov 2015 09:06:57 +0000 Subject: [issue25730] invisible sidebar content with code snippets In-Reply-To: <1448448461.72.0.524937822108.issue25730@psf.upfronthosting.co.za> Message-ID: <1448528817.38.0.478936681786.issue25730@psf.upfronthosting.co.za> hiroaki itoh added the comment: Because there are a couple of ways (places) to fix this, I'll try them, so please wait. For testing, I think we can only visit all htmls manually and I'll make an effort. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 04:40:50 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 26 Nov 2015 09:40:50 +0000 Subject: [issue25707] Add the close method for ElementTree.iterparse() object In-Reply-To: <1448287045.22.0.0931965485798.issue25707@psf.upfronthosting.co.za> Message-ID: <1448530850.83.0.571539276181.issue25707@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: +Verify the etree_parse and etree_iterparse benchmarks are working appropriately _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 05:45:18 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 26 Nov 2015 10:45:18 +0000 Subject: [issue25622] Enable ctypes.test.test_values.Win_ValuesTestCase for non-Windows In-Reply-To: <1447450134.96.0.43104915369.issue25622@psf.upfronthosting.co.za> Message-ID: <20151126104513.31407.3643@psf.io> Roundup Robot added the comment: New changeset 0325eca1927e by Martin Panter in branch '3.4': Issue #25622: Rename to PythonValuesTestCase and enable for non-Windows https://hg.python.org/cpython/rev/0325eca1927e New changeset 18a74ef65d3f by Martin Panter in branch '3.5': Issue #25622: Merge ctypes test from 3.4 into 3.5 https://hg.python.org/cpython/rev/18a74ef65d3f New changeset 38f749f0a1bd by Martin Panter in branch '3.5': Issue #25622: Use repr(bytes) to avoid BytesWarning https://hg.python.org/cpython/rev/38f749f0a1bd ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 06:07:15 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 26 Nov 2015 11:07:15 +0000 Subject: [issue22989] HTTPResponse.msg not as documented In-Reply-To: <1417632317.82.0.906874710781.issue22989@psf.upfronthosting.co.za> Message-ID: <20151126110711.652.85020@psf.io> Roundup Robot added the comment: New changeset fa3c9faabfb0 by Martin Panter in branch '3.4': Issues #22989, #21228: Document HTTP response object for urlopen() https://hg.python.org/cpython/rev/fa3c9faabfb0 New changeset b55c006b79bc by Martin Panter in branch '3.5': Issue #22989, #21228: Merge urlopen() doc from 3.4 into 3.5 https://hg.python.org/cpython/rev/b55c006b79bc New changeset c6930661599b by Martin Panter in branch 'default': Issue #22989, #21228: Merge urlopen() doc from 3.5 https://hg.python.org/cpython/rev/c6930661599b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 06:07:15 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 26 Nov 2015 11:07:15 +0000 Subject: [issue21228] Missing enumeration of HTTPResponse Objects methods of urllib.request.urlopen's http.client.HTTPResponse? In-Reply-To: <1397520483.48.0.224250148615.issue21228@psf.upfronthosting.co.za> Message-ID: <20151126110711.652.45566@psf.io> Roundup Robot added the comment: New changeset fa3c9faabfb0 by Martin Panter in branch '3.4': Issues #22989, #21228: Document HTTP response object for urlopen() https://hg.python.org/cpython/rev/fa3c9faabfb0 New changeset b55c006b79bc by Martin Panter in branch '3.5': Issue #22989, #21228: Merge urlopen() doc from 3.4 into 3.5 https://hg.python.org/cpython/rev/b55c006b79bc New changeset c6930661599b by Martin Panter in branch 'default': Issue #22989, #21228: Merge urlopen() doc from 3.5 https://hg.python.org/cpython/rev/c6930661599b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 06:12:49 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 26 Nov 2015 11:12:49 +0000 Subject: [issue21228] Missing enumeration of HTTPResponse Objects methods of urllib.request.urlopen's http.client.HTTPResponse? In-Reply-To: <1397520483.48.0.224250148615.issue21228@psf.upfronthosting.co.za> Message-ID: <1448536369.21.0.179716673282.issue21228@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 06:19:03 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 26 Nov 2015 11:19:03 +0000 Subject: [issue22989] HTTPResponse.msg not as documented In-Reply-To: <1417632317.82.0.906874710781.issue22989@psf.upfronthosting.co.za> Message-ID: <1448536743.68.0.79705440675.issue22989@psf.upfronthosting.co.za> Martin Panter added the comment: The documentation now mentions the ?msg? quirk and the info() method. ---------- resolution: -> fixed stage: -> resolved status: open -> closed versions: +Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 06:20:40 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 26 Nov 2015 11:20:40 +0000 Subject: [issue21228] Missing enumeration of HTTPResponse Objects methods of urllib.request.urlopen's http.client.HTTPResponse? In-Reply-To: <1397520483.48.0.224250148615.issue21228@psf.upfronthosting.co.za> Message-ID: <1448536840.03.0.864375075962.issue21228@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 06:22:21 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 26 Nov 2015 11:22:21 +0000 Subject: [issue25622] Enable ctypes.test.test_values.Win_ValuesTestCase for non-Windows In-Reply-To: <1447450134.96.0.43104915369.issue25622@psf.upfronthosting.co.za> Message-ID: <20151126112218.29812.9127@psf.io> Roundup Robot added the comment: New changeset 7b12b04f4f18 by Martin Panter in branch '2.7': Issue #25622: Rename to PythonValuesTestCase and enable for non-Windows https://hg.python.org/cpython/rev/7b12b04f4f18 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 06:25:35 2015 From: report at bugs.python.org (Chi Hsuan Yen) Date: Thu, 26 Nov 2015 11:25:35 +0000 Subject: [issue21668] The select and time modules uses libm functions without linking against it In-Reply-To: <1401972993.52.0.304727515537.issue21668@psf.upfronthosting.co.za> Message-ID: <1448537135.58.0.384057427705.issue21668@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: Bump. For rev c6930661599b timemodule.c and selectmodule.c no longer calls libm functions, while audioop.c and _ctypes_test.c still do. I have my updated patch here based on previous patches. Note that the introduction of detect_math_libs() is my naive try. Its naming and position in setup.py may need more consideration. Here's the result before and after my patch. Before: shell at GT-N7000:/data/local/tmp $ python3 Python 3.6.0a0 (default:6a8fbb97c8d8+, Nov 26 2015, 18:42:29) [GCC 4.9 20140827 (prerelease)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import select >>> import time >>> import audioop Traceback (most recent call last): File "", line 1, in ImportError: dlopen failed: cannot locate symbol "floor" referenced by "audioop.cpython-36m-arm-linux-gnueabi.so"... >>> import _ctypes_test Traceback (most recent call last): File "", line 1, in ImportError: dlopen failed: cannot locate symbol "sqrt" referenced by "_ctypes_test.cpython-36m-arm-linux-gnueabi.so"... >>> After: shell at GT-N7000:/data/local/tmp $ python3 Python 3.6.0a0 (default:c6930661599b+, Nov 26 2015, 19:10:15) [GCC 4.9 20140827 (prerelease)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import time >>> import selectr Traceback (most recent call last): File "", line 1, in ImportError: No module named 'selectr' >>> import select >>> import audioop >>> import _ctypes_test >>> Tested on Samsung Galaxy Note GT-N7000 with my custom build of CyanogenMod 11.0 ---------- nosy: +Chi Hsuan Yen Added file: http://bugs.python.org/file41168/python-hg-modules-link-libm.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 06:27:38 2015 From: report at bugs.python.org (Chi Hsuan Yen) Date: Thu, 26 Nov 2015 11:27:38 +0000 Subject: [issue21668] The select and time modules uses libm functions without linking against it In-Reply-To: <1401972993.52.0.304727515537.issue21668@psf.upfronthosting.co.za> Message-ID: <1448537258.53.0.325937158235.issue21668@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: Well, the hg revision of Python in two tests are different, because I `hg pull -u` each time I build. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 06:29:53 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 26 Nov 2015 11:29:53 +0000 Subject: [issue25622] Enable ctypes.test.test_values.Win_ValuesTestCase for non-Windows In-Reply-To: <1447450134.96.0.43104915369.issue25622@psf.upfronthosting.co.za> Message-ID: <1448537393.21.0.911727264736.issue25622@psf.upfronthosting.co.za> Martin Panter added the comment: The buildbots don?t seem to be having any troubles with test_ctypes, so I assume my change is good. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 06:34:09 2015 From: report at bugs.python.org (berdario) Date: Thu, 26 Nov 2015 11:34:09 +0000 Subject: [issue25737] array is not a Sequence Message-ID: <1448537649.86.0.885493348949.issue25737@psf.upfronthosting.co.za> New submission from berdario: >>> from array import array >>> from collections.abc import Sequence >>> isinstance(array('I', [1]), Sequence) False ---------- components: Interpreter Core messages: 255413 nosy: berdario priority: normal severity: normal status: open title: array is not a Sequence versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 06:37:17 2015 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 26 Nov 2015 11:37:17 +0000 Subject: [issue25737] array is not a Sequence In-Reply-To: <1448537649.86.0.885493348949.issue25737@psf.upfronthosting.co.za> Message-ID: <1448537837.45.0.473642476223.issue25737@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti, rhettinger, stutzbach type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 06:43:10 2015 From: report at bugs.python.org (berdario) Date: Thu, 26 Nov 2015 11:43:10 +0000 Subject: [issue25737] array is not a Sequence In-Reply-To: <1448537649.86.0.885493348949.issue25737@psf.upfronthosting.co.za> Message-ID: <1448538190.71.0.421147414183.issue25737@psf.upfronthosting.co.za> berdario added the comment: Ok, basically `Sequence` does not implement `__subclasshook__` and is manually hardcoded to ``` Sequence.register(tuple) Sequence.register(str) Sequence.register(range) Sequence.register(memoryview) ``` This is not by design, is it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 07:30:58 2015 From: report at bugs.python.org (Eryk Sun) Date: Thu, 26 Nov 2015 12:30:58 +0000 Subject: [issue25737] array is not a Sequence In-Reply-To: <1448537649.86.0.885493348949.issue25737@psf.upfronthosting.co.za> Message-ID: <1448541058.69.0.600188043733.issue25737@psf.upfronthosting.co.za> Eryk Sun added the comment: This is a duplicate of issue 23864, i.e. only the "one-trick ponies" work: >>> issubclass(array.array, abc.Sized) True >>> issubclass(array.array, abc.Iterable) True >>> issubclass(array.array, abc.Container) True ---------- nosy: +eryksun resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> issubclass without registration only works for "one-trick pony" collections ABCs. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 08:14:17 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Thu, 26 Nov 2015 13:14:17 +0000 Subject: [issue25528] Attempt to further increase test coverage of calendar module In-Reply-To: <1446371863.84.0.773420016182.issue25528@psf.upfronthosting.co.za> Message-ID: <1448543657.34.0.509114650452.issue25528@psf.upfronthosting.co.za> St?phane Wirtel added the comment: no problem about the second patch of Rohit. pass the test with default and I have tested the code in the REPL. ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 08:57:55 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 26 Nov 2015 13:57:55 +0000 Subject: [issue25528] Attempt to further increase test coverage of calendar module In-Reply-To: <1446371863.84.0.773420016182.issue25528@psf.upfronthosting.co.za> Message-ID: <1448546275.34.0.64197656857.issue25528@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The problem with Rohit's patch is that it throws out existing test case. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 09:45:43 2015 From: report at bugs.python.org (Michael Layzell) Date: Thu, 26 Nov 2015 14:45:43 +0000 Subject: [issue25677] Syntax error caret confused by indentation In-Reply-To: <1447998656.06.0.471632717786.issue25677@psf.upfronthosting.co.za> Message-ID: <1448549143.6.0.144777089878.issue25677@psf.upfronthosting.co.za> Michael Layzell added the comment: Martin's solution seemed like the least work, so that's what I ended up using. I also switched over to assertRegex, and I agree that it produces better error messages. I added a comment to explain the use of the ugly multiline regex, and removed some of its unnecessary parts. ---------- Added file: http://bugs.python.org/file41169/cpython25677.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 09:48:12 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 26 Nov 2015 14:48:12 +0000 Subject: [issue13330] Attempt full test coverage of LocaleTextCalendar.formatweekday In-Reply-To: <1320300850.58.0.556745870791.issue13330@psf.upfronthosting.co.za> Message-ID: <1448549292.26.0.674135245682.issue13330@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The test depends on the en_US locale. Only existing of POSIX locale is guarantied. The test should be skipped instead of failed if the en_US locale is not available. It would be nice to test also with other locales. For example with de_DE, fr_FR, tr_TR, ps_AF - these locales are used also in other tests. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 09:56:49 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 26 Nov 2015 14:56:49 +0000 Subject: [issue25730] invisible sidebar content with code snippets In-Reply-To: <1448448461.72.0.524937822108.issue25730@psf.upfronthosting.co.za> Message-ID: <1448549809.2.0.151829377964.issue25730@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I intentionally said 'test' rather than 'unittest' or 'automated test' to allow for the possibility of a human-operated view test script posted here on the issue. IDLE now has a view test framework to run tests for either one or all modules with visual displays. For all: python -m idlelib.idle_test.htest This has been very useful when modifying files. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 10:00:40 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 26 Nov 2015 15:00:40 +0000 Subject: [issue12568] Add functions to get the width in columns of a character In-Reply-To: <1310683436.9.0.375403702242.issue12568@psf.upfronthosting.co.za> Message-ID: <1448550040.16.0.776201770832.issue12568@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think this function would be very useful in many parts of interpreter core and standard library. From displaying tracebacks to formatting helps. Otherwise we are doomed to implement imperfect variants in multiple places. ---------- resolution: out of date -> status: closed -> open versions: +Python 3.6 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 10:04:43 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 26 Nov 2015 15:04:43 +0000 Subject: [issue13330] Attempt full test coverage of LocaleTextCalendar.formatweekday In-Reply-To: <1320300850.58.0.556745870791.issue13330@psf.upfronthosting.co.za> Message-ID: <1448550283.88.0.378334462467.issue13330@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: And it looks that only empty locale works on Windows (issue21731). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 11:22:19 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Thu, 26 Nov 2015 16:22:19 +0000 Subject: [issue25528] Attempt to further increase test coverage of calendar module In-Reply-To: <1446371863.84.0.773420016182.issue25528@psf.upfronthosting.co.za> Message-ID: <1448554939.17.0.764573221806.issue25528@psf.upfronthosting.co.za> St?phane Wirtel added the comment: Sure, But the patch is correct. Now, you are right, we have to ask him a new patch where the function is really tested. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 11:56:07 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 26 Nov 2015 16:56:07 +0000 Subject: [issue25723] ConfigParser should never write broken configurations In-Reply-To: <1448379104.29.0.433011869224.issue25723@psf.upfronthosting.co.za> Message-ID: <1448556967.23.0.446490237606.issue25723@psf.upfronthosting.co.za> R. David Murray added the comment: I view this as similar to the corresponding issue with email headers, where we fixed a similar security issue. The special danger of \n is that it allows you to create a *new* header, or in this case section, with an arbitrary value, possibly overriding an existing section and thus changing the behavior of the program in an exploitable way. This is *far* easier to exploit than the ability to introduce arbitrary data into the section name itself. Good security involves concentric rings of defense, and one should almost always be more secure by default when it has a small usability impact. In this case, there is no legitimate use for \n in a section name, so the only usability impact would be if some weird program out there was actually making use of this for some reason, against all reasonable logic :). Which is why we are suggesting changing it only in 3.6. \x00 is problematic (though somewhat less so) for the same reason, as many file readers will treat it as equivalent to end of line and allow a similar exploit. \r, \f, and \x1c-\x1e should also be blocked, but otherwise we should probably ignore non-printables for backward compatibility reasons (there we move further into the usability impact area). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 12:05:13 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 26 Nov 2015 17:05:13 +0000 Subject: [issue25736] smtplib can't send 8bit encoded utf-8 message In-Reply-To: <1448523992.32.0.105956858988.issue25736@psf.upfronthosting.co.za> Message-ID: <1448557513.09.0.324836132777.issue25736@psf.upfronthosting.co.za> R. David Murray added the comment: Although that will work for text-only messages if you know what RFC format looks like, you really don't want to do that in the general case, since you can't express messages that have binary non-text content using unicode. What you want to do is prepare your message in correct RFC form, which is what the email library is for. With the new API (provisional now, but any changes will be minor when it becomes final in 3.6), this is even easy (see the 'contentmanager' docs). Then you call smtplib.send_message, and the encoding to RFC format is taken care of for you. In 3.5 it even supports SMTPUTF8, if you know any servers that do :) ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 12:06:32 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 26 Nov 2015 17:06:32 +0000 Subject: [issue25736] smtplib can't send 8bit encoded utf-8 message In-Reply-To: <1448523992.32.0.105956858988.issue25736@psf.upfronthosting.co.za> Message-ID: <1448557592.47.0.475352441167.issue25736@psf.upfronthosting.co.za> R. David Murray added the comment: Oh, and as for why this worked in python2: in python2 strings were binary, not unicode, so the non-ascii stuff was already in bytes form. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 12:09:31 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 26 Nov 2015 17:09:31 +0000 Subject: [issue25730] invisible sidebar content with code snippets In-Reply-To: <1448448461.72.0.524937822108.issue25730@psf.upfronthosting.co.za> Message-ID: <1448557771.57.0.0540245650948.issue25730@psf.upfronthosting.co.za> R. David Murray added the comment: Ah, I see what you mean. It's still tricky for web stuff, though, because what you see can completely depend on things like window size and browser version. So a detailed description of how to produce the error would be good, and we'll see if we actually can :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 12:16:39 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 26 Nov 2015 17:16:39 +0000 Subject: [issue13275] Recommend xml.etree for XML processing In-Reply-To: <1319709959.84.0.984784684468.issue13275@psf.upfronthosting.co.za> Message-ID: <1448558199.18.0.0989570925526.issue13275@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 12:17:05 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 26 Nov 2015 17:17:05 +0000 Subject: [issue10942] xml.etree.ElementTree.tostring returns type bytes, expected type str In-Reply-To: <1295395949.96.0.0409847573272.issue10942@psf.upfronthosting.co.za> Message-ID: <1448558225.9.0.216636541171.issue10942@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> out of date stage: needs patch -> resolved status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 12:18:16 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 26 Nov 2015 17:18:16 +0000 Subject: [issue14988] _elementtree: Raise ImportError when importing of pyexpat fails In-Reply-To: <1338708115.99.0.275881966348.issue14988@psf.upfronthosting.co.za> Message-ID: <1448558296.2.0.925763306007.issue14988@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: test needed -> resolved status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 12:19:37 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 26 Nov 2015 17:19:37 +0000 Subject: [issue24858] python3 -m test -ugui -v test_tk gives 3 failures under Debian unstable (sid) In-Reply-To: <1439486580.93.0.0912467403749.issue24858@psf.upfronthosting.co.za> Message-ID: <1448558377.77.0.131107798225.issue24858@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> third party stage: -> resolved status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 12:20:08 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 26 Nov 2015 17:20:08 +0000 Subject: [issue15504] pickle/cPickle saves invalid/incomplete data In-Reply-To: <1343663028.38.0.42350418133.issue15504@psf.upfronthosting.co.za> Message-ID: <1448558408.44.0.86137024037.issue15504@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> out of date stage: -> resolved status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 12:21:29 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 26 Nov 2015 17:21:29 +0000 Subject: [issue8426] multiprocessing.Queue fails to get() very large objects In-Reply-To: <1271443086.56.0.51527518355.issue8426@psf.upfronthosting.co.za> Message-ID: <1448558489.52.0.0783510704168.issue8426@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> not a bug stage: -> resolved status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 12:24:33 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 26 Nov 2015 17:24:33 +0000 Subject: [issue25040] xml.sax.make_parser makes bad use of parser_list argument default value In-Reply-To: <1441803251.56.0.483557486647.issue25040@psf.upfronthosting.co.za> Message-ID: <1448558673.76.0.43706019056.issue25040@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> not a bug stage: -> resolved status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 12:29:05 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 26 Nov 2015 17:29:05 +0000 Subject: [issue25106] Hash computation speedup for {buffer, string, unicode}object In-Reply-To: <1442215768.28.0.950322315319.issue25106@psf.upfronthosting.co.za> Message-ID: <1448558945.66.0.496678823237.issue25106@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping. ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 12:33:38 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 26 Nov 2015 17:33:38 +0000 Subject: [issue12340] Access violation when using the C version of the io module In-Reply-To: <1308152515.03.0.630952257185.issue12340@psf.upfronthosting.co.za> Message-ID: <1448559218.41.0.779858524521.issue12340@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> out of date stage: -> resolved status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 12:37:34 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 26 Nov 2015 17:37:34 +0000 Subject: [issue11872] cPickle gives strange error for large objects. In-Reply-To: <1303200362.9.0.587954333494.issue11872@psf.upfronthosting.co.za> Message-ID: <1448559454.36.0.837613739314.issue11872@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> out of date stage: needs patch -> resolved status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 12:45:34 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 26 Nov 2015 17:45:34 +0000 Subject: [issue23513] Add support for classes/object model in multiprocessing/pickle In-Reply-To: <1424797303.36.0.545069200968.issue23513@psf.upfronthosting.co.za> Message-ID: <1448559934.93.0.799392629065.issue23513@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Support of pickling nested classes and methods with all protocols was added in issue23611. ---------- resolution: -> out of date stage: -> resolved status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 12:46:28 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 26 Nov 2015 17:46:28 +0000 Subject: [issue25194] Opt-in motivations & affiliations page for core contributors In-Reply-To: <1442740668.12.0.539568285088.issue25194@psf.upfronthosting.co.za> Message-ID: <20151126174625.31405.62730@psf.io> Roundup Robot added the comment: New changeset b360bad24805 by R David Murray in branch 'default': #25194: add my entry to 'motivations'. https://hg.python.org/devguide/rev/b360bad24805 New changeset 2d4907e5b51c by R David Murray in branch 'default': #25194: Fix indentation in Nick's entry. https://hg.python.org/devguide/rev/2d4907e5b51c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 12:50:52 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 26 Nov 2015 17:50:52 +0000 Subject: [issue25106] Hash computation speedup for {buffer, string, unicode}object In-Reply-To: <1442215768.28.0.950322315319.issue25106@psf.upfronthosting.co.za> Message-ID: <1448560252.55.0.116940038472.issue25106@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Reopen this if you find a reproducible way for this patch to prove useful. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 12:52:57 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 26 Nov 2015 17:52:57 +0000 Subject: [issue25194] Opt-in motivations & affiliations page for core contributors In-Reply-To: <1442740668.12.0.539568285088.issue25194@psf.upfronthosting.co.za> Message-ID: <1448560377.06.0.402740138734.issue25194@psf.upfronthosting.co.za> R. David Murray added the comment: As I finalized my entry it occurred to me that in fact the PSF has expressed willingness to pay me for some contract work around the tracker, but I haven't managed to make the proposal yet. The good news in that is that in fact I have a good bit of open source work filling my schedule right now... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 12:53:58 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 26 Nov 2015 17:53:58 +0000 Subject: [issue18911] minidom does not encode correctly when calling Document.writexml In-Reply-To: <1378186619.58.0.930376227557.issue18911@psf.upfronthosting.co.za> Message-ID: <1448560438.23.0.524331803342.issue18911@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +easy stage: -> needs patch versions: +Python 3.5, Python 3.6 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 12:54:14 2015 From: report at bugs.python.org (=?utf-8?q?Ervin_Heged=C3=BCs?=) Date: Thu, 26 Nov 2015 17:54:14 +0000 Subject: [issue25736] smtplib can't send 8bit encoded utf-8 message In-Reply-To: <1448523992.32.0.105956858988.issue25736@psf.upfronthosting.co.za> Message-ID: <1448560454.58.0.0905469583568.issue25736@psf.upfronthosting.co.za> Ervin Heged?s added the comment: David, many thanks for your information. I think my e-mail format was correct - I've copied it from a maildir, as an "email file". As I wrote, there is a solution: before the code passes the 'msg' argument to sendmail() function, it needs to encode() it as "utf-8", then it will be a bytestream, instead of unicode (which is the default type of any string in Py3). Meanwhile I realized it :). Thanks again, and sorry for my mistake. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 14:07:31 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 26 Nov 2015 19:07:31 +0000 Subject: [issue4712] Document pickle behavior for subclasses of dicts/lists In-Reply-To: <1229880245.44.0.0654065239479.issue4712@psf.upfronthosting.co.za> Message-ID: <1448564851.67.0.942668838013.issue4712@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The copy module uses the same __reduce__ protocol, but reconstruct the object in different order, first set state, then add items. This discrepancy causes a difference between results of pickle/unpickle and copy operations. Example: >>> class L(list): ... def __getstate__(self): ... return list(self) ... def __setstate__(self, state): ... self[:] = state ... >>> import copy, pickle >>> pickle.loads(pickle.dumps(L([1, 2]))) [1, 2] >>> copy.deepcopy(L([1, 2])) [1, 2, 1, 2] This was happened with xml.dom.minicompat.NodeList (issue10131). Definitely one of pickle's or copy's behavior should be changed. But what? ---------- nosy: +serhiy.storchaka versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 15:42:22 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 26 Nov 2015 20:42:22 +0000 Subject: [issue10131] deepcopying an xml.dom.minidom.Document generates an invalid XML document In-Reply-To: <1287322940.78.0.0838139062813.issue10131@psf.upfronthosting.co.za> Message-ID: <1448570542.81.0.533038469732.issue10131@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka nosy: +alexandre.vassalotti, pitrou, serhiy.storchaka versions: +Python 3.4, Python 3.5, Python 3.6 -Python 3.2, Python 3.3 Added file: http://bugs.python.org/file41170/copying_NodeList.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 16:32:47 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 26 Nov 2015 21:32:47 +0000 Subject: [issue25677] Syntax error caret confused by indentation In-Reply-To: <1447998656.06.0.471632717786.issue25677@psf.upfronthosting.co.za> Message-ID: <1448573567.75.0.329938168618.issue25677@psf.upfronthosting.co.za> Martin Panter added the comment: Michael, see the review comments if you already haven?t. There is an unused variable ?p? in the last two patches. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 16:33:31 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 26 Nov 2015 21:33:31 +0000 Subject: [issue25677] Syntax error caret confused by indentation In-Reply-To: <1447998656.06.0.471632717786.issue25677@psf.upfronthosting.co.za> Message-ID: <1448573611.18.0.800888621636.issue25677@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- stage: test needed -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 16:53:04 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 26 Nov 2015 21:53:04 +0000 Subject: [issue10131] deepcopying an xml.dom.minidom.Document generates an invalid XML document In-Reply-To: <1287322940.78.0.0838139062813.issue10131@psf.upfronthosting.co.za> Message-ID: <20151126215301.31401.38281@psf.io> Roundup Robot added the comment: New changeset 0eea57ddb75f by Serhiy Storchaka in branch '2.7': Issue #10131: Fixed deep copying of minidom documents. Based on patch https://hg.python.org/cpython/rev/0eea57ddb75f New changeset aa304ad32292 by Serhiy Storchaka in branch '3.4': Issue #10131: Fixed deep copying of minidom documents. Based on patch https://hg.python.org/cpython/rev/aa304ad32292 New changeset 5d6b2dc7e3d0 by Serhiy Storchaka in branch '3.5': Issue #10131: Fixed deep copying of minidom documents. Based on patch https://hg.python.org/cpython/rev/5d6b2dc7e3d0 New changeset 9fcfdb53e8af by Serhiy Storchaka in branch 'default': Issue #10131: Fixed deep copying of minidom documents. Based on patch https://hg.python.org/cpython/rev/9fcfdb53e8af ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 16:56:25 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 26 Nov 2015 21:56:25 +0000 Subject: [issue10131] deepcopying an xml.dom.minidom.Document generates an invalid XML document In-Reply-To: <1287322940.78.0.0838139062813.issue10131@psf.upfronthosting.co.za> Message-ID: <1448574985.84.0.138620175385.issue10131@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Marian for your patch. Committed modified patch with tests. For compatibility with data pickled by unpatched Python we have to keep __setstate__. The discrepancy between pickle and copy module is different not easy issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 16:58:42 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 26 Nov 2015 21:58:42 +0000 Subject: [issue10131] deepcopying an xml.dom.minidom.Document generates an invalid XML document In-Reply-To: <1287322940.78.0.0838139062813.issue10131@psf.upfronthosting.co.za> Message-ID: <1448575122.82.0.845740852152.issue10131@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: test needed -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 17:08:28 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 26 Nov 2015 22:08:28 +0000 Subject: [issue1100562] deepcopying listlike and dictlike objects Message-ID: <1448575708.32.0.813212921003.issue1100562@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Note that this change added discrepancy between pickle and copy modules and broke deepcopying of minidom documents (issue10131). ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 17:09:29 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 26 Nov 2015 22:09:29 +0000 Subject: [issue4712] Document pickle behavior for subclasses of dicts/lists In-Reply-To: <1229880245.44.0.0654065239479.issue4712@psf.upfronthosting.co.za> Message-ID: <1448575769.48.0.828437941131.issue4712@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The order in copy was changed by issue1100562. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 17:11:25 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 26 Nov 2015 22:11:25 +0000 Subject: [issue4712] Document pickle behavior for subclasses of dicts/lists In-Reply-To: <1229880245.44.0.0654065239479.issue4712@psf.upfronthosting.co.za> Message-ID: <1448575885.11.0.12698356636.issue4712@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +alexandre.vassalotti, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 18:19:03 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 26 Nov 2015 23:19:03 +0000 Subject: [issue22233] http.client splits headers on non-\r\n characters In-Reply-To: <1408528953.84.0.772180232607.issue22233@psf.upfronthosting.co.za> Message-ID: <1448579943.5.0.317912844783.issue22233@psf.upfronthosting.co.za> Martin Panter added the comment: For the record, this is a simplified version of the original scenario, showing the low-level HTTP protocol: >>> request = ( ... b"GET /%C4%85 HTTP/1.1\r\n" ... b"Host: graph.facebook.com\r\n" ... b"\r\n" ... ) >>> s = create_connection(("graph.facebook.com", HTTPS_PORT)) >>> with ssl.wrap_socket(s) as s: ... s.sendall(request) ... response = s.recv(3000) ... 50 >>> pprint(response.splitlines(keepends=True)) [b'HTTP/1.1 404 Not Found\r\n', b'WWW-Authenticate: OAuth "Facebook Platform" "not_found" "(#803) Some of the ' b'aliases you requested do not exist: \xc4\x85"\r\n', b'Access-Control-Allow-Origin: *\r\n', b'Content-Type: text/javascript; charset=UTF-8\r\n', b'X-FB-Trace-ID: H9yxnVcQFuA\r\n', b'X-FB-Rev: 2063232\r\n', b'Pragma: no-cache\r\n', b'Cache-Control: no-store\r\n', b'Facebook-API-Version: v2.0\r\n', b'Expires: Sat, 01 Jan 2000 00:00:00 GMT\r\n', b'X-FB-Debug: 07ouxMl1Z439Ke/YzHSjXx3o9PcpGeZBFS7yrGwTzaaudrZWe5Ef8Z96oSo2dINp' b'3GR4q78+1oHDX2pUF2ky1A==\r\n', b'Date: Thu, 26 Nov 2015 23:03:47 GMT\r\n', b'Connection: keep-alive\r\n', b'Content-Length: 147\r\n', b'\r\n', b'{"error":{"message":"(#803) Some of the aliases you requested do not exist: ' b'\\u0105","type":"OAuthException","code":803,"fbtrace_id":"H9yxnVcQFuA"}}'] In my mind, the simplest way forward would be to change the ?email? module to only parse lines using the ?universal newlines? algorithm. The /Lib/email/feedparser.py module should use StringIO(s, newline="").readlines() rather than s.splitlines(keepends=True). That would mean all email parsing behaviour would change; for instance, given the following message: >>> m = email.message_from_string( ... "WWW-Authenticate: abc\x85\r\n" ... "\r\n" ... ) instead of the current behaviour: >>> m.items() [('WWW-Authenticate', 'abc\x85')] >>> m.get_payload() '\r\n\r\n' it would change to: >>> m.items() [('WWW-Authenticate', 'abc\x85')] >>> m.get_payload() '' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 18:20:50 2015 From: report at bugs.python.org (Florian Hassanen) Date: Thu, 26 Nov 2015 23:20:50 +0000 Subject: [issue24960] Can't use pip or easy_install with embeddable zip file. In-Reply-To: <1440869782.83.0.207113001402.issue24960@psf.upfronthosting.co.za> Message-ID: <1448580050.46.0.563874718945.issue24960@psf.upfronthosting.co.za> Florian Hassanen added the comment: got this traceback: Traceback (most recent call last): File "setup.py", line 169, in dist = setuptools.setup(**setup_params) File "distutils\core.py", line 134, in setup File "...\setuptools\setuptools\dist.py", line 299, in parse_command_line result = _Distribution.parse_command_line(self) File "distutils\dist.py", line 469, in parse_command_line File "...\setuptools\setuptools\dist.py", line 679, in handle_display_options return _Distribution.handle_display_options(self, option_order) File "distutils\dist.py", line 672, in handle_display_options File "...\setuptools\setuptools\dist.py", line 439, in print_commands cmdclass = ep.resolve() File "...\setuptools\pkg_resources\__init__.py", line 2383, in resolve module = __import__(self.module_name, fromlist=['__name__'], level=0) File "...\setuptools\setuptools\command\build_py.py", line 10, in from setuptools.lib2to3_ex import Mixin2to3 File "...\setuptools\setuptools\lib2to3_ex.py", line 12, in from lib2to3.refactor import RefactoringTool, get_fixers_from_package File "", line 969, in _find_and_load File "", line 958, in _find_and_load_unlocked File "", line 664, in _load_unlocked File "", line 634, in _load_backward_compatible File "lib2to3\refactor.py", line 27, in File "", line 969, in _find_and_load File "", line 958, in _find_and_load_unlocked File "", line 664, in _load_unlocked File "", line 634, in _load_backward_compatible File "lib2to3\fixer_util.py", line 9, in File "", line 969, in _find_and_load File "", line 958, in _find_and_load_unlocked File "", line 664, in _load_unlocked File "", line 634, in _load_backward_compatible File "lib2to3\pygram.py", line 32, in File "lib2to3\pgen2\driver.py", line 121, in load_grammar File "lib2to3\pgen2\pgen.py", line 385, in generate_grammar File "lib2to3\pgen2\pgen.py", line 15, in __init__ FileNotFoundError: [Errno 2] No such file or directory: '...\\python-3.5.0-embed-amd64\\python35.zip\\lib2to3\\Grammar.txt' triggered e.g. by "python setup.py --help-commands" (when building setuptools) workaround is to extract "...\python-3.5.0-embed-amd64\python35.zip" into a __directory__ named exactly the same (hence a directory named "python35.zip" which replaces the original zip file) ---------- nosy: +Florian Hassanen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 18:23:45 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 26 Nov 2015 23:23:45 +0000 Subject: [issue25464] Tix HList header_exists should be "exist" In-Reply-To: <1445555946.1.0.542845821493.issue25464@psf.upfronthosting.co.za> Message-ID: <1448580225.9.0.600163083284.issue25464@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 19:18:56 2015 From: report at bugs.python.org (SpaceOne) Date: Fri, 27 Nov 2015 00:18:56 +0000 Subject: [issue25723] ConfigParser should never write broken configurations In-Reply-To: <1448379104.29.0.433011869224.issue25723@psf.upfronthosting.co.za> Message-ID: <1448583536.11.0.677634335358.issue25723@psf.upfronthosting.co.za> SpaceOne added the comment: Of course both of you have reasonable arguments. For compatibility with overridden SECTRE attributes it should not raise ValueError for characters like [ and ]. (too bad that SECTRE is a public attribute otherwise it could also be used to validate the name (SECTRE.match('[%s]')). What if somebody changed SECTRE to multiline? Then even rejecting '\n' would break compatibility. But: How often does this happen? In open source projects it seems none. A nullege.com and google search exposed that no project does this. Terry, I completely agree with your argument "that blindly inserting external input into a database is bad idea". But in the real world it happens that there are many applications out which doesn't validate what they pass into .add_section(). (Do you want me to give you a list of python projects which are either broken or vulnerable?). In my opinion this is dangerous, as well as not validating HTTP/Mail/MIME headers for such characters and so on. What's the goal of python here? Giving programmers nice utilities which have security considerations in its software design by default or giving everything up to the programmer which is forced to never trust the stdlib and always have to read the source code it uses? As I understand when I read the documentation is that config parser is loosely based on M$ INI files and as the name says it is for configuration files. Usually(!) configuration files are human readable files editable with an editor. Disallowing non-printable characters would have been the best option in the first release of config parser. >From my experience it is good to restrict things from the beginning and make them overrideable to be more relaxed if this is really needed. And regarding issue20923: I think it would be a great feature to include the code change instead of changing the documentation. In my research about add_section() I found some projects which uses URI's as section name. As you know the WWW is evolving and actually http://[::1]/ is a valid URI nowadays. If this would be changed these implementations will not have to overwrite SECTRE in the future and they also won't run into that bug one day. I adapted my commit to only disallow \r \n and \x00. [ ] are allowed for customization of SECTRE. https://github.com/spaceone/cpython/commit/a0cdb85e4c7c4dd71a87b1f6c4d9d92ece2dde15 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 19:26:18 2015 From: report at bugs.python.org (SpaceOne) Date: Fri, 27 Nov 2015 00:26:18 +0000 Subject: [issue25738] http.server doesn't handle RESET CONTENT status correctly Message-ID: <1448583978.87.0.253695569638.issue25738@psf.upfronthosting.co.za> New submission from SpaceOne: The status 205 RESET CONTENT is not correctly evaluated by http.server. It MUST NOT write a response body to the client. Patch: https://github.com/spaceone/cpython/commit/17048e2e7349cc4861c7fe90299f2c092b8e1604 ---------- components: Library (Lib) messages: 255443 nosy: spaceone priority: normal severity: normal status: open title: http.server doesn't handle RESET CONTENT status correctly _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 19:30:04 2015 From: report at bugs.python.org (SpaceOne) Date: Fri, 27 Nov 2015 00:30:04 +0000 Subject: [issue25739] Add PAYLOAD_TOO_LARGE (new name in RFC 7231) Message-ID: <1448584204.43.0.941086994375.issue25739@psf.upfronthosting.co.za> New submission from SpaceOne: Add PAYLOAD_TOO_LARGE status code to http package. Patch: https://github.com/spaceone/cpython/commit/5d9427a07bde43b523386322b1fc377618eadb76 ---------- components: Library (Lib) messages: 255444 nosy: spaceone priority: normal severity: normal status: open title: Add PAYLOAD_TOO_LARGE (new name in RFC 7231) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 19:35:22 2015 From: report at bugs.python.org (SpaceOne) Date: Fri, 27 Nov 2015 00:35:22 +0000 Subject: [issue25740] multiple issues in http.client Message-ID: <1448584522.19.0.187814376378.issue25740@psf.upfronthosting.co.za> New submission from SpaceOne: * RESET_CONTENT not evaluated * negative chunk size accepted * invalid ports accepted * success status !== 200 ignored Patch: https://github.com/spaceone/cpython/commit/3289080306408db971f8b816d3e9f0ab44ed392b Part of github Pull Request https://github.com/python/cpython/pull/19 from July. Should I split this up into multiple bugtracker issues? ---------- components: Library (Lib) messages: 255445 nosy: spaceone priority: normal severity: normal status: open title: multiple issues in http.client _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 19:38:56 2015 From: report at bugs.python.org (SpaceOne) Date: Fri, 27 Nov 2015 00:38:56 +0000 Subject: [issue25739] Add PAYLOAD_TOO_LARGE / URI_TOO_LONG (new name in RFC 7231) In-Reply-To: <1448584204.43.0.941086994375.issue25739@psf.upfronthosting.co.za> Message-ID: <1448584736.12.0.212088589488.issue25739@psf.upfronthosting.co.za> SpaceOne added the comment: Also URI_TOO_LONG has been changed. https://tools.ietf.org/html/rfc7231#section-6.5.11 https://tools.ietf.org/html/rfc7231#section-6.5.12 ---------- title: Add PAYLOAD_TOO_LARGE (new name in RFC 7231) -> Add PAYLOAD_TOO_LARGE / URI_TOO_LONG (new name in RFC 7231) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 20:54:54 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 27 Nov 2015 01:54:54 +0000 Subject: [issue25739] Add PAYLOAD_TOO_LARGE / URI_TOO_LONG (new name in RFC 7231) In-Reply-To: <1448584204.43.0.941086994375.issue25739@psf.upfronthosting.co.za> Message-ID: <1448589294.53.0.634963286338.issue25739@psf.upfronthosting.co.za> Martin Panter added the comment: In general, I?m not sure it is worth adding aliases for various names used in different RFCs. But you could argue that this is appropriate because the old names are unnecessarily long. Another example would be HTTPStatus.REQUESTED_RANGE_NOT_SATISFIABLE vs ?Range Not Satisfiable? . If we were to go ahead with this, it would need a documentation update. A test case would also be nice, ensuring that the new name is the ?one true? name, and the old name is an alias. ---------- nosy: +martin.panter stage: -> patch review type: -> enhancement versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 21:08:45 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 27 Nov 2015 02:08:45 +0000 Subject: [issue25738] http.server doesn't handle RESET CONTENT status correctly In-Reply-To: <1448583978.87.0.253695569638.issue25738@psf.upfronthosting.co.za> Message-ID: <1448590125.56.0.197043002505.issue25738@psf.upfronthosting.co.za> Martin Panter added the comment: I left some comments about the tangential changes on Git Hub. Can you write a test case for this? ---------- nosy: +martin.panter stage: -> patch review type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 21:45:27 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 27 Nov 2015 02:45:27 +0000 Subject: [issue25740] multiple issues in http.client In-Reply-To: <1448584522.19.0.187814376378.issue25740@psf.upfronthosting.co.za> Message-ID: <1448592327.13.0.751661970331.issue25740@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks for these fixes. It might be better to open other report(s) for the FIXME comments, so you can explain them better, and propose any ideas or possible solutions. For some of them, it may be more appropriate to just fix them in the next (3.6) release, such as the method case insensitivity thing (to minimize backwards compatibility problems). It would be good to have regression test cases for each bug fixed. Regarding folded header field values, I think there was some discussion about deprecating that ability in Issue 22928. Definitely needs a separate report. See Issue 23740 about various quirks with what objects and automatic encodings are accepted when sending a request. It is already a can of worms; I suggest not to make it any more complicated. Can you elaborate on accepting invalid ports? Is this related to Issue 24169? ---------- nosy: +martin.panter stage: -> patch review type: -> behavior versions: +Python 2.7, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 21:50:35 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 27 Nov 2015 02:50:35 +0000 Subject: [issue25740] multiple issues in http.client In-Reply-To: <1448584522.19.0.187814376378.issue25740@psf.upfronthosting.co.za> Message-ID: <1448592635.36.0.249666614761.issue25740@psf.upfronthosting.co.za> Martin Panter added the comment: I missed seeing the _get_hostport() change in the commit. So you are saying that values out of range 1?65535 should raise InvalidURL("nonnumeric port . . ."). The error message isn?t quite right. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 26 22:05:07 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 27 Nov 2015 03:05:07 +0000 Subject: [issue25660] tabs don't work correctly in python repl In-Reply-To: <1447876730.91.0.918964104484.issue25660@psf.upfronthosting.co.za> Message-ID: <1448593507.55.0.23246170093.issue25660@psf.upfronthosting.co.za> Martin Panter added the comment: Yury or anyone else: can you confirm if the patch works properly with a proper OS X or BSD libedit (rather than my questionable Linux version?). If so, I think it is okay to ignore my Linux problems, and I could look at fixing the compatibility when the readline module is not available. Another way to look at this may be to fix the Editline (libedit) library to more faithfully emulate the Gnu version. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 02:22:07 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 27 Nov 2015 07:22:07 +0000 Subject: [issue23914] pickle fails with SystemError In-Reply-To: <1428756762.72.0.925495036586.issue23914@psf.upfronthosting.co.za> Message-ID: <20151127072204.22378.3944@psf.io> Roundup Robot added the comment: New changeset 322060740b64 by Zachary Ware in branch '2.7': Issue #23914: Fix test_xpickle with python 2.4 and 2.5 https://hg.python.org/cpython/rev/322060740b64 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 02:27:39 2015 From: report at bugs.python.org (Zachary Ware) Date: Fri, 27 Nov 2015 07:27:39 +0000 Subject: [issue23914] pickle fails with SystemError In-Reply-To: <1428756762.72.0.925495036586.issue23914@psf.upfronthosting.co.za> Message-ID: <1448609259.73.0.689247897051.issue23914@psf.upfronthosting.co.za> Zachary Ware added the comment: This broke test_xpickle with python 2.4 and 2.5 due to 'b' prefixes and an import that's not actually used in the 2.7 patch; now fixed. The ware-gentoo-x86 buildslave now has pythons 2.4, 2.5, and 2.6 installed for test_xpickle to use. ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 02:57:42 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 27 Nov 2015 07:57:42 +0000 Subject: [issue23914] pickle fails with SystemError In-Reply-To: <1428756762.72.0.925495036586.issue23914@psf.upfronthosting.co.za> Message-ID: <1448611062.56.0.652076445141.issue23914@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Great! I afraid there were no buildbots with 2.4 and 2.5 for testing test_xpickle. Thank you Zachary! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 04:24:04 2015 From: report at bugs.python.org (Firat Ozgul) Date: Fri, 27 Nov 2015 09:24:04 +0000 Subject: [issue25741] Usual Installation Directory Message-ID: <1448616244.63.0.310461564489.issue25741@psf.upfronthosting.co.za> New submission from Firat Ozgul: Official documentation reads: "On Windows machines, the Python installation is usually placed in C:\Python35" However, as of Python 3.5.0, usual installation directory on Windows is %LOCALAPPDATA%\Programs\Python. ---------- assignee: docs at python components: Documentation messages: 255455 nosy: docs at python, firatozgul priority: normal severity: normal status: open title: Usual Installation Directory type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 05:02:20 2015 From: report at bugs.python.org (Laura Creighton) Date: Fri, 27 Nov 2015 10:02:20 +0000 Subject: [issue25741] Usual Installation Directory In-Reply-To: <1448616244.63.0.310461564489.issue25741@psf.upfronthosting.co.za> Message-ID: <1448618540.32.0.194482306773.issue25741@psf.upfronthosting.co.za> Laura Creighton added the comment: Where does it go if the user hasn't set %LOCALAPPDATA% ? ---------- nosy: +lac _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 05:20:48 2015 From: report at bugs.python.org (Firat Ozgul) Date: Fri, 27 Nov 2015 10:20:48 +0000 Subject: [issue25741] Usual Installation Directory In-Reply-To: <1448616244.63.0.310461564489.issue25741@psf.upfronthosting.co.za> Message-ID: <1448619648.46.0.914364533167.issue25741@psf.upfronthosting.co.za> Firat Ozgul added the comment: Correct me if I am wrong, but as far as I know, %LOCALAPPDATA% is always set in Windows. When you want to install Python for just one user (which is the default), files are installed into this directory (LOCALAPPDATA). If you choose to install Python for all users, however, files are installed into %PROGRAMFILES% or %PROGRAMFILES(x86)% ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 05:28:48 2015 From: report at bugs.python.org (Laura Creighton) Date: Fri, 27 Nov 2015 10:28:48 +0000 Subject: [issue25741] Usual Installation Directory In-Reply-To: <1448616244.63.0.310461564489.issue25741@psf.upfronthosting.co.za> Message-ID: <1448620128.05.0.300395424731.issue25741@psf.upfronthosting.co.za> Laura Creighton added the comment: I don't know the answer, but from the point of view of a webmaster who gets support requests and doesn't have a windows system, it would be very useful to already know where a person's python is supposed to be, and thus good if the documentation said something along the lines of: If the user does not specify %LOCALAPPDATA% then it defaults to assuming there is such a default, of course. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 05:56:07 2015 From: report at bugs.python.org (Firat Ozgul) Date: Fri, 27 Nov 2015 10:56:07 +0000 Subject: [issue25741] Usual Installation Directory In-Reply-To: <1448616244.63.0.310461564489.issue25741@psf.upfronthosting.co.za> Message-ID: <1448621767.59.0.558707644614.issue25741@psf.upfronthosting.co.za> Firat Ozgul added the comment: Actually, under 'Using Python on Windows' at https://docs.python.org/3/using/windows.html, the documentation correctly refers to %LOCALAPPDATA% and %PROGRAMFILES% or %PROGRAMFILES(x86)% environment variables as the default installation directories for just-for-me installs and for all-user installs, respectively. The information provided in the tutorial part of the documentation (where it refers C:\Python35 as the default location) contradicts the one provided under 'Using Python on Windows'. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 09:04:41 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 27 Nov 2015 14:04:41 +0000 Subject: [issue22233] http.client splits headers on non-\r\n characters In-Reply-To: <1408528953.84.0.772180232607.issue22233@psf.upfronthosting.co.za> Message-ID: <1448633081.98.0.251990086683.issue22233@psf.upfronthosting.co.za> R. David Murray added the comment: I agree. Can you update the email issue with this suggestion and/or a patch? The problem with this, of course is backward compatibility, but since it is more correct per the RFCs, our past policy has been to fix it anyway. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 09:54:09 2015 From: report at bugs.python.org (tierlieb) Date: Fri, 27 Nov 2015 14:54:09 +0000 Subject: [issue25742] locale.setlocale does not work with unicode strings Message-ID: <1448636049.37.0.145831829956.issue25742@psf.upfronthosting.co.za> New submission from tierlieb: Within locale.py in setlocale your have this piece of code: if locale and type(locale) is not type(""): # convert to string locale = normalize(_build_localename(locale)) That does not work with unicode strings as I found out after wondering quite a bit about the difference was between my tests and my production code... So either expand the check here to include type(u"") or make _build_localename smarter. ---------- components: Unicode messages: 255461 nosy: ezio.melotti, haypo, tierlieb priority: normal severity: normal status: open title: locale.setlocale does not work with unicode strings versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 10:18:46 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 27 Nov 2015 15:18:46 +0000 Subject: [issue25696] "make -j9 install" fails because bininstall target requires the libainstall target In-Reply-To: <1448202702.88.0.964294450431.issue25696@psf.upfronthosting.co.za> Message-ID: <1448637526.4.0.641702484999.issue25696@psf.upfronthosting.co.za> STINNER Victor added the comment: > $(LIBPC) is a single directory name, so I suggest dropping the ?for? loop. Ok, here is a version without loop. I also added "-" before the if to mimick other lines of the bininstall target. Does it look better now? > (...) there is technically still a race with ?libainstall? and ?bininstall? both testing and creating the same directory. Sorry, I don't understand. Is it an issue in practice to create the same directory twice "at the same time"? Are you able to reproduce the bug? Please try my use case: "./configure && make && make -j10 install" and enjoy the partial installation :-) (The python binary is installed in bin/ but it doesn't work because the stdlib is completly missing.) ---------- Added file: http://bugs.python.org/file41171/bininstall-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 10:50:58 2015 From: report at bugs.python.org (Zack Weinberg) Date: Fri, 27 Nov 2015 15:50:58 +0000 Subject: [issue25743] Clarify exactly what \w matches in UNICODE mode Message-ID: <1448639458.78.0.12264064003.issue25743@psf.upfronthosting.co.za> New submission from Zack Weinberg: The `re` module documentation does not do a good job of explaining exactly what `\w` matches. Quoting https://docs.python.org/3.5/library/re.html : > \w > For Unicode (str) patterns: > Matches Unicode word characters; this includes most characters > that can be part of a word in any language, as well as numbers > and the underscore. Empirically, this appears to mean "everything in Unicode general categories L* and N*, plus U+005F (underscore)". That is a perfectly sensible definition and the documentation should state it in those terms. "Unicode word characters" could mean any number of different things; note for instance that UTS#18 gives a very different definition. (Further reading: https://gist.github.com/zackw/3077f387591376c7bf67 plus links therefrom). ---------- assignee: docs at python components: Documentation messages: 255463 nosy: docs at python, zwol priority: normal severity: normal status: open title: Clarify exactly what \w matches in UNICODE mode versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From stephane at wirtel.be Fri Nov 20 12:46:28 2015 From: stephane at wirtel.be (Stephane Wirtel) Date: Fri, 20 Nov 2015 18:46:28 +0100 Subject: [issue25625] "chdir" Contex manager for pathlib In-Reply-To: <1447527503.2.0.866276605324.issue25625@psf.upfronthosting.co.za> References: <1447523143.32.0.921942004004.issue25625@psf.upfronthosting.co.za> <1447527503.2.0.866276605324.issue25625@psf.upfronthosting.co.za> Message-ID: <20151120174628.GA22243@sg1> What's the relation with subprocess ? -- St?phane Wirtel - http://wirtel.be - @matrixise From stephane at wirtel.be Fri Nov 20 17:19:29 2015 From: stephane at wirtel.be (Stephane Wirtel) Date: Fri, 20 Nov 2015 23:19:29 +0100 Subject: [issue25686] Don't use distutils in test_shutil In-Reply-To: <1448057615.39.0.634950011826.issue25686@psf.upfronthosting.co.za> References: <1448057615.39.0.634950011826.issue25686@psf.upfronthosting.co.za> Message-ID: <20151120221929.GA8855@sg1> Works fine on my laptop with 3.6. and the code is right -- St?phane Wirtel - http://wirtel.be - @matrixise From stephane at wirtel.be Mon Nov 23 08:51:41 2015 From: stephane at wirtel.be (Stephane Wirtel) Date: Mon, 23 Nov 2015 14:51:41 +0100 Subject: [issue25706] problems in library/base64.rst In-Reply-To: <1448286576.19.0.151141842639.issue25706@psf.upfronthosting.co.za> References: <1448285359.37.0.0735251263176.issue25706@psf.upfronthosting.co.za> <1448286576.19.0.151141842639.issue25706@psf.upfronthosting.co.za> Message-ID: <20151123135141.GA25726@sg1> Who can explain the problem ? I am ignorant about this issue. -- St?phane Wirtel - http://wirtel.be - @matrixise From stephane at wirtel.be Mon Nov 23 11:38:14 2015 From: stephane at wirtel.be (Stephane Wirtel) Date: Mon, 23 Nov 2015 17:38:14 +0100 Subject: [issue4744] asynchat documentation needs to be more precise In-Reply-To: <1448296496.11.0.352337152221.issue4744@psf.upfronthosting.co.za> References: <1230168171.56.0.381937953807.issue4744@psf.upfronthosting.co.za> <1448296496.11.0.352337152221.issue4744@psf.upfronthosting.co.za> Message-ID: <20151123163814.GE15060@sg1> Ok, in this case, I will provide the patch On 11/23, R. David Murray wrote: > > R. David Murray added the comment: > > Yes. The docs should be accurate, even if the module is deprecated. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > _______________________________________________ > Python-bugs-list mailing list > Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/stephane%40wirtel.be > -- St?phane Wirtel - http://wirtel.be - @matrixise From report at bugs.python.org Fri Nov 27 11:14:25 2015 From: report at bugs.python.org (Andi McClure) Date: Fri, 27 Nov 2015 16:14:25 +0000 Subject: [issue25743] Clarify exactly what \w matches in UNICODE mode In-Reply-To: <1448639458.78.0.12264064003.issue25743@psf.upfronthosting.co.za> Message-ID: <1448640865.65.0.17947416032.issue25743@psf.upfronthosting.co.za> Andi McClure added the comment: I would like to request also a clear explanation be given for the documentation in the 2.7 branch. From https://docs.python.org/2.7/library/re.html : "\w ... If UNICODE is set, this will match the characters [0-9_] plus whatever is classified as alphanumeric in the Unicode character properties database" This is ambiguous. Does it mean the "Alphabetic" property from UAX#44? Does it mean something else? ---------- nosy: +Andi McClure _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 11:35:23 2015 From: report at bugs.python.org (Brett Cannon) Date: Fri, 27 Nov 2015 16:35:23 +0000 Subject: [issue25741] Usual Installation Directory In-Reply-To: <1448616244.63.0.310461564489.issue25741@psf.upfronthosting.co.za> Message-ID: <1448642123.42.0.408531693574.issue25741@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: +steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 11:40:30 2015 From: report at bugs.python.org (Zack Weinberg) Date: Fri, 27 Nov 2015 16:40:30 +0000 Subject: [issue25743] Clarify exactly what \w matches in UNICODE mode In-Reply-To: <1448639458.78.0.12264064003.issue25743@psf.upfronthosting.co.za> Message-ID: <1448642430.55.0.605684152245.issue25743@psf.upfronthosting.co.za> Zack Weinberg added the comment: FWIW, the actual behavior of \w matching "everything in Unicode general categories L* and N*, plus U+005F (underscore)" is consistent across all versions I can conveniently test (2.7, 3.4, 3.5). In 2.7, there are four characters in general category Nl that \w doesn't match, but I believe that is just a bug, not an intentional difference of behavior. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 12:25:42 2015 From: report at bugs.python.org (Zachary Ware) Date: Fri, 27 Nov 2015 17:25:42 +0000 Subject: [issue25741] Usual Installation Directory In-Reply-To: <1448616244.63.0.310461564489.issue25741@psf.upfronthosting.co.za> Message-ID: <1448645142.59.0.172389708324.issue25741@psf.upfronthosting.co.za> Zachary Ware added the comment: Here's a patch to try to modernize the whole section a bit, and to remove one of the two other instances of 'Python35' in the docs (the other instance is in the docs for pyvenv, which needs its own overhaul in a separate issue). ---------- keywords: +patch nosy: +zach.ware versions: +Python 3.6 Added file: http://bugs.python.org/file41172/issue25741.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 12:38:30 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 27 Nov 2015 17:38:30 +0000 Subject: [issue25719] Deprecate spitfire benchmark In-Reply-To: <1448362459.17.0.918374944074.issue25719@psf.upfronthosting.co.za> Message-ID: <20151127173827.29808.60502@psf.io> Roundup Robot added the comment: New changeset 75751d838789 by Zachary Ware in branch 'default': Issue #25719: Deprecate spitfire benchmark. https://hg.python.org/benchmarks/rev/75751d838789 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 12:38:56 2015 From: report at bugs.python.org (Zachary Ware) Date: Fri, 27 Nov 2015 17:38:56 +0000 Subject: [issue25719] Deprecate spitfire benchmark In-Reply-To: <1448362459.17.0.918374944074.issue25719@psf.upfronthosting.co.za> Message-ID: <1448645936.85.0.84531504608.issue25719@psf.upfronthosting.co.za> Zachary Ware added the comment: Done. Thanks, Florin! ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 13:04:18 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 27 Nov 2015 18:04:18 +0000 Subject: [issue25744] Reference leaks in test_collections Message-ID: <1448647458.47.0.750758594214.issue25744@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: $ ./python -m test.regrtest -uall -R 3:3 test_collections [1/1] test_collections beginning 6 repetitions 123456 ...... test_collections leaked [-2, 0, 0] references, sum=-2 test_collections leaked [-1, 2, 1] memory blocks, sum=2 1 test failed: test_collections ---------- components: Extension Modules, Tests messages: 255469 nosy: rhettinger, serhiy.storchaka priority: normal severity: normal status: open title: Reference leaks in test_collections type: resource usage versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 13:04:42 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 27 Nov 2015 18:04:42 +0000 Subject: [issue25745] Reference leaks in test_curses Message-ID: <1448647482.06.0.750956111756.issue25745@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: $ ./python -m test.regrtest -uall -R 3:3 test_curses [1/1] test_curses beginning 6 repetitions 123456 . test_curses leaked [2, 2, 2] references, sum=6 test_curses leaked [0, 1, 2] memory blocks, sum=3 1 test failed: test_curses ---------- components: Extension Modules, Tests messages: 255470 nosy: serhiy.storchaka, twouters priority: normal severity: normal status: open title: Reference leaks in test_curses type: resource usage versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 13:07:31 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 27 Nov 2015 18:07:31 +0000 Subject: [issue25746] test_unittest failure in leaks searching mode Message-ID: <1448647651.46.0.84768072047.issue25746@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: $ ./python -m test.regrtest -uall -R 3:3 test_unittest [1/1] test_unittest test test_unittest failed -- multiple errors occurred; run in verbose mode for details 1 test failed: test_unittest $ ./python -m test.regrtest -vvuall -R 3:3 test_unittest ... ====================================================================== ERROR: test_discover_with_init_module_that_raises_SkipTest_on_import (unittest.test.test_discovery.TestDiscovery) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/serhiy/py/cpython-debug/Lib/unittest/test/test_discovery.py", line 532, in test_discover_with_init_module_that_raises_SkipTest_on_import pickle.loads(pickle.dumps(suite, proto)) _pickle.PicklingError: Can't pickle : attribute lookup ModuleSkipped on unittest.loader failed ====================================================================== ERROR: test_discover_with_module_that_raises_SkipTest_on_import (unittest.test.test_discovery.TestDiscovery) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/serhiy/py/cpython-debug/Lib/unittest/test/test_discovery.py", line 508, in test_discover_with_module_that_raises_SkipTest_on_import pickle.loads(pickle.dumps(suite, proto)) _pickle.PicklingError: Can't pickle : attribute lookup ModuleSkipped on unittest.loader failed ---------------------------------------------------------------------- ---------- components: Tests messages: 255471 nosy: ezio.melotti, michael.foord, rbcollins, serhiy.storchaka priority: normal severity: normal status: open title: test_unittest failure in leaks searching mode type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 13:13:07 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 27 Nov 2015 18:13:07 +0000 Subject: [issue25747] test_idle failure in leaks searching mode Message-ID: <1448647986.99.0.712792565134.issue25747@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: $ ./python -m test.regrtest -uall -R 3:3 test_idle [1/1] test_idle beginning 6 repetitions 123456 test test_idle failed -- Traceback (most recent call last): File "/home/serhiy/py/cpython-debug/Lib/idlelib/idle_test/test_warning.py", line 76, in test_idlever self.assertEqual(len(w), 1) AssertionError: 0 != 1 1 test failed: test_idle ---------- components: IDLE, Tests messages: 255472 nosy: kbk, roger.serwy, serhiy.storchaka, terry.reedy priority: normal severity: normal status: open title: test_idle failure in leaks searching mode type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 13:15:58 2015 From: report at bugs.python.org (Robert Collins) Date: Fri, 27 Nov 2015 18:15:58 +0000 Subject: [issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys In-Reply-To: <1429890469.94.0.27310602141.issue24053@psf.upfronthosting.co.za> Message-ID: <1448648158.85.0.27250746856.issue24053@psf.upfronthosting.co.za> Robert Collins added the comment: @Serhiy, EXIT_FAILURE is used in Python's C code itself (just once admittedly, and then we use 0 sometimes for success and sometimes for errors, and then 1 for errors... aiee.) FWIW to the extent that folk want to write posix code in Python, I'm all for helping them, I find the amount of help this will be to be hard to assess. There is some code to adding the constants in documentation and learning surface area. Right now we don't document all the ways Python can interact with exit codes, and I suspect thats actually a bigger burden than writing the code to generate any given code. ---------- nosy: +rbcollins _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 13:17:20 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 27 Nov 2015 18:17:20 +0000 Subject: [issue25687] Error during test case and tearDown In-Reply-To: <1448092467.41.0.746674123801.issue25687@psf.upfronthosting.co.za> Message-ID: <1448648240.6.0.0271523806221.issue25687@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: +ezio.melotti, michael.foord, rbcollins versions: +Python 3.5, Python 3.6 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 13:33:33 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 27 Nov 2015 18:33:33 +0000 Subject: [issue25704] Update the devguide to 3.5 In-Reply-To: <1448282986.29.0.990424693558.issue25704@psf.upfronthosting.co.za> Message-ID: <1448649213.76.0.827478881398.issue25704@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The section of committing.rst in question was updated from 3.3 and 3.4 to 3.4 and 3.5 in 414a7e2067b2 after 3.4 came out. I think we should continue to update it. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 13:33:42 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 27 Nov 2015 18:33:42 +0000 Subject: [issue25748] Resource warnings when run test_asyncio in leaks searching mode Message-ID: <1448649222.14.0.755060741285.issue25748@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: $ ./python -m test.regrtest -uall -R 3:3 test_asyncio [1/1] test_asyncio ... .Executing .start() done, defined at /home/serhiy/py/cpython-debug/Lib/test/test_asyncio/test_pep492.py:146> result=None created at /home/serhiy/py/cpython-debug/Lib/asyncio/base_events.py:317> took 0.133 seconds /home/serhiy/py/cpython-debug/Lib/threading.py:864: ResourceWarning: unclosed self._target(*self._args, **self._kwargs) returning true from eof_received() has no effect when using ssl returning true from eof_received() has no effect when using ssl /home/serhiy/py/cpython-debug/Lib/asyncio/base_events.py:379: ResourceWarning: unclosed event loop <_UnixSelectorEventLoop running=False closed=False debug=False> warnings.warn("unclosed event loop %r" % self, ResourceWarning) ... 1 test OK. Cited lines are repeated 6 times (for the number of test runs). ---------- components: Tests, asyncio messages: 255475 nosy: giampaolo.rodola, gvanrossum, haypo, pitrou, serhiy.storchaka, yselivanov priority: normal severity: normal status: open title: Resource warnings when run test_asyncio in leaks searching mode type: resource usage versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 14:28:36 2015 From: report at bugs.python.org (Ron Frederick) Date: Fri, 27 Nov 2015 19:28:36 +0000 Subject: [issue25749] asyncio.Server class documented but not exported Message-ID: <1448652516.67.0.0555030356133.issue25749@psf.upfronthosting.co.za> New submission from Ron Frederick: The asyncio documentation defines the class 'asyncio.Server' in section 18.5.1.15. However, this class is not exported by asyncio. It is defined in base_events.py but not in the __all__ list. The only class exported at the asyncio top level is asyncio.AbstractServer, defined in events.py. I think the documentation should match the exports. Either Server should be exported out of base_events.py, or the documentation should only refer to asyncio.AbstractServer. ---------- components: asyncio messages: 255476 nosy: Ron Frederick, gvanrossum, haypo, yselivanov priority: normal severity: normal status: open title: asyncio.Server class documented but not exported type: behavior versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 14:32:26 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 27 Nov 2015 19:32:26 +0000 Subject: [issue25749] asyncio.Server class documented but not exported In-Reply-To: <1448652516.67.0.0555030356133.issue25749@psf.upfronthosting.co.za> Message-ID: <1448652746.7.0.950083632844.issue25749@psf.upfronthosting.co.za> Yury Selivanov added the comment: Let's not export the Server class -- in uvloop, for instance, I have a completely different internal implementation of Server (I can't use the one from asyncio). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 14:40:18 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 27 Nov 2015 19:40:18 +0000 Subject: [issue25733] Idle does not handle non-standard compile errors In-Reply-To: <1448461598.38.0.392041411432.issue25733@psf.upfronthosting.co.za> Message-ID: <1448653218.52.0.811049848983.issue25733@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I believe startup files are compiled in PyShell.py, line 649 (3.x) try: code = compile(source, filename, "exec") except (OverflowError, SyntaxError): and editor code is compiled in ScriptBinding.py, line 100 try: # If successful, return the compiled code return compile(source, filename, "exec") except (SyntaxError, OverflowError, ValueError) as value: Adding SystemError to the tuple is trivial. I just need to test to verify. (Side note: I think the tuple should be the same for both. The reasons for entries other than SyntaxError should be documented. ValueError when compiling?) I believe that interactive input is forwarded to stdlib code.InteractiveInterpreter in PyShell.py, line 679 try: # InteractiveInterpreter.runsource() calls its runcode() method, # which is overridden (see below) return InteractiveInterpreter.runsource(self, source, filename) The compile call and error catching is inside Lib/code.py, line 57. try: code = self.compile(source, filename, symbol) except (OverflowError, SyntaxError, ValueError): It should be fixed here. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 14:40:42 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 27 Nov 2015 19:40:42 +0000 Subject: [issue25733] Idle does not handle non-standard compile errors In-Reply-To: <1448461598.38.0.392041411432.issue25733@psf.upfronthosting.co.za> Message-ID: <1448653242.93.0.856894669786.issue25733@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- assignee: -> terry.reedy stage: -> needs patch versions: +Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 14:53:29 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 27 Nov 2015 19:53:29 +0000 Subject: [issue25735] math.factorial doc should mention integer return type In-Reply-To: <1448480671.49.0.139605050425.issue25735@psf.upfronthosting.co.za> Message-ID: <1448654009.7.0.457512251249.issue25735@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I agree. In testing, I discovered this bug >>> factorial(decimal.Decimal(5.2)) 120 I don't know if this is a glitch in factorial or Decimal. I also noticed >>> fac(fractions.Fraction(4, 1)) Traceback (most recent call last): File "", line 1, in fac(fractions.Fraction(4, 1)) TypeError: an integer is required (got type Fraction) Perhaps this is due to no __int__ method. ---------- nosy: +facundobatista, mark.dickinson, rhettinger, skrah, terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 14:56:53 2015 From: report at bugs.python.org (Jeroen Demeyer) Date: Fri, 27 Nov 2015 19:56:53 +0000 Subject: [issue25750] tp_descr_get(self, obj, type) is called without owning a reference to "self" Message-ID: <1448654213.28.0.807225788685.issue25750@psf.upfronthosting.co.za> New submission from Jeroen Demeyer: `type_getattro()` calls `tp_descr_get(self, obj, type)` without actually owning a reference to "self". In very rare cases, this can cause a segmentation fault if "self" is deleted by the descriptor. Downstream: [http://trac.sagemath.org/ticket/19633] ---------- components: Interpreter Core files: descr_ref.patch keywords: patch messages: 255480 nosy: jdemeyer priority: normal severity: normal status: open title: tp_descr_get(self, obj, type) is called without owning a reference to "self" versions: Python 2.7 Added file: http://bugs.python.org/file41173/descr_ref.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 15:09:15 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 27 Nov 2015 20:09:15 +0000 Subject: [issue25742] locale.setlocale does not work with unicode strings In-Reply-To: <1448636049.37.0.145831829956.issue25742@psf.upfronthosting.co.za> Message-ID: <1448654955.95.0.674557884561.issue25742@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The doc for setlocale(category [,locale]) says "locale may be a string, or an iterable of two strings (language code and encoding)". The purpose of _build_locale is handle an iterable of two strings. This request looks like an enhancement request, which is not allowed for 2.7. I suspect that the locale locale module and doc predate the addition of unicode. I think this should be closed. ---------- nosy: +lemburg, loewis, terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 15:19:20 2015 From: report at bugs.python.org (Bernd Dietzel) Date: Fri, 27 Nov 2015 20:19:20 +0000 Subject: [issue25751] ctypes.util , Shell Injection in find_library() Message-ID: <1448655560.8.0.523539379986.issue25751@psf.upfronthosting.co.za> New submission from Bernd Dietzel: The find_library() function can execute code when special chars like ;|`<>$ are in the name. The "os.popen()" calls in the util.py script should be replaced with "subprocess.Popen()". Demo Exploits for Linux : ==================== >>> from ctypes.util import find_library >>> find_library(";xeyes") # runs xeyes >>> find_library("|xterm") # runs terminal >>> find_library("&gimp") # runs gimp >>> find_library("$(nautilus)") # runs filemanager >>> find_library(">test") # creates, and if exists, erases a file "test" ==== Traceback ==== >>> find_library("`xmessage hello`") # shows a message, press ctrl+c for Traceback ^CTraceback (most recent call last): File "", line 1, in File "/usr/lib/python3.4/ctypes/util.py", line 244, in find_library return _findSoname_ldconfig(name) or _get_soname(_findLib_gcc(name)) File "/usr/lib/python3.4/ctypes/util.py", line 99, in _findLib_gcc trace = f.read() KeyboardInterrupt https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1512068 ---------- components: ctypes files: workaround.diff keywords: patch messages: 255482 nosy: TheRegRunner priority: normal severity: normal status: open title: ctypes.util , Shell Injection in find_library() type: security versions: Python 2.7, Python 3.4 Added file: http://bugs.python.org/file41174/workaround.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 15:19:51 2015 From: report at bugs.python.org (ppperry) Date: Fri, 27 Nov 2015 20:19:51 +0000 Subject: [issue25733] Idle does not handle non-standard compile errors In-Reply-To: <1448461598.38.0.392041411432.issue25733@psf.upfronthosting.co.za> Message-ID: <1448655591.9.0.930042081408.issue25733@psf.upfronthosting.co.za> ppperry added the comment: A similar problem occurs with the TypeError produced by attempting to compile a null byte. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 15:35:53 2015 From: report at bugs.python.org (Jeroen Demeyer) Date: Fri, 27 Nov 2015 20:35:53 +0000 Subject: [issue9504] signal.signal/signal.alarm not working as expected In-Reply-To: <1280910836.88.0.645209486589.issue9504@psf.upfronthosting.co.za> Message-ID: <1448656553.53.0.718595941648.issue9504@psf.upfronthosting.co.za> Jeroen Demeyer added the comment: Just a comment: if you need really robust signal handling, you just cannot do it with pure Python. I would recommend using Cython, where one has complete control over when signals are checked. ---------- nosy: +jdemeyer _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 15:54:18 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 27 Nov 2015 20:54:18 +0000 Subject: [issue25747] test_idle failure in leaks searching mode In-Reply-To: <1448647986.99.0.712792565134.issue25747@psf.upfronthosting.co.za> Message-ID: <1448657658.38.0.380011339247.issue25747@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The test method was added in 3.5. with warnings.catch_warnings(record=True) as w: warnings.simplefilter("always") import idlelib.idlever self.assertEqual(len(w), 1) self.assertTrue(issubclass(w[-1].category, DeprecationWarning)) self.assertIn("version", str(w[-1].message)) It is copied replacements from https://docs.python.org/3.6/library/warnings.html#testing-warnings. I see that test.support has a wrapper that might or might be easier or make a difference. Replacing "import idlelib.idlever" with "test.support.import_fresh_module('idlelib.idlever')" might fix the problem. I will test after I install the 10GB VS2015 package needed to build 3.5/6 on Windows. ---------- versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 16:09:37 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 27 Nov 2015 21:09:37 +0000 Subject: [issue25733] Idle does not handle non-standard compile errors In-Reply-To: <1448461598.38.0.392041411432.issue25733@psf.upfronthosting.co.za> Message-ID: <1448658577.58.0.89826086354.issue25733@psf.upfronthosting.co.za> Terry J. Reedy added the comment: How lovely ;-) >>> compile(chr(0), '', 'eval') # 2.7, chr(0) is byte Traceback (most recent call last): File "", line 1, in compile(chr(0), '', 'eval') TypeError: compile() expected string without null bytes >>> compile(chr(0), '', 'eval') # 3.4, chr(0) is unichar Traceback (most recent call last): File "", line 1, in compile(chr(0), '', 'eval') ValueError: source code string cannot contain null bytes >>> compile(bytes(1), '', 'eval') # == 2.7 chr(0) Traceback (most recent call last): File "", line 1, in compile(bytes(1), '', 'eval') ValueError: source code string cannot contain null bytes I almost think the long tuple should be replaced by Exception. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 16:14:42 2015 From: report at bugs.python.org (ppperry) Date: Fri, 27 Nov 2015 21:14:42 +0000 Subject: [issue25733] Idle does not handle non-standard compile errors In-Reply-To: <1448461598.38.0.392041411432.issue25733@psf.upfronthosting.co.za> Message-ID: <1448658882.8.0.0320236600586.issue25733@psf.upfronthosting.co.za> ppperry added the comment: Why does compile not support null bytes in the first place? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 16:26:38 2015 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Fri, 27 Nov 2015 21:26:38 +0000 Subject: [issue25752] asyncio.readline - add customizable line separator Message-ID: <1448659598.46.0.288346349625.issue25752@psf.upfronthosting.co.za> New submission from ???? ?????????: In Python3.5 asyncio.StreamReader.readline() can separate lines only by b'\n'. For some task, I want actually "read until separator", where separator is another byte. Since I cannot create pull-request, I will write just here what I want: @coroutine def readline(self, separator=b'\n'): if not isinstance(separator, bytes) or len(separator) != 1: raise ValueError(separator) .... ichar = self._buffer.find(separator) .... ---------- components: asyncio messages: 255488 nosy: gvanrossum, haypo, mmarkk, yselivanov priority: normal severity: normal status: open title: asyncio.readline - add customizable line separator type: enhancement versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 16:34:59 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 27 Nov 2015 21:34:59 +0000 Subject: [issue25748] Resource warnings when run test_asyncio in leaks searching mode In-Reply-To: <1448649222.14.0.755060741285.issue25748@psf.upfronthosting.co.za> Message-ID: <1448660099.14.0.475983889313.issue25748@psf.upfronthosting.co.za> Martin Panter added the comment: I guess this is not a special property of the leaks search. These messages are seen normally as well, see Issue 25693 and Issue 25272. ---------- nosy: +martin.panter resolution: -> duplicate status: open -> closed superseder: -> asyncio tests are getting noisy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 16:38:23 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 27 Nov 2015 21:38:23 +0000 Subject: [issue25272] asyncio tests are getting noisy In-Reply-To: <1443553151.38.0.791479091232.issue25272@psf.upfronthosting.co.za> Message-ID: <1448660303.24.0.702458635824.issue25272@psf.upfronthosting.co.za> Martin Panter added the comment: New messages seen in Issue 25693 and Issue 25748: /tmp/cpython/Lib/threading.py:864: ResourceWarning: unclosed self._target(*self._args, **self._kwargs) . . . /tmp/cpython/Lib/asyncio/base_events.py:379: ResourceWarning: unclosed event loop <_UnixSelectorEventLoop running=False closed=False debug=False> warnings.warn("unclosed event loop %r" % self, ResourceWarning) ---------- versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 16:41:04 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 27 Nov 2015 21:41:04 +0000 Subject: [issue25753] Reference leaks in test_smtplib Message-ID: <1448660464.47.0.968238224363.issue25753@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: $ ./python -m test.regrtest -uall -R 3:3 test_smtplib [1/1] test_smtplib beginning 6 repetitions 123456 ...... test_smtplib leaked [0, 1, 1] references, sum=2 test_smtplib leaked [0, 1, 2] memory blocks, sum=3 1 test failed: test_smtplib ---------- components: Tests messages: 255491 nosy: serhiy.storchaka priority: normal severity: normal status: open title: Reference leaks in test_smtplib type: resource usage versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 16:43:30 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 27 Nov 2015 21:43:30 +0000 Subject: [issue25754] Test test_rlcompleter failed if run twice Message-ID: <1448660610.8.0.576604023002.issue25754@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: $ ./python -m test.regrtest test_rlcompleter test_rlcompleter [1/2] test_rlcompleter [2/2] test_rlcompleter test test_rlcompleter failed -- Traceback (most recent call last): File "/home/serhiy/py/cpython-debug/Lib/test/test_rlcompleter.py", line 66, in test_attr_matches ['CompleteMe.mro(', 'CompleteMe.spam']) AssertionError: Lists differ: ['CompleteMe.me(', 'CompleteMe.mro(', 'CompleteMe.spam'] != ['CompleteMe.mro(', 'CompleteMe.spam'] First differing element 0: CompleteMe.me( CompleteMe.mro( First list contains 1 additional elements. First extra element 2: CompleteMe.spam - ['CompleteMe.me(', 'CompleteMe.mro(', 'CompleteMe.spam'] ? ------------------ + ['CompleteMe.mro(', 'CompleteMe.spam'] 1 test OK. 1 test failed: test_rlcompleter ---------- components: Tests messages: 255492 nosy: martin.panter, serhiy.storchaka priority: normal severity: normal status: open title: Test test_rlcompleter failed if run twice type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 16:45:16 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 27 Nov 2015 21:45:16 +0000 Subject: [issue25755] Test test_property failed if run twice Message-ID: <1448660716.3.0.167851724474.issue25755@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: $ ./python -m test.regrtest test_property test_property [1/2] test_property [2/2] test_property test test_property failed -- Traceback (most recent call last): File "/home/serhiy/py/cpython-debug/Lib/test/test_property.py", line 172, in test_property_decorator_doc_writable self.assertEqual(sub.__class__.spam.__doc__, 'Eggs') AssertionError: 'Spam' != 'Eggs' - Spam + Eggs 1 test OK. 1 test failed: test_property ---------- components: Tests messages: 255493 nosy: serhiy.storchaka priority: normal severity: normal status: open title: Test test_property failed if run twice type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 16:47:06 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Fri, 27 Nov 2015 21:47:06 +0000 Subject: [issue25742] locale.setlocale does not work with unicode strings In-Reply-To: <1448636049.37.0.145831829956.issue25742@psf.upfronthosting.co.za> Message-ID: <1448660826.58.0.15256436993.issue25742@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: I wouldn't say this is a feature request. What the code wanted to check is "if this is an iterable of two strings, convert these to a locale string". I have no idea why the doc string uses "iterable". IMO, a tuple of two strings would have been fine and make the test case a lot simpler - too late to fix, though. If the code works with Unicode strings, I think we can change the test to: if locale and not isinstance(locale, basestring): ... In Python 3, the function will only accept Unicode strings, so no need to fix things there. @tierlieb: Could you provide a patch with test for this ? Thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 16:54:00 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 27 Nov 2015 21:54:00 +0000 Subject: [issue25755] Test test_property failed if run twice In-Reply-To: <1448660716.3.0.167851724474.issue25755@psf.upfronthosting.co.za> Message-ID: <1448661240.05.0.967721242793.issue25755@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: As result the test is failed in leaks searching mode. $ ./python -m test.regrtest -uall -R 3:3 test_property [1/1] test_property beginning 6 repetitions 123456 test test_property failed -- Traceback (most recent call last): File "/home/serhiy/py/cpython-debug/Lib/test/test_property.py", line 172, in test_property_decorator_doc_writable self.assertEqual(sub.__class__.spam.__doc__, 'Eggs') AssertionError: 'Spam' != 'Eggs' - Spam + Eggs 1 test failed: test_property ---------- nosy: +berker.peksag, rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 17:11:14 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 27 Nov 2015 22:11:14 +0000 Subject: [issue25742] locale.setlocale does not work with unicode strings In-Reply-To: <1448636049.37.0.145831829956.issue25742@psf.upfronthosting.co.za> Message-ID: <1448662274.28.0.047522828432.issue25742@psf.upfronthosting.co.za> STINNER Victor added the comment: I don't see the benefit of supporting Unicode strings for setlocale() arguments: locale name are always encodable to ASCII, so loc.decode('ascii') is enough to workaround the issue. But well, I think it's ok if it doesn't make the code much more complex ;-) I wrote a patch, what do you think? Is it worth it? ;-) ---------- keywords: +patch Added file: http://bugs.python.org/file41175/setlocale_unicode.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 17:18:54 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 27 Nov 2015 22:18:54 +0000 Subject: [issue25749] asyncio.Server class documented but not exported In-Reply-To: <1448652746.7.0.950083632844.issue25749@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Yeah, I recall this point. The doc points to Server, but Guido didn't want to expose "implementation details" of Server like sockets. Different implementations of event loops (Yury gave the good example of uvloop based on libuv) don't give (direct) access to sockets. The problem is maybe that we try to document two different things at the same place: asyncio "portable" API (the PEP 3156), and the implementation of "default" event loops. Even if it's not possible to directly use server sockets, it's kind of useful to get them. What do you think? Server.sockets is documented at: https://docs.python.org/dev/library/asyncio-eventloop.html#asyncio.Server.sockets Server.sockets is explicitly documented at: https://docs.python.org/dev/library/asyncio-eventloop.html#asyncio.BaseEventLoop.create_server I would prefer to keep the Server.sockets doc, but explain better that it's an "implementation detail". We already have something similar for "CPython" implementation details in the doc. Examples: - https://docs.python.org/dev/library/sys.html#sys._debugmallocstats - https://docs.python.org/dev/library/sys.html#sys._getframe - https://docs.python.org/dev/library/dis.html#module-dis - etc. What do you think of reusing the ".. impl-detail:" markup? Or do you prefer to write a different kind of box for asyncio? Or just not box and a simple sentence? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 17:28:22 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Fri, 27 Nov 2015 22:28:22 +0000 Subject: [issue25742] locale.setlocale does not work with unicode strings In-Reply-To: <1448662274.28.0.047522828432.issue25742@psf.upfronthosting.co.za> Message-ID: <5658D8FD.1090204@egenix.com> Marc-Andre Lemburg added the comment: On 27.11.2015 23:11, STINNER Victor wrote: > > STINNER Victor added the comment: > > I don't see the benefit of supporting Unicode strings for setlocale() arguments: locale name are always encodable to ASCII, so loc.decode('ascii') is enough to workaround the issue. > > But well, I think it's ok if it doesn't make the code much more complex ;-) > > I wrote a patch, what do you think? Thanks :-) > Is it worth it? ;-) I think so, since the current failure for Unicode is rather obscure. BTW: Why did you use (_str, _unicode) instead of basestring ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 17:44:51 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 27 Nov 2015 22:44:51 +0000 Subject: [issue9504] signal.signal/signal.alarm not working as expected In-Reply-To: <1280910836.88.0.645209486589.issue9504@psf.upfronthosting.co.za> Message-ID: <1448664291.07.0.490158465015.issue9504@psf.upfronthosting.co.za> STINNER Victor added the comment: I don't understand this issue. I would expect that a system call fails with EINTR if it is interrupted by a signal. Python explicitly configures the C library to get EINTR errors: automatic retry is disabled when Python sets its signal handlers. If a system call doesn't fail, what shoud we do with the result, especially when reading data (read/recv)? Yes, we _can_ checks to check regulary if we got a C signal by adding checks, but it's unclear to me if we must raise the exception immediatly, or later. Immedialty if I understand correctly the initial message. So should we check *all* system calls, or only system calls well known to block on I/O, like read/write, send/recv, select, etc.? Do we try to workaround design choices by the Linux kernel and the GNU libc? Right now, my favorite choice would be to do nothing. Yes, sometimes signals are delayed. Sometimes, a signal doesn't interrupt immediatly a blocked program. It's not perfect. But it's already very complex, I'm not sure that I want to make the code even more complex to check for signals in more places. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 17:49:32 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 27 Nov 2015 22:49:32 +0000 Subject: [issue25752] asyncio.readline - add customizable line separator In-Reply-To: <1448659598.46.0.288346349625.issue25752@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: I like the idea. It's common in protocols to have different kinds of "terminators" to mark the end of a message. C strings use a null byte for example. I would be trivial to accept other terminators, since we don't store received bytes as lines, but as a raw byte string (technically in a bytearray). > if not isinstance(separator, bytes) or len(separator) != 1: Yes, we should only reject empty terminator string. But terminator strings of more than 1 character are fine, no? I don't think that we need to put an arbitrary limitation here. > Since I cannot create pull-request, I will write just here what I want: Oh, what is your problem? You can use https://github.com/python/asyncio ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 17:50:44 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 27 Nov 2015 22:50:44 +0000 Subject: [issue25742] locale.setlocale does not work with unicode strings In-Reply-To: <1448636049.37.0.145831829956.issue25742@psf.upfronthosting.co.za> Message-ID: <1448664644.79.0.651910747219.issue25742@psf.upfronthosting.co.za> STINNER Victor added the comment: > BTW: Why did you use (_str, _unicode) instead of basestring ? Serhiy usually insists that technically, it's possible to compile Python 2.7 without Unicode support. I don't believe that anyone uses this crazy feature, but well, it was easier to use _unicode (which is already defined) than trying to run a poll on python users :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 17:55:07 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 27 Nov 2015 22:55:07 +0000 Subject: [issue25749] asyncio.Server class documented but not exported In-Reply-To: <1448652516.67.0.0555030356133.issue25749@psf.upfronthosting.co.za> Message-ID: <1448664907.95.0.0568451318326.issue25749@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Yeah, I recall this point. The doc points to Server, but Guido didn't want to expose "implementation details" of Server like sockets. Different implementations of event loops (Yury gave the good example of uvloop based on libuv) don't give (direct) access to sockets. I actually found a way to extract a fileno (there is an API for that). But Ron suggested to actually export the Server class, so that it's available as 'asyncio.Server'. And I think that *that* is a bad idea, since the actual implementation of Server is tied to event loop and transports, which may be implemented differently (as in uvloop) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 17:55:39 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 27 Nov 2015 22:55:39 +0000 Subject: [issue25742] locale.setlocale does not work with unicode strings In-Reply-To: <1448636049.37.0.145831829956.issue25742@psf.upfronthosting.co.za> Message-ID: <20151127225536.87873.60784@psf.io> Roundup Robot added the comment: New changeset 7841e9b614eb by Victor Stinner in branch '2.7': Closes #25742: locale.setlocale() now accepts a Unicode string for its second https://hg.python.org/cpython/rev/7841e9b614eb ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 17:56:23 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Fri, 27 Nov 2015 22:56:23 +0000 Subject: [issue25742] locale.setlocale does not work with unicode strings In-Reply-To: <1448664644.79.0.651910747219.issue25742@psf.upfronthosting.co.za> Message-ID: <5658DF8D.9@egenix.com> Marc-Andre Lemburg added the comment: On 27.11.2015 23:50, STINNER Victor wrote: > > STINNER Victor added the comment: > >> BTW: Why did you use (_str, _unicode) instead of basestring ? > > Serhiy usually insists that technically, it's possible to compile Python 2.7 without Unicode support. I don't believe that anyone uses this crazy feature, but well, it was easier to use _unicode (which is already defined) than trying to run a poll on python users :-) Hmm, but basestring is always defined, even when Python is compiled without Unicode support (which I agree is not used much these days). unicode won't exist in such a Python version, so basestring is actually safer to use than the tuple. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 17:59:16 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 27 Nov 2015 22:59:16 +0000 Subject: [issue25749] asyncio.Server class documented but not exported In-Reply-To: <1448664907.95.0.0568451318326.issue25749@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Yury Selivanov added the comment: > But Ron suggested to actually export the Server class, so that it's available as 'asyncio.Server'. And I think that *that* is a bad idea, (...) I know, but IMHO the issue is wider than just exporting or not the symbol. Right now, create_server() doc explicitly says that the list of sockets is available in server.sockets attribute. We should mention that it's not always the case, it's only available on "some" implementations of event loops. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 18:00:41 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 27 Nov 2015 23:00:41 +0000 Subject: [issue25742] locale.setlocale does not work with unicode strings In-Reply-To: <5658DF8D.9@egenix.com> Message-ID: STINNER Victor added the comment: Marc-Andre Lemburg added the comment: > Hmm, but basestring is always defined, even when Python is compiled > without Unicode support (...) Oh, I didn't know. Well, I already pushed my patch and it works. Feel free to modify locale.py to use basestring. I'm not interested to spend time on this *minor* issue anymore ;-) Thanks for the review.by the way. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 18:03:47 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Fri, 27 Nov 2015 23:03:47 +0000 Subject: [issue25742] locale.setlocale does not work with unicode strings In-Reply-To: Message-ID: <5658E149.6030703@egenix.com> Marc-Andre Lemburg added the comment: On 28.11.2015 00:00, STINNER Victor wrote: > > STINNER Victor added the comment: > > Marc-Andre Lemburg added the comment: >> Hmm, but basestring is always defined, even when Python is compiled >> without Unicode support (...) > > Oh, I didn't know. Well, I already pushed my patch and it works. Feel > free to modify locale.py to use basestring. I'm not interested to > spend time on this *minor* issue anymore ;-) No big deal. There are probably lots more places in the stdlib which break without Unicode compiled in... :-) > Thanks for the review.by the way. Thanks for the patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 18:22:05 2015 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Fri, 27 Nov 2015 23:22:05 +0000 Subject: [issue25756] asyncio WriteTransport documentation typo Message-ID: <1448666524.97.0.228973534452.issue25756@psf.upfronthosting.co.za> New submission from ???? ?????????: Here is the match against master. Doc/library/asyncio-protocol.rst: @@ -156,9 +156,9 @@ WriteTransport high-water limit is given, the low-water limit defaults to an implementation-specific value less than or equal to the high-water limit. Setting *high* to zero forces *low* to zero as - well, and causes :meth:`pause_writing` to be called whenever the + well, and causes :meth:`resume_writing` to be called whenever the buffer becomes non-empty. Setting *low* to zero causes - :meth:`resume_writing` to be called only once the buffer is empty. + :meth:`pause_writing` to be called only once the buffer is empty. Use of zero for either limit is generally sub-optimal as it reduces opportunities for doing I/O and computation concurrently. ---------- assignee: docs at python components: Documentation messages: 255508 nosy: docs at python, mmarkk priority: normal severity: normal status: open title: asyncio WriteTransport documentation typo type: enhancement versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 18:23:27 2015 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Fri, 27 Nov 2015 23:23:27 +0000 Subject: [issue21579] Python 3.4: tempfile.close attribute does not work In-Reply-To: <1401083279.44.0.182194375794.issue21579@psf.upfronthosting.co.za> Message-ID: <1448666607.11.0.159426113575.issue21579@psf.upfronthosting.co.za> ???? ????????? added the comment: No activity last week ? Why not to merge ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 18:25:48 2015 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Fri, 27 Nov 2015 23:25:48 +0000 Subject: [issue25608] ascynio readexactly() should raise ValueError if passed length <= 0 in argument In-Reply-To: <1447355475.79.0.931064144901.issue25608@psf.upfronthosting.co.za> Message-ID: <1448666748.19.0.526768219477.issue25608@psf.upfronthosting.co.za> ???? ????????? added the comment: result of readexactly(0) is indistinguishable from EOF, so no one should try to use that as I think. What is the useful case when zero bytes should be read ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 18:43:52 2015 From: report at bugs.python.org (Torsten Landschoff) Date: Fri, 27 Nov 2015 23:43:52 +0000 Subject: [issue25757] Subclasses of property lose docstring Message-ID: <1448667832.51.0.334598445629.issue25757@psf.upfronthosting.co.za> New submission from Torsten Landschoff: I actually found this in Python2, but it is still unchanged in Python 3.6 dev. Namely, creating an instance of a class derived from property will drop the docstring passed explicitly to the constructor: torsten at defiant:~$ python3.6 Python 3.6.0a0 (default:9fcfdb53e8af, Nov 27 2015, 23:11:09) [GCC 4.8.4] on linux Type "help", "copyright", "credits" or "license" for more information. >>> property(doc="Hello world").__doc__ 'Hello world' >>> class SubProp(property): pass ... >>> SubProp(doc="Hello world").__doc__ >>> This war surprising to me. I actually used a subclass of property to describe fields of configuration classes with extensive documentation, which disappeared during runtime. In Python2 I work around this by assigning to __doc__ as the last thing in the constructor of my SubProp class. ---------- components: Interpreter Core messages: 255511 nosy: torsten priority: normal severity: normal status: open title: Subclasses of property lose docstring type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 18:45:24 2015 From: report at bugs.python.org (Torsten Landschoff) Date: Fri, 27 Nov 2015 23:45:24 +0000 Subject: [issue25757] Subclasses of property lose docstring In-Reply-To: <1448667832.51.0.334598445629.issue25757@psf.upfronthosting.co.za> Message-ID: <1448667924.79.0.331601576113.issue25757@psf.upfronthosting.co.za> Torsten Landschoff added the comment: Here is a proposed patch to correct this including regression tests. ---------- keywords: +patch Added file: http://bugs.python.org/file41176/subprop_doc.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 18:47:37 2015 From: report at bugs.python.org (Torsten Landschoff) Date: Fri, 27 Nov 2015 23:47:37 +0000 Subject: [issue25757] Subclasses of property lose docstring In-Reply-To: <1448667832.51.0.334598445629.issue25757@psf.upfronthosting.co.za> Message-ID: <1448668057.31.0.582982663604.issue25757@psf.upfronthosting.co.za> Torsten Landschoff added the comment: Just a note about the patch: I changed the behaviour a bit in that the code does not ignore random exceptions while getting getter.__doc__. I think that would be surprising for most users and it also does not match the application of the doc field to the subclass, where exceptions are propagated. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 19:11:05 2015 From: report at bugs.python.org (STINNER Victor) Date: Sat, 28 Nov 2015 00:11:05 +0000 Subject: [issue25742] locale.setlocale does not work with unicode strings In-Reply-To: <5658E149.6030703@egenix.com> Message-ID: STINNER Victor added the comment: Marc-Andre Lemburg added the comment: > No big deal. There are probably lots more places in the stdlib which > break without Unicode compiled in... :-) Well, to have more fun, try to run any Python application with a Python compiled without Unicode support *and* without thread support :-D ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 20:09:38 2015 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 28 Nov 2015 01:09:38 +0000 Subject: [issue25608] ascynio readexactly() should raise ValueError if passed length <= 0 in argument In-Reply-To: <1447355475.79.0.931064144901.issue25608@psf.upfronthosting.co.za> Message-ID: <1448672978.13.0.704323688366.issue25608@psf.upfronthosting.co.za> Guido van Rossum added the comment: read(0) on a regular stream and os.read(fd, 0) also return an empty string without error. This is not something we should keep debating. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 20:15:20 2015 From: report at bugs.python.org (irdb) Date: Sat, 28 Nov 2015 01:15:20 +0000 Subject: [issue25522] IDLE: warn if save-as name matches stdlib name In-Reply-To: <1446270102.89.0.424617028731.issue25522@psf.upfronthosting.co.za> Message-ID: <1448673320.64.0.454620322585.issue25522@psf.upfronthosting.co.za> Changes by irdb : ---------- nosy: +irdb _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 20:28:13 2015 From: report at bugs.python.org (STINNER Victor) Date: Sat, 28 Nov 2015 01:28:13 +0000 Subject: [issue10399] AST Optimization: inlining of function calls In-Reply-To: <1289593012.28.0.71054855235.issue10399@psf.upfronthosting.co.za> Message-ID: <1448674093.53.0.000812997459341.issue10399@psf.upfronthosting.co.za> STINNER Victor added the comment: "Can we resurrect this, perhaps by taking it up on python-dev?" I created a new "FAT Python" project to reimplement such kind of optimizations with a similar design (similar but different ;-)): https://faster-cpython.readthedocs.org/fat_python.html ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 20:30:45 2015 From: report at bugs.python.org (Emanuel Barry) Date: Sat, 28 Nov 2015 01:30:45 +0000 Subject: [issue25757] Subclasses of property lose docstring In-Reply-To: <1448667832.51.0.334598445629.issue25757@psf.upfronthosting.co.za> Message-ID: <1448674245.09.0.774644488409.issue25757@psf.upfronthosting.co.za> Emanuel Barry added the comment: Pointed out a refleak and a small nit. ---------- nosy: +ebarry stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 20:34:32 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 28 Nov 2015 01:34:32 +0000 Subject: [issue22233] http.client splits headers on non-\r\n characters In-Reply-To: <1408528953.84.0.772180232607.issue22233@psf.upfronthosting.co.za> Message-ID: <1448674472.49.0.211543280013.issue22233@psf.upfronthosting.co.za> Martin Panter added the comment: David: what is the email issue you mentioned? In the mean time, I am uploading a patch to this issue. It seems using StringIO is a bit slower than str.splitlines(). I found a way to optimize building long lines, which compensated a lot of the loss, but this optimization would apply even without using StringIO. My patch makes test.test_email 0.3% slower (the optimization alone would make it 4.4% faster), and test_email.TestFeedParsers.test_long_lines() is 3% slower (optimization 12% faster). I also tried two other alternatives to str.splitlines(), but they were both slower than the StringIO technique: * _partial is a list of UTF-8 bytes; join and use bytes.splitlines() * _partial is a UTF-8 bytearray; use bytearray.splitlines() ---------- keywords: +patch stage: needs patch -> patch review versions: +Python 3.6 Added file: http://bugs.python.org/file41177/crlf-headers.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 21:29:17 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 28 Nov 2015 02:29:17 +0000 Subject: [issue25696] "make -j9 install" fails because bininstall target requires the libainstall target In-Reply-To: <1448202702.88.0.964294450431.issue25696@psf.upfronthosting.co.za> Message-ID: <1448677757.12.0.794508241664.issue25696@psf.upfronthosting.co.za> Martin Panter added the comment: I agree your patches should fix your practical bug (I can reproduce it, two out of three times). My concern is more about making the code cleaner and less likely to grow problems in the future. :) The worse case with patch 3 would be the ?Creating directory? message being echoed twice. I am just trying to get the makefile cleaner. If that block compiled a file, instead of just creating a directory, then it would be a worse problem. The second compile command could truncate the first version, causing errors later on. Also, I don?t believe adding the dash (-) prefix is a good idea here. It tells Make to keep going even if the command failed. In this case, if the directory already exists, the ?if? statement will succeed, and the only way it can fail is if $(INSTALL) fails, which I think we would want to know about. The original ?for? loop under libainstall does not include a dash. bininstall-4.patch implements my suggestion from before. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 21:30:05 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 28 Nov 2015 02:30:05 +0000 Subject: [issue25696] "make -j9 install" fails because bininstall target requires the libainstall target In-Reply-To: <1448202702.88.0.964294450431.issue25696@psf.upfronthosting.co.za> Message-ID: <1448677805.29.0.642767967854.issue25696@psf.upfronthosting.co.za> Changes by Martin Panter : Added file: http://bugs.python.org/file41178/bininstall-4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 22:04:18 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 28 Nov 2015 03:04:18 +0000 Subject: [issue9504] signal.signal/signal.alarm not working as expected In-Reply-To: <1280910836.88.0.645209486589.issue9504@psf.upfronthosting.co.za> Message-ID: <1448679858.68.0.391008159402.issue9504@psf.upfronthosting.co.za> Martin Panter added the comment: Okay, I tend to agree, and don?t have a problem with rejecting this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 22:13:50 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 28 Nov 2015 03:13:50 +0000 Subject: [issue25754] Test test_rlcompleter failed if run twice In-Reply-To: <1448660610.8.0.576604023002.issue25754@psf.upfronthosting.co.za> Message-ID: <1448680430.48.0.399272657438.issue25754@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a possible fix, just using mock.patch.object() and a context manager to remove the attribute after the test. ---------- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file41179/repeat-rlcompleter.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 22:27:25 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 28 Nov 2015 03:27:25 +0000 Subject: [issue22636] avoid using a shell in ctypes.util: replace os.popen with subprocess In-Reply-To: <1413325975.89.0.175884398711.issue22636@psf.upfronthosting.co.za> Message-ID: <1448681245.7.0.188668513397.issue22636@psf.upfronthosting.co.za> Martin Panter added the comment: See Issue 25751 for some demo exploits on Linux, if anyone wants inspiration for test cases. Maybe this should be applied as a bug fix. I haven?t looked at the patch, other than confirming it removes all five os.popen() calls. ---------- nosy: +martin.panter stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 22:28:16 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 28 Nov 2015 03:28:16 +0000 Subject: [issue22636] avoid using a shell in ctypes.util: replace os.popen with subprocess In-Reply-To: <1413325975.89.0.175884398711.issue22636@psf.upfronthosting.co.za> Message-ID: <1448681296.5.0.371544750345.issue22636@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- components: +ctypes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 22:29:09 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 28 Nov 2015 03:29:09 +0000 Subject: [issue25751] ctypes.util , Shell Injection in find_library() In-Reply-To: <1448655560.8.0.523539379986.issue25751@psf.upfronthosting.co.za> Message-ID: <1448681349.3.0.793424791431.issue25751@psf.upfronthosting.co.za> Martin Panter added the comment: There is a patch at Issue 22636 which looks like it replaces all five os.popen() calls. ---------- nosy: +martin.panter resolution: -> duplicate status: open -> closed superseder: -> avoid using a shell in ctypes.util: replace os.popen with subprocess _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 22:31:02 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 28 Nov 2015 03:31:02 +0000 Subject: [issue25751] ctypes.util , Shell Injection in find_library() In-Reply-To: <1448655560.8.0.523539379986.issue25751@psf.upfronthosting.co.za> Message-ID: <1448681462.01.0.145087021356.issue25751@psf.upfronthosting.co.za> Martin Panter added the comment: Your Ubuntu link seems broken, or is that a private report? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 23:19:51 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 28 Nov 2015 04:19:51 +0000 Subject: [issue14826] urllib2.urlopen fails to load URL In-Reply-To: <1337158473.64.0.398540003062.issue14826@psf.upfronthosting.co.za> Message-ID: <1448684391.16.0.408349531235.issue14826@psf.upfronthosting.co.za> Martin Panter added the comment: FWIW urlopen() already handles space characters in the Location target of redirects; see HTTPRedirectHandler.redirect_request(). So I think it is reasonable to handle space characters in user-supplied URLs also, if it is done properly. ---------- nosy: +martin.panter resolution: fixed -> stage: resolved -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 23:36:35 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 28 Nov 2015 04:36:35 +0000 Subject: [issue25741] Usual Installation Directory In-Reply-To: <1448616244.63.0.310461564489.issue25741@psf.upfronthosting.co.za> Message-ID: <1448685395.72.0.0335769163984.issue25741@psf.upfronthosting.co.za> Steve Dower added the comment: That patch looks good to me. LOCALAPPDATA is set by the operating system, typically to C:\Users\\AppData\Local (at least since Vista I think? Certainly since Win7). While it's possible to customize it, people who know how to do that won't be emailing webmasters expecting technical support. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 23:46:40 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 28 Nov 2015 04:46:40 +0000 Subject: [issue25252] Hard-coded line ending in asyncio.streams.StreamReader.readline In-Reply-To: <1443393275.12.0.244806076878.issue25252@psf.upfronthosting.co.za> Message-ID: <1448686000.44.0.0716206895668.issue25252@psf.upfronthosting.co.za> Martin Panter added the comment: Eric seems to have retracted this proposal, however Issue 25752 has also been opened, which sounds very similar. ---------- nosy: +martin.panter status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 27 23:49:49 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 28 Nov 2015 04:49:49 +0000 Subject: [issue18082] Inconsistent behavior of IOBase methods on closed files In-Reply-To: <1369758688.03.0.231740499906.issue18082@psf.upfronthosting.co.za> Message-ID: <1448686189.21.0.366893667961.issue18082@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 28 00:01:21 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 28 Nov 2015 05:01:21 +0000 Subject: [issue16151] Deferred KeyboardInterrupt in interactive mode In-Reply-To: <1349551962.43.0.949416732292.issue16151@psf.upfronthosting.co.za> Message-ID: <1448686881.78.0.313296477546.issue16151@psf.upfronthosting.co.za> Martin Panter added the comment: Discovered Issue 22923 is already open about ?Display all possibilities? problem. It sounds like that may be a regression in Readline, not Python. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 28 01:23:10 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 28 Nov 2015 06:23:10 +0000 Subject: [issue25754] Test test_rlcompleter failed if run twice In-Reply-To: <1448660610.8.0.576604023002.issue25754@psf.upfronthosting.co.za> Message-ID: <1448691790.65.0.0881912336646.issue25754@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 28 01:25:51 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 28 Nov 2015 06:25:51 +0000 Subject: [issue16151] Deferred KeyboardInterrupt in interactive mode In-Reply-To: <1349551962.43.0.949416732292.issue16151@psf.upfronthosting.co.za> Message-ID: <1448691951.58.0.31145494325.issue16151@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: +No prompt for "display all X possibilities" on completion-enabled input() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 28 03:13:15 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 28 Nov 2015 08:13:15 +0000 Subject: [issue25732] functools.total_ordering does not correctly implement not equal behaviour In-Reply-To: <1448457169.16.0.121144285875.issue25732@psf.upfronthosting.co.za> Message-ID: <1448698395.28.0.624240744648.issue25732@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The docs are correct but are apparently misleading ("rich comparison methods" means all six comparison methods while "rich comparison ordering methods" means only the four that provide order). That said, I think it would be perfectly reasonable to amend the code to supply __ne__ if it is missing. That would be reduce the likelihood of bugs arising when supplied only __eq__ and one of the four ordering methods but not __ne__. ---------- assignee: -> ncoghlan keywords: +patch Added file: http://bugs.python.org/file41180/total_ordering_ne.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 28 03:43:23 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 28 Nov 2015 08:43:23 +0000 Subject: [issue25732] functools.total_ordering does not correctly implement not equal behaviour In-Reply-To: <1448457169.16.0.121144285875.issue25732@psf.upfronthosting.co.za> Message-ID: <1448700203.57.0.806406861478.issue25732@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Now defined __ne__ always silently overridden. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 28 04:11:39 2015 From: report at bugs.python.org (Firat Ozgul) Date: Sat, 28 Nov 2015 09:11:39 +0000 Subject: [issue25741] Usual Installation Directory In-Reply-To: <1448616244.63.0.310461564489.issue25741@psf.upfronthosting.co.za> Message-ID: <1448701899.45.0.144301973754.issue25741@psf.upfronthosting.co.za> Firat Ozgul added the comment: Maybe that part of the tutorial should also include a link to https://docs.python.org/3/using/windows.html. This document contains all the details for using Python on Windows. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 28 04:18:23 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 28 Nov 2015 09:18:23 +0000 Subject: [issue25732] functools.total_ordering does not correctly implement not equal behaviour In-Reply-To: <1448457169.16.0.121144285875.issue25732@psf.upfronthosting.co.za> Message-ID: <1448702303.45.0.720356383048.issue25732@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: ncoghlan -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 28 04:20:27 2015 From: report at bugs.python.org (Torsten Landschoff) Date: Sat, 28 Nov 2015 09:20:27 +0000 Subject: [issue25757] Subclasses of property lose docstring In-Reply-To: <1448667832.51.0.334598445629.issue25757@psf.upfronthosting.co.za> Message-ID: <1448702427.89.0.482076151867.issue25757@psf.upfronthosting.co.za> Changes by Torsten Landschoff : Added file: http://bugs.python.org/file41181/subprop_doc_r2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 28 04:26:01 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 28 Nov 2015 09:26:01 +0000 Subject: [issue25732] functools.total_ordering does not correctly implement not equal behaviour In-Reply-To: <1448457169.16.0.121144285875.issue25732@psf.upfronthosting.co.za> Message-ID: <1448702761.98.0.0467600716063.issue25732@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: rhettinger -> ncoghlan Added file: http://bugs.python.org/file41182/total_ordering_ne2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 28 04:42:34 2015 From: report at bugs.python.org (Torsten Landschoff) Date: Sat, 28 Nov 2015 09:42:34 +0000 Subject: [issue25757] Subclasses of property lose docstring In-Reply-To: <1448667832.51.0.334598445629.issue25757@psf.upfronthosting.co.za> Message-ID: <1448703754.59.0.587173583071.issue25757@psf.upfronthosting.co.za> Torsten Landschoff added the comment: Prompted by Emanuel's comment I ran the test with repetitions. This does not actually test his assertion that I missed a decref since he referred to the error case when setting the __doc__ key of the instance dict fails. But I was curious none the less. I was shocked that this failed with ``` torsten at defiant:~/mirror/cpython$ make test TESTOPTS="-R 3:2 test_property" ... test test_property failed -- Traceback (most recent call last): File "/home/torsten/mirror/cpython/Lib/test/test_property.py", line 172, in test_property_decorator_doc_writable self.assertEqual(sub.__class__.spam.__doc__, 'Eggs') AssertionError: 'Spam' != 'Eggs' ``` But this was not introduced by my changes, rather it is an existing bug in the tests: test_property_decorator_doc_writable modifies a class created on module level so the second repetition sees the already updated class. fix_repetitions.diff contains a fix for this problem (by defining the class locally in the test method). While at it I introduced a refleak on purpose and this is correctly reported by the tests. Good to know how to test for this :-) ---------- Added file: http://bugs.python.org/file41183/fix_repetitions.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 28 04:56:53 2015 From: report at bugs.python.org (Dima Tisnek) Date: Sat, 28 Nov 2015 09:56:53 +0000 Subject: [issue25758] ensurepip/venv broken on Windows if path includes unicode Message-ID: <1448704613.06.0.448553989281.issue25758@psf.upfronthosting.co.za> New submission from Dima Tisnek: One of my students installed Python 3.5 on Windows 10 to default location where user name "?ukasz" contains unicode. Now "-m venv" and "-m ensurepip" do not work: C:\Users\?ukasz>C:\Users\?ukasz\AppData\Local\Programs\Python\Python35-32\python.exe -m venv workshops Error: Command '['C:\\Users\\\u0141ukasz\\workshops\\Scripts\\python.exe', '-Im', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 1 C:\Users\?ukasz>C:\Users\?ukasz\AppData\Local\Programs\Python\Python35-32\python.exe -m ensurepip Traceback (most recent call last): File "C:\Users\\u0141ukasz\AppData\Local\Programs\Python\Python35-32\lib\runpy.py", line 170, in _run_module_as_main "__main__", mod_spec) File "C:\Users\\u0141ukasz\AppData\Local\Programs\Python\Python35-32\lib\runpy.py", line 85, in _run_code exec(code, run_globals) File "C:\Users\\u0141ukasz\AppData\Local\Programs\Python\Python35-32\lib\ensurepip\__main__.py", line 4, in ensurepip._main() File "C:\Users\\u0141ukasz\AppData\Local\Programs\Python\Python35-32\lib\ensurepip\__init__.py", line 209, in _main default_pip=args.default_pip, File "C:\Users\\u0141ukasz\AppData\Local\Programs\Python\Python35-32\lib\ensurepip\__init__.py", line 116, in bootstrap _run_pip(args + [p[0] for p in _PROJECTS], additional_paths) File "C:\Users\\u0141ukasz\AppData\Local\Programs\Python\Python35-32\lib\ensurepip\__init__.py", line 40, in _run_pip import pip File "", line 969, in _find_and_load File "", line 954, in _find_and_load_unlocked File "", line 896, in _find_spec File "", line 1136, in find_spec File "", line 1112, in _get_spec File "", line 1093, in _legacy_get_spec File "", line 444, in spec_from_loader File "", line 530, in spec_from_file_location UnicodeEncodeError: 'mbcs' codec can't encode characters in position 0--1: invalid character ---------- components: Unicode messages: 255534 nosy: Dima.Tisnek, ezio.melotti, haypo priority: normal severity: normal status: open title: ensurepip/venv broken on Windows if path includes unicode versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 28 05:23:33 2015 From: report at bugs.python.org (Laura Creighton) Date: Sat, 28 Nov 2015 10:23:33 +0000 Subject: [issue25758] ensurepip/venv broken on Windows if path includes unicode In-Reply-To: <1448704613.06.0.448553989281.issue25758@psf.upfronthosting.co.za> Message-ID: <1448706213.08.0.163316034898.issue25758@psf.upfronthosting.co.za> Changes by Laura Creighton : ---------- nosy: +Marcus.Smith, dstufft, ncoghlan, paul.moore _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 28 05:38:45 2015 From: report at bugs.python.org (Eryk Sun) Date: Sat, 28 Nov 2015 10:38:45 +0000 Subject: [issue25741] Usual Installation Directory In-Reply-To: <1448616244.63.0.310461564489.issue25741@psf.upfronthosting.co.za> Message-ID: <1448707125.13.0.32352291339.issue25741@psf.upfronthosting.co.za> Eryk Sun added the comment: > LOCALAPPDATA is set by the operating system, typically to > C:\Users\\AppData\Local (at least since Vista I > think? Certainly since Win7 Vista introduced LOCALAPPDATA, so there's no problem referencing it in the docs for 3.5+. On a related note, section 3.4.4.1 [1] could be changed to use %LOCALAPPDATA% instead of referring to the shell function SHGetFolderPath and CSIDL_LOCAL_APPDATA. [1]: https://docs.python.org/3.5/using/windows.html#customization-via-ini-files ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 28 05:48:14 2015 From: report at bugs.python.org (Ronald Oussoren) Date: Sat, 28 Nov 2015 10:48:14 +0000 Subject: [issue9504] signal.signal/signal.alarm not working as expected In-Reply-To: <1280910836.88.0.645209486589.issue9504@psf.upfronthosting.co.za> Message-ID: <1448707694.2.0.802755484792.issue9504@psf.upfronthosting.co.za> Ronald Oussoren added the comment: Victor: read(2) and recv(2) are defined as returning all available data when interrupted by a signal and might therefore not return an error. The same is true for write(2): it returns the number of bytes written when there are any bytes written (instead of setting errno to SIGINT and returning an error). I'd expect the C implementation of readall to behave the same as the Python implementation: a signal handler that raises an exception can cause data loss due to discarding the buffer that's used to collect the data. The data loss in the script isn't worse than it currently is, AFAIK it would currently lose data due to raising the exception just after the call to readall in the next loop through the eval loop. If I read the issue correctly the signal handling issue mentioned here is basically similar to the one in this scriptlet: # BEGIN import signal, sys import subprocess def handler(sig, frames): raise RuntimeError("Alarm!") signal.signal(signal.SIGALRM, handler) signal.alarm(5) b = sys.stdin.buffer.raw.readall() print(len(b)) signal.alarm(0) #END When you run this with a large file on stdin (I've used /dev/zero) the script will continue to run indefinitely and cannot be cleanly interrupted at all (on my system its eventually killed by the system due to running out of its rlimit limitations, otherwise it can only be killed by sending it an uncatchable signal like SIGKILL or SIGABRT). ---------- nosy: +ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 28 06:15:36 2015 From: report at bugs.python.org (SilentGhost) Date: Sat, 28 Nov 2015 11:15:36 +0000 Subject: [issue25758] ensurepip/venv broken on Windows if path includes unicode In-Reply-To: <1448704613.06.0.448553989281.issue25758@psf.upfronthosting.co.za> Message-ID: <1448709336.28.0.817036268918.issue25758@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- components: +Windows nosy: +brett.cannon, eric.snow, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 28 06:19:51 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 28 Nov 2015 11:19:51 +0000 Subject: [issue25732] functools.total_ordering does not correctly implement not equal behaviour In-Reply-To: <1448457169.16.0.121144285875.issue25732@psf.upfronthosting.co.za> Message-ID: <1448709591.17.0.309006060046.issue25732@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This doesn't work with new-style classes that always have __ne__ inherited from object. I afraid that the only way to fix this issue is to backport Python 3 behavior of default __ne__, automatically fallback to __eq__. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 28 07:20:34 2015 From: report at bugs.python.org (Emanuel Barry) Date: Sat, 28 Nov 2015 12:20:34 +0000 Subject: [issue25757] Subclasses of property lose docstring In-Reply-To: <1448667832.51.0.334598445629.issue25757@psf.upfronthosting.co.za> Message-ID: <1448713234.28.0.363106370426.issue25757@psf.upfronthosting.co.za> Emanuel Barry added the comment: Looking at it again, it appears you didn't have to decref it; my bad. Both patches LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 28 07:30:40 2015 From: report at bugs.python.org (Bernd Dietzel) Date: Sat, 28 Nov 2015 12:30:40 +0000 Subject: [issue25751] ctypes.util , Shell Injection in find_library() In-Reply-To: <1448655560.8.0.523539379986.issue25751@psf.upfronthosting.co.za> Message-ID: <1448713840.48.0.100382089518.issue25751@psf.upfronthosting.co.za> Bernd Dietzel added the comment: i made the ubuntu link readable for everyone. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 28 08:48:09 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 28 Nov 2015 13:48:09 +0000 Subject: [issue6395] Infinite Recursion during Unpickling a codecs Object In-Reply-To: <1246463188.35.0.320675118154.issue6395@psf.upfronthosting.co.za> Message-ID: <1448718489.78.0.833683626237.issue6395@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Implementing only .__get/setstate__() doesn't fix all problem. We have implement also __getnewargs_ex__(). But implemented __getnewargs_ex__() has priority over __getnewargs__() implemented in subclasses. And may be there are problems with other optional special methods that are incorrectly delegated to the stream in codecs IO classes. I think more reliable way is to disallow delegating all special (or may be even private) methods. Here is a patch. ---------- assignee: -> serhiy.storchaka nosy: +serhiy.storchaka stage: -> patch review type: enhancement -> behavior versions: +Python 3.5, Python 3.6 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 28 08:48:27 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 28 Nov 2015 13:48:27 +0000 Subject: [issue6395] Infinite Recursion during Unpickling a codecs Object In-Reply-To: <1246463188.35.0.320675118154.issue6395@psf.upfronthosting.co.za> Message-ID: <1448718507.04.0.846419026657.issue6395@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +patch Added file: http://bugs.python.org/file41184/codecs_stream_delegating.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 28 09:11:50 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 28 Nov 2015 14:11:50 +0000 Subject: [issue18068] pickle + weakref.proxy(self) In-Reply-To: <1369594749.9.0.0448045246945.issue18068@psf.upfronthosting.co.za> Message-ID: <1448719910.65.0.878452508786.issue18068@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The weakref.proxy object delegates all attribute access to referred object, including special attributes used in pickling, like __class__ or __getstate__. test.recursive is not test, but it looks as TestPickle instance for the pickler. It is pickled and unpickled as TestPickle instance. >>> test.recursive.__class__ >>> test.recursive.__getstate__ > >>> test.recursive.__reduce_ex__(2) __getstate__ 3071478700 (, (,), {'recursive': }, None, None) >>> pickle.loads(pickle.dumps(test.recursive, 2)) __getstate__ 3071478700 __setstate__ 3071525356 <__main__.TestPickle object at 0xb713c1ec> Since test.recursive.recursive is test.recursive, this recursion is detected by pickler. This issue is similar to issue6395, but since weakref.proxy is not subclassable, we can just implement correct __reduce__. ---------- assignee: -> serhiy.storchaka nosy: +serhiy.storchaka stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 28 09:29:08 2015 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 28 Nov 2015 14:29:08 +0000 Subject: [issue25735] math.factorial doc should mention integer return type In-Reply-To: <1448480671.49.0.139605050425.issue25735@psf.upfronthosting.co.za> Message-ID: <1448720948.63.0.705145103221.issue25735@psf.upfronthosting.co.za> Mark Dickinson added the comment: [Terry] >>> factorial(decimal.Decimal(5.2)) 120 Yep, that's definitely wrong. If we want to behave the same way as for float, we should accept only integral Decimal values. (Though I'm not much of a fan of the float behaviour: I would have preferred math.factorial not to accept floats at all.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 28 10:32:07 2015 From: report at bugs.python.org (Ethan Furman) Date: Sat, 28 Nov 2015 15:32:07 +0000 Subject: [issue25634] Add a dedicated subclass for attribute missing errors In-Reply-To: <1447666799.36.0.119700754928.issue25634@psf.upfronthosting.co.za> Message-ID: <1448724727.66.0.58717863047.issue25634@psf.upfronthosting.co.za> Ethan Furman added the comment: Note for posterity: the current behavior of __getattr__ is what allows Enum to work correctly. ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 28 10:43:25 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 28 Nov 2015 15:43:25 +0000 Subject: [issue20836] Pickle Nonetype In-Reply-To: <1393800619.38.0.666577692495.issue20836@psf.upfronthosting.co.za> Message-ID: <1448725405.63.0.880242932568.issue20836@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 28 10:51:37 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 28 Nov 2015 15:51:37 +0000 Subject: [issue25732] functools.total_ordering does not correctly implement not equal behaviour In-Reply-To: <1448457169.16.0.121144285875.issue25732@psf.upfronthosting.co.za> Message-ID: <1448725897.81.0.785044597415.issue25732@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: ncoghlan -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 28 10:56:25 2015 From: report at bugs.python.org (Eryk Sun) Date: Sat, 28 Nov 2015 15:56:25 +0000 Subject: [issue25758] ensurepip/venv broken on Windows if path includes unicode In-Reply-To: <1448704613.06.0.448553989281.issue25758@psf.upfronthosting.co.za> Message-ID: <1448726185.96.0.395207806636.issue25758@psf.upfronthosting.co.za> Eryk Sun added the comment: The problem is that the compile_source function in Modules/zipimport.c calls PyUnicode_EncodeFSDefault to get an encoded string to pass as the filename argument of Py_CompileString. On Windows this uses the ANSI codepage (i.e. 'mbcs'). Apparently your system's ANSI codepage doesn't map the "?" character. I reproduced the problem more simply by copying pip-7.1.2-py2.py3-none-any.whl to a subdirectory named "?ukasz"; adding the wheel path to sys.path; and attempting to execute "import pip". One solution is to replace Py_CompileString with Py_CompileStringObject. This way compile_source doesn't have to worry about encoding its pathname argument. A minimal patch is attached, but it needs a test. ---------- keywords: +patch nosy: +eryksun versions: +Python 3.6 Added file: http://bugs.python.org/file41185/issue25758_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 28 11:04:53 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 28 Nov 2015 16:04:53 +0000 Subject: [issue25732] functools.total_ordering does not correctly implement not equal behaviour In-Reply-To: <1448457169.16.0.121144285875.issue25732@psf.upfronthosting.co.za> Message-ID: <1448726693.57.0.65091959847.issue25732@psf.upfronthosting.co.za> Raymond Hettinger added the comment: In Python 2.7, __ne__ isn't inherited from object. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 28 11:25:57 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 28 Nov 2015 16:25:57 +0000 Subject: [issue25732] functools.total_ordering does not correctly implement not equal behaviour In-Reply-To: <1448457169.16.0.121144285875.issue25732@psf.upfronthosting.co.za> Message-ID: <1448727957.8.0.0723972594403.issue25732@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Oh, sorry. Then the patch LGTM. ---------- stage: needs patch -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 28 12:25:14 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 28 Nov 2015 17:25:14 +0000 Subject: [issue25485] Add a context manager to telnetlib.Telnet In-Reply-To: <1445883619.21.0.032521861016.issue25485@psf.upfronthosting.co.za> Message-ID: <20151128172510.29830.37410@psf.io> Roundup Robot added the comment: New changeset 277824f2d133 by R David Murray in branch 'default': #25485: Add context manager support to Telnet class. https://hg.python.org/cpython/rev/277824f2d133 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 28 12:27:24 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 28 Nov 2015 17:27:24 +0000 Subject: [issue25485] Add a context manager to telnetlib.Telnet In-Reply-To: <1445883619.21.0.032521861016.issue25485@psf.upfronthosting.co.za> Message-ID: <1448731644.68.0.0854001351546.issue25485@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, St?phane. I adjusted the docs...we don't seem to be very consistent about how we document addition of content manager support, so I picked what I liked best. Also, FYI it is generally best (at this point in time) to not include the NEWS item, but enhancements should inlcude a what's new entry (I added one). ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 28 14:09:49 2015 From: report at bugs.python.org (Jeroen Demeyer) Date: Sat, 28 Nov 2015 19:09:49 +0000 Subject: [issue25750] tp_descr_get(self, obj, type) is called without owning a reference to "self" In-Reply-To: <1448654213.28.0.807225788685.issue25750@psf.upfronthosting.co.za> Message-ID: <1448737789.53.0.513192239838.issue25750@psf.upfronthosting.co.za> Changes by Jeroen Demeyer : ---------- type: -> crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 28 15:06:01 2015 From: report at bugs.python.org (=?utf-8?q?Adam_Barto=C5=A1?=) Date: Sat, 28 Nov 2015 20:06:01 +0000 Subject: [issue17620] Python interactive console doesn't use sys.stdin for input In-Reply-To: <1364921954.86.0.527255608282.issue17620@psf.upfronthosting.co.za> Message-ID: <1448741161.31.0.084641456459.issue17620@psf.upfronthosting.co.za> Adam Barto? added the comment: I've formulated a proposal regarding this issue: https://mail.python.org/pipermail/python-dev/2015-November/142246.html . Does it make sense? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 28 15:10:41 2015 From: report at bugs.python.org (Kovid Goyal) Date: Sat, 28 Nov 2015 20:10:41 +0000 Subject: [issue25759] Python 2.7.11rc1 not building with Visual Studio 2015 Message-ID: <1448741441.78.0.371130073658.issue25759@psf.upfronthosting.co.za> New submission from Kovid Goyal: The Pcbuild/readme.txt file implies that it is possible to build python 2.7.11rc1 with Visual Studio 2015 (although it is not officially supported). However, there are at least a couple of problems, that I have encountered so far: 1) timemodule.c uses timezone, tzname and daylight which are no longer defined in visual studio, as a quick hackish workaround, one can do #if defined _MSC_VER && MSC_VER >= 1900 #define timezone _timezone #define tzname _tzname #define daylight _daylight #endif 2) More serious, the code in posixmodule.c to check if file descriptors are valid no longer links, since it relies on an internal structure from microsoft ddls, __pioinfo that no longer exists. See https://bugs.python.org/issue23524 for discussion about this in the python 3.x branch As a quick and dirty fix one could just replace _PyVerify_fd with a stub implementation that does nothing for _MSC_VER >= 1900 However, a proper fix should probably be made. ---------- components: Interpreter Core messages: 255550 nosy: kovidgoyal priority: normal severity: normal status: open title: Python 2.7.11rc1 not building with Visual Studio 2015 type: compile error versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 28 15:16:47 2015 From: report at bugs.python.org (SilentGhost) Date: Sat, 28 Nov 2015 20:16:47 +0000 Subject: [issue25759] Python 2.7.11rc1 not building with Visual Studio 2015 In-Reply-To: <1448741441.78.0.371130073658.issue25759@psf.upfronthosting.co.za> Message-ID: <1448741807.56.0.199040881116.issue25759@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- components: +Build, Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 28 16:17:34 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 28 Nov 2015 21:17:34 +0000 Subject: [issue25759] Python 2.7.11rc1 not building with Visual Studio 2015 In-Reply-To: <1448741441.78.0.371130073658.issue25759@psf.upfronthosting.co.za> Message-ID: <1448745454.23.0.40796397308.issue25759@psf.upfronthosting.co.za> Steve Dower added the comment: The proper fix is to remove any hint in the readme file that this will work. Building 2.7 with VS 2015 will not work unless someone forks CPython and makes the updates themselves. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 28 17:01:06 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 28 Nov 2015 22:01:06 +0000 Subject: [issue22636] avoid using a shell in ctypes.util: replace os.popen with subprocess In-Reply-To: <1413325975.89.0.175884398711.issue22636@psf.upfronthosting.co.za> Message-ID: <1448748066.24.0.684452635649.issue22636@psf.upfronthosting.co.za> Martin Panter added the comment: I think it is better to return None without an exception, to keep the current behaviour, and because that?s what the documentation implies. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 28 17:23:47 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 28 Nov 2015 22:23:47 +0000 Subject: [issue25717] tempfile.TemporaryFile fails when dir option set to directory residing on host OS mount In-Reply-To: <1448339024.55.0.65158482353.issue25717@psf.upfronthosting.co.za> Message-ID: <1448749427.4.0.89959603979.issue25717@psf.upfronthosting.co.za> Martin Panter added the comment: Antoine or Bohuslav, since you were involved in Issue 21679, would you be able to comment on fstat-failure.patch, which reverts back to ignoring most fstat() errors? The problem here is that fstat() seems to fail if the directory entry has been unlinked, and the file is on a Virtual Box shared folder filesystem. ---------- nosy: +bkabrda, pitrou stage: -> patch review versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 28 17:31:54 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 28 Nov 2015 22:31:54 +0000 Subject: [issue25732] functools.total_ordering does not correctly implement not equal behaviour In-Reply-To: <1448457169.16.0.121144285875.issue25732@psf.upfronthosting.co.za> Message-ID: <1448749914.6.0.751576079009.issue25732@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Nick, I'm inclined to put this in. Only bugs can come out of the current arrangement. Do you have any further thoughts? ---------- assignee: -> ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 28 17:32:26 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 28 Nov 2015 22:32:26 +0000 Subject: [issue25732] functools.total_ordering does not correctly implement not equal behaviour In-Reply-To: <1448457169.16.0.121144285875.issue25732@psf.upfronthosting.co.za> Message-ID: <1448749946.41.0.150065845798.issue25732@psf.upfronthosting.co.za> Changes by Raymond Hettinger : Added file: http://bugs.python.org/file41186/total_ordering_ne3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 28 17:57:06 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 28 Nov 2015 22:57:06 +0000 Subject: [issue25754] Test test_rlcompleter failed if run twice In-Reply-To: <1448660610.8.0.576604023002.issue25754@psf.upfronthosting.co.za> Message-ID: <20151128225703.69562.76654@psf.io> Roundup Robot added the comment: New changeset 2e889344436e by Martin Panter in branch 'default': Issue #25754: Allow test_rlcompleter to be run multiple times https://hg.python.org/cpython/rev/2e889344436e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 28 18:06:46 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 28 Nov 2015 23:06:46 +0000 Subject: [issue23150] urllib parse incorrect handing of params In-Reply-To: <1420208027.4.0.951710161178.issue23150@psf.upfronthosting.co.za> Message-ID: <1448752006.42.0.0492370840041.issue23150@psf.upfronthosting.co.za> Martin Panter added the comment: Marking as Python 3 since you mentioned urllib.parse, rather than just urllib. However you need to be more specific. We already have a urllib.parse.urlsplit() function which seems to do what you want: >>> urllib.parse.urlsplit("http://example.com/;").path '/;' I see that the ?params? bit can be dropped by urljoin(). My proposal in Issue 22852 could probably be adapted to help with that. ---------- nosy: +martin.panter stage: -> test needed versions: +Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 28 18:08:09 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 28 Nov 2015 23:08:09 +0000 Subject: [issue25754] Test test_rlcompleter failed if run twice In-Reply-To: <1448660610.8.0.576604023002.issue25754@psf.upfronthosting.co.za> Message-ID: <1448752089.46.0.158226924448.issue25754@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 28 20:24:17 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 29 Nov 2015 01:24:17 +0000 Subject: [issue24363] httplib fails to handle semivalid HTTP headers In-Reply-To: <1433257563.79.0.772954216205.issue24363@psf.upfronthosting.co.za> Message-ID: <1448760257.84.0.0114345750107.issue24363@psf.upfronthosting.co.za> Martin Panter added the comment: Since the Python 2 and Python 3 branches are different, two different patches would be needed here. Perhaps they could share common test cases though. Michael: I presume your proposal is for Python 2. I don?t understand the re.findall() expression; is there a clearer way to do whatever it is trying to do (or failing that, explain it in a comment)? It looks like you are trying to skip over spaces at the start of the first header field name. Also, it seems to drop support for lines folded with tabs rather than spaces. David: The headers-only mode wouldn?t make much difference because it only affects parsing the ?payload?. As far as the email package is concerned, the payload should always be empty when used by HTTP?s parse_headers(). The simplest fix (at least for the Python 3 code) would be to check each line against email.feedparser.headerRE before adding it to the list of lines in the HTTP package. This would prevent the email parser from bailing from the header section early, which is the main problem. But that does seem like a bad hack and wouldn?t treat the offending line as a folded line, which Cory and David want. So I guess we need to make the email parser more flexible instead. Maybe a private FeedParser._parse_header_lines() method or something, that replaces feed() and close(), and defers most of the processing directly to _parse_headers(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 28 21:07:24 2015 From: report at bugs.python.org (Samwyse) Date: Sun, 29 Nov 2015 02:07:24 +0000 Subject: [issue25760] TextWrapper fails to split 'two-and-a-half-hour' correctly Message-ID: <1448762844.39.0.812229060367.issue25760@psf.upfronthosting.co.za> New submission from Samwyse: Single character words in a hyphenated phrase are not split correctly. The root issue it the wordsep_re class variable. To reproduce, run the following: >>> import textwrap >>> textwrap.TextWrapper.wordsep_re.split('two-and-a-half-hour') ['', 'two-', 'and-a', '-half-', 'hour'] It works if 'a' is replaces with two or more alphabetic characters. >>> textwrap.TextWrapper.wordsep_re.split('two-and-aa-half-hour') ['', 'two-', '', 'and-', '', 'aa-', '', 'half-', 'hour'] The problem is in this part of the pattern: (?=\w+[^0-9\W]) I confess that I don't understand the situation that would require that complicated of a pattern. Why wouldn't (?=\w) would work? ---------- components: Library (Lib) messages: 255558 nosy: samwyse priority: normal severity: normal status: open title: TextWrapper fails to split 'two-and-a-half-hour' correctly type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 28 21:29:56 2015 From: report at bugs.python.org (Kovid Goyal) Date: Sun, 29 Nov 2015 02:29:56 +0000 Subject: [issue25759] Python 2.7.11rc1 not building with Visual Studio 2015 In-Reply-To: <1448741441.78.0.371130073658.issue25759@psf.upfronthosting.co.za> Message-ID: <1448764196.97.0.997453081312.issue25759@psf.upfronthosting.co.za> Kovid Goyal added the comment: OK, I had hoped to avoid having to maintain my own fork of python 2 for a while longer, but, I guess not. Could you at least tell me if there are any other issues I should be aware of, to avoid me having to search through the python 3 sourcecode/commit history. I will be happy to make my work public so others can benefit from it as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 29 00:44:43 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 29 Nov 2015 05:44:43 +0000 Subject: [issue5784] raw deflate format and zlib module In-Reply-To: <1240006221.86.0.263428051867.issue5784@psf.upfronthosting.co.za> Message-ID: <1448775883.79.0.700485990418.issue5784@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a patch with the following changes: * Clarified that wbits affects the container format as well as windows size * Undid some word wrapping to make the diff simpler * Added zero and 32 + n for decompression * Added full list of options under decompressobj(), and link decompress() to that. Otherwise we end up saying decompression generates a header, when it really parses the header. * Added tests for various wbits values * Compressing with window bits = 8 not actually supported (Zlib bumps it to 9: . The change log says ?Force windowBits > 8 to avoid a bug in the encoder for a window size of 256 bytes?.) * Updated doc strings ---------- keywords: +patch versions: +Python 3.5, Python 3.6 -Python 3.2, Python 3.3 Added file: http://bugs.python.org/file41187/zlib-wbits.v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 29 01:20:55 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 29 Nov 2015 06:20:55 +0000 Subject: [issue25760] TextWrapper fails to split 'two-and-a-half-hour' correctly In-Reply-To: <1448762844.39.0.812229060367.issue25760@psf.upfronthosting.co.za> Message-ID: <1448778055.87.0.16336289739.issue25760@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Already fixed in issue22687. ---------- nosy: +serhiy.storchaka resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 29 01:25:42 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 29 Nov 2015 06:25:42 +0000 Subject: [issue25759] Python 2.7.11rc1 not building with Visual Studio 2015 In-Reply-To: <1448741441.78.0.371130073658.issue25759@psf.upfronthosting.co.za> Message-ID: <1448778342.11.0.990022503371.issue25759@psf.upfronthosting.co.za> Steve Dower added the comment: Not off the top of my head, but you only really need to look at my commits, and looking for issues assigned to me is an easy way to find those. Most of the issues are obvious once you start trying to build. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 29 01:49:52 2015 From: report at bugs.python.org (Kovid Goyal) Date: Sun, 29 Nov 2015 06:49:52 +0000 Subject: [issue25759] Python 2.7.11rc1 not building with Visual Studio 2015 In-Reply-To: <1448741441.78.0.371130073658.issue25759@psf.upfronthosting.co.za> Message-ID: <1448779792.26.0.43379916745.issue25759@psf.upfronthosting.co.za> Kovid Goyal added the comment: I have it building with just two simple patches: https://github.com/kovidgoyal/cpython/commit/fd1ceca4f21135f12ceb72f37d4ac5ea1576594d https://github.com/kovidgoyal/cpython/commit/edb740218c04b38aa0f385188103100a972d608c However, in developing the patches, I discovered what looks like a bug in the CRT close() function. If you double close a valid file descriptor it crashes, rather than calling the invalid parameter handler. python -c "import os; os.close(2); os.close(2)" crashes. This is true for python 2.7.10 built against VS 2008 as well. This contrasts with the behavior of double close() on other operating systems, where it sets errno to EBADF and does not crash. I have not tested it with python 3.5, but I assume the bug is present there as well. ---------- components: -Build, Windows _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 29 02:11:05 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 29 Nov 2015 07:11:05 +0000 Subject: =?utf-8?q?=5Bissue23200=5D_Deprecate_the_zlib_decompressor=E2=80=99s_flus?= =?utf-8?q?h=28=29_method?= In-Reply-To: <1420766781.53.0.179588350228.issue23200@psf.upfronthosting.co.za> Message-ID: <1448781065.95.0.486155768482.issue23200@psf.upfronthosting.co.za> Martin Panter added the comment: And regarding other internal buffers and state, calling flush() or decompress() guarantees you get as much data as possible, but there is no error checking. You have to check the eof attribute to ensure everything is done, otherwise I don?t think there is a way to differentiate a truncated stream from a properly ended stream. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 29 03:23:22 2015 From: report at bugs.python.org (Armin Rigo) Date: Sun, 29 Nov 2015 08:23:22 +0000 Subject: [issue25750] tp_descr_get(self, obj, type) is called without owning a reference to "self" In-Reply-To: <1448654213.28.0.807225788685.issue25750@psf.upfronthosting.co.za> Message-ID: <1448785402.96.0.67359235855.issue25750@psf.upfronthosting.co.za> Armin Rigo added the comment: This is a known general issue which is documented in Lib/test/crashers/borrowed_ref_1 inside the 2.7 branch. In trunk, I see that this file has been deleted, although the issue has not been solved in general. Only the particular crash in the file has been solved. (Somebody with motivation should restore the crashers that have been solved superficially only. But finding actual crashing code takes more effort than I'm willing to put into this rather pointless process, so CPython still gets the occasional bug report like this one instead.) ---------- nosy: +arigo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 29 03:56:41 2015 From: report at bugs.python.org (Jeroen Demeyer) Date: Sun, 29 Nov 2015 08:56:41 +0000 Subject: [issue25750] tp_descr_get(self, obj, type) is called without owning a reference to "self" In-Reply-To: <1448654213.28.0.807225788685.issue25750@psf.upfronthosting.co.za> Message-ID: <1448787401.43.0.319093213029.issue25750@psf.upfronthosting.co.za> Jeroen Demeyer added the comment: Thanks for the pointer. My patch does fix the crash in Lib/test/crashers/borrowed_ref_2.py on Python 2.7.10. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 29 05:59:25 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 29 Nov 2015 10:59:25 +0000 Subject: [issue25761] Improve unpickling errors handling Message-ID: <1448794765.73.0.847000762162.issue25761@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: This issue is for better detecting and reporting errors in broken pickle data. ---------- assignee: serhiy.storchaka components: Extension Modules, Library (Lib), Tests messages: 255567 nosy: serhiy.storchaka priority: normal severity: normal status: open title: Improve unpickling errors handling type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 29 06:09:36 2015 From: report at bugs.python.org (SilentGhost) Date: Sun, 29 Nov 2015 11:09:36 +0000 Subject: [issue25627] distutils : file "bdist_rpm.py" does not quote filenames when executing the rpm command In-Reply-To: <1447535612.69.0.122030151224.issue25627@psf.upfronthosting.co.za> Message-ID: <1448795376.76.0.431261996438.issue25627@psf.upfronthosting.co.za> SilentGhost added the comment: I tried re-writing that bit using subprocess.Popen but since the 2.7 support is needed I genuinely don't see any benefit that would add on top of the submitted patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 29 06:14:44 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 29 Nov 2015 11:14:44 +0000 Subject: [issue25761] Improve unpickling errors handling In-Reply-To: <1448794765.73.0.847000762162.issue25761@psf.upfronthosting.co.za> Message-ID: <20151129111441.69570.36783@psf.io> Roundup Robot added the comment: New changeset d47e5b162072 by Serhiy Storchaka in branch '3.4': Issue #25761: Added more test cases for testing unpickling broken data. https://hg.python.org/cpython/rev/d47e5b162072 New changeset c7e7d77ef8bf by Serhiy Storchaka in branch '2.7': Issue #25761: Added more test cases for testing unpickling broken data. https://hg.python.org/cpython/rev/c7e7d77ef8bf New changeset 4897438543da by Serhiy Storchaka in branch '3.5': Issue #25761: Added more test cases for testing unpickling broken data. https://hg.python.org/cpython/rev/4897438543da New changeset c852c7d8d681 by Serhiy Storchaka in branch 'default': Issue #25761: Added more test cases for testing unpickling broken data. https://hg.python.org/cpython/rev/c852c7d8d681 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 29 06:39:52 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 29 Nov 2015 11:39:52 +0000 Subject: [issue25627] distutils : file "bdist_rpm.py" does not quote filenames when executing the rpm command In-Reply-To: <1447535612.69.0.122030151224.issue25627@psf.upfronthosting.co.za> Message-ID: <1448797192.82.0.464145054408.issue25627@psf.upfronthosting.co.za> Martin Panter added the comment: I don?t understand what 2.7 has got to do with using subprocess or not. Jumping through a shell quoting hoop only to pass a command to the shell to be unquoted seems like double handling. This is how I might rewrite it (untested): q_cmd = ("rpm", "-q", "--qf", r"%s %s\n" % (...), "--specfile", spec_path) with subprocess.Popen(q_cmd, stdout=PIPE, universal_newlines=?) as proc: for line in proc.stdout: ... if proc.returncode: raise DistutilsExecError(...) ---------- nosy: +martin.panter stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 29 07:19:34 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 29 Nov 2015 12:19:34 +0000 Subject: [issue25761] Improve unpickling errors handling In-Reply-To: <1448794765.73.0.847000762162.issue25761@psf.upfronthosting.co.za> Message-ID: <1448799574.89.0.942841289288.issue25761@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Proposed patch allows unpickler to detect errors related to reading a stack behind a mark. For now Python implementation just pops a sentinel used as a mark. This can cause TypeError, AttributeError or UnpicklingError besides IndexError: >>> pickle._loads(b'}(NNs.') Traceback (most recent call last): ... TypeError: 'object' object does not support item assignment >>> pickle._loads(b'](Na.') Traceback (most recent call last): ... AttributeError: 'object' object has no attribute 'append' Or can silently expose the mark object: >>> pickle._loads(b')(.') >>> pickle._loads(b']](a.') [] C implementation just ignores incorrect mark: >>> pickle.loads(b'}(NNs.') {None: None} >>> pickle.loads(b'](Na.') [None] >>> pickle.loads(b')(.') () >>> pickle.loads(b']](a.') [[]] But in case of complex data this can cause errors later. With the patch C implementation always raises UnpicklingError with relevant message and Python implementation always raises IndexError. >>> pickle.loads(b'}(NNs.') Traceback (most recent call last): File "", line 1, in NameError: name 'pickle' is not defined >>> import pickle, pickletools >>> pickle.loads(b'}(NNs.') Traceback (most recent call last): File "", line 1, in _pickle.UnpicklingError: unexpected MARK found >>> pickle.loads(b'](Na.') Traceback (most recent call last): File "", line 1, in _pickle.UnpicklingError: unexpected MARK found >>> pickle.loads(b')(.') Traceback (most recent call last): File "", line 1, in _pickle.UnpicklingError: unexpected MARK found >>> pickle.loads(b']](a.') Traceback (most recent call last): File "", line 1, in _pickle.UnpicklingError: unexpected MARK found >>> pickle._loads(b'}(NNs.') Traceback (most recent call last): ... IndexError: list index out of range >>> pickle._loads(b'](Na.') Traceback (most recent call last): ... IndexError: list index out of range >>> pickle._loads(b')(.') Traceback (most recent call last): ... IndexError: pop from empty list >>> pickle._loads(b']](a.') Traceback (most recent call last): ... IndexError: pop from empty list ---------- keywords: +patch stage: -> patch review versions: +Python 3.6 Added file: http://bugs.python.org/file41188/unpickling_mark_errors.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 29 07:43:38 2015 From: report at bugs.python.org (SilentGhost) Date: Sun, 29 Nov 2015 12:43:38 +0000 Subject: [issue25627] distutils : file "bdist_rpm.py" does not quote filenames when executing the rpm command In-Reply-To: <1447535612.69.0.122030151224.issue25627@psf.upfronthosting.co.za> Message-ID: <1448801018.85.0.184783476074.issue25627@psf.upfronthosting.co.za> SilentGhost added the comment: Yeah, it would be great, Martin, if only that code worked in python2. Anyway, here is an alternative patch. ---------- Added file: http://bugs.python.org/file41189/issue25627_3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 29 08:26:31 2015 From: report at bugs.python.org (Kovid Goyal) Date: Sun, 29 Nov 2015 13:26:31 +0000 Subject: [issue25759] Python 2.7.11rc1 not building with Visual Studio 2015 In-Reply-To: <1448741441.78.0.371130073658.issue25759@psf.upfronthosting.co.za> Message-ID: <1448803591.65.0.187948795392.issue25759@psf.upfronthosting.co.za> Kovid Goyal added the comment: I missed a few places in my initial patch, updated patch: https://github.com/kovidgoyal/cpython/commit/a9ec814d466d3c0139d10b69666f88eed10e4940 Also fixed the code not clearing errno before calling CRT functions, while I was there. Regardless of whether you want to allow your fork to be compiled with VS 2015 or not, I suggest you consider merging this patch, anyway, since the errno clearing is the correct thing to do, regardless. You can always cherrypick the errno clearing bits if you like :) Just FYI, the code in my fork of 2.7 passes all tests on 64bit builds with VS 2015, except for 5 small ones that I have yet to track down. (test_ctypes test_distutils test_gzip test_mailbox test_zipfile) I dont anticipate any difficulty in fixing the remaining test failures. Famous last words ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 29 09:17:42 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 29 Nov 2015 14:17:42 +0000 Subject: [issue25742] locale.setlocale does not work with unicode strings In-Reply-To: <1448636049.37.0.145831829956.issue25742@psf.upfronthosting.co.za> Message-ID: <1448806662.28.0.465205843481.issue25742@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: http://buildbot.python.org/all/builders/x86%20XP-4%202.7/builds/3517/steps/test/logs/stdio ====================================================================== ERROR: test_setlocale_unicode (test.test_locale.TestMiscellaneous) ---------------------------------------------------------------------- Traceback (most recent call last): File "d:\cygwin\home\db3l\buildarea\2.7.bolen-windows\build\lib\test\test_locale.py", line 497, in test_setlocale_unicode old_loc = locale.getlocale(locale.LC_ALL) File "d:\cygwin\home\db3l\buildarea\2.7.bolen-windows\build\lib\locale.py", line 565, in getlocale raise TypeError, 'category LC_ALL is not supported' TypeError: category LC_ALL is not supported ---------------------------------------------------------------------- ---------- nosy: +serhiy.storchaka status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 29 09:37:06 2015 From: report at bugs.python.org (STINNER Victor) Date: Sun, 29 Nov 2015 14:37:06 +0000 Subject: [issue25696] "make -j9 install" fails because bininstall target requires the libainstall target In-Reply-To: <1448202702.88.0.964294450431.issue25696@psf.upfronthosting.co.za> Message-ID: <1448807826.19.0.0173547219561.issue25696@psf.upfronthosting.co.za> STINNER Victor added the comment: bininstall-4.patch: IMHO it's overkill and makes Makefile more complex to follow. My patch bininstall.patch proposed something similar, but Arfrever asked me to modify bininstall target. IMHO Getting "Creating directory xxx" message twice is a minor issue. It becomes annoying to have nitpicking on my patch, I hate autotools, I hate having to care of Makefile, etc. Maybe I should just abandon my change, it looks like nobody cares that Python cannot be installed with -j9 anyway :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 29 10:33:27 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 29 Nov 2015 15:33:27 +0000 Subject: [issue25742] locale.setlocale does not work with unicode strings In-Reply-To: <1448636049.37.0.145831829956.issue25742@psf.upfronthosting.co.za> Message-ID: <20151129153324.13419.9496@psf.io> Roundup Robot added the comment: New changeset d7481ebeaa4f by Victor Stinner in branch '2.7': Issue #25742: Try to fix test_locale on Windows https://hg.python.org/cpython/rev/d7481ebeaa4f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 29 10:37:29 2015 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Sun, 29 Nov 2015 15:37:29 +0000 Subject: [issue25752] asyncio.readline - add customizable line separator In-Reply-To: <1448659598.46.0.288346349625.issue25752@psf.upfronthosting.co.za> Message-ID: <1448811449.2.0.705786999044.issue25752@psf.upfronthosting.co.za> ???? ????????? added the comment: When I reported that bug, I want to suggest multibyte separators, but implementation is much complex than current one. For example, we should decide what to do if partial separator is read and EOF occur. So, I think we should merge ability to use custom one-byte separator, and next create another pull-request to make support of multibyte separator (like '\r\n'). Okay, I can make pull request on asyncio, but asyncio now is the part of Python. Does not it ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 29 10:47:08 2015 From: report at bugs.python.org (Laura Creighton) Date: Sun, 29 Nov 2015 15:47:08 +0000 Subject: [issue25514] better startup error messages in IDLE when stdlib modules shadowed In-Reply-To: <1446151640.74.0.583734209916.issue25514@psf.upfronthosting.co.za> Message-ID: <1448812028.05.0.890235230478.issue25514@psf.upfronthosting.co.za> Laura Creighton added the comment: webmaster got another one of these today. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 29 11:40:53 2015 From: report at bugs.python.org (Yunus Emre Kursav) Date: Sun, 29 Nov 2015 16:40:53 +0000 Subject: [issue25762] Calculation Mistake 1.5 * 0.3 Message-ID: <1448815253.26.0.478369331046.issue25762@psf.upfronthosting.co.za> New submission from Yunus Emre Kursav: Dear Authorized Person, When I was using python, I found a bug. When I multiplied 1.5 time 0.3, I got 0.44999999999999996 as a result. Best Regards, Yunus ---------- files: Screenshot from 2015-11-29 17-39-20.png messages: 255579 nosy: zeneregion priority: normal severity: normal status: open title: Calculation Mistake 1.5 * 0.3 type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file41190/Screenshot from 2015-11-29 17-39-20.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 29 11:50:59 2015 From: report at bugs.python.org (Ethan Furman) Date: Sun, 29 Nov 2015 16:50:59 +0000 Subject: [issue25762] Calculation Mistake 1.5 * 0.3 In-Reply-To: <1448815253.26.0.478369331046.issue25762@psf.upfronthosting.co.za> Message-ID: <1448815859.43.0.814520290226.issue25762@psf.upfronthosting.co.za> Ethan Furman added the comment: Floating point calculations are not exact. https://docs.python.org/3/tutorial/floatingpoint.html https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html ---------- nosy: +ethan.furman resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 29 12:02:23 2015 From: report at bugs.python.org (jingtao chen) Date: Sun, 29 Nov 2015 17:02:23 +0000 Subject: [issue25763] I cannot use absolute path in sqlite3 , python 2.7.9, windows Message-ID: <1448816543.72.0.957954089761.issue25763@psf.upfronthosting.co.za> New submission from jingtao chen: I tried the way like here https://www.sqlite.org/c3ref/open.html#urifilenamesinsqlite3open but it is useless what I got is C:\Users\CJT-6220>python D:\NKUSearch\pr_cal\main.py Traceback (most recent call last): File "D:\NKUSearch\pr_cal\main.py", line 7, in conn = sqlite3.Connection('file:///D:/NKU.db') sqlite3.OperationalError: unable to open database file and I tried some other ways to write the URI but none of them works and PEP 249 did not mention anything about absolute path . So what can I do ? ---------- components: Windows messages: 255581 nosy: jingtao chen, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: I cannot use absolute path in sqlite3 , python 2.7.9, windows type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 29 12:49:53 2015 From: report at bugs.python.org (Albert Zeyer) Date: Sun, 29 Nov 2015 17:49:53 +0000 Subject: [issue5710] ctypes should return composite types from callbacks In-Reply-To: <1239038926.27.0.792638874347.issue5710@psf.upfronthosting.co.za> Message-ID: <1448819393.2.0.717402459391.issue5710@psf.upfronthosting.co.za> Albert Zeyer added the comment: Any update here? ---------- nosy: +Albert.Zeyer versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 29 13:14:17 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 29 Nov 2015 18:14:17 +0000 Subject: [issue24731] Incorrect assert in str_subtype_new In-Reply-To: <1437952885.56.0.72690112679.issue24731@psf.upfronthosting.co.za> Message-ID: <20151129181414.31417.65556@psf.io> Roundup Robot added the comment: New changeset 2ea1a3bf448f by Serhiy Storchaka in branch '2.7': Fixed Py3k warnings in tests for issue #24731. https://hg.python.org/cpython/rev/2ea1a3bf448f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 29 13:21:52 2015 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 29 Nov 2015 18:21:52 +0000 Subject: [issue25752] asyncio.readline - add customizable line separator In-Reply-To: <1448659598.46.0.288346349625.issue25752@psf.upfronthosting.co.za> Message-ID: <1448821312.57.0.763443472134.issue25752@psf.upfronthosting.co.za> Guido van Rossum added the comment: If you hit EOF in the middle of a partial separator, treat it as a premature EOF just as if you hit EOF before the separator -- the record is not properly terminated so it shouldn't be accepted. I prefer a single PR that has the full code. We keep the CPython Lib version and the asyncio repo synchronized, a PR for the asyncio repo is easier to handle for me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 29 14:03:14 2015 From: report at bugs.python.org (Robert Collins) Date: Sun, 29 Nov 2015 19:03:14 +0000 Subject: [issue5319] stdout error at interpreter shutdown fails to return OS error status In-Reply-To: <1235065081.04.0.732738239861.issue5319@psf.upfronthosting.co.za> Message-ID: <1448823794.82.0.955523895734.issue5319@psf.upfronthosting.co.za> Robert Collins added the comment: @Martin I was wrong re: the defs - they only cover function vs data, not return codes. So it looks fine to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 29 14:09:11 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 29 Nov 2015 19:09:11 +0000 Subject: [issue25764] PyObject_Call() is called with an exception set in subprocess Message-ID: <1448824151.78.0.622422139525.issue25764@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: http://buildbot.python.org/all/builders/x86%20OpenIndiana%203.x/builds/10847/steps/test/logs/stdio [117/400] test_subprocess -- running: test_tokenize (65 sec), test_concurrent_futures (38 sec) Assertion failed: !PyErr_Occurred(), file Objects/abstract.c, line 2158 Fatal Python error: Aborted Current thread 0x00000001 (most recent call first): File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/subprocess.py", line 1483 in _execute_child File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/subprocess.py", line 950 in __init__ File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/test_subprocess.py", line 2295 in test_close_fds_after_preexec File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/unittest/case.py", line 600 in run File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/unittest/case.py", line 648 in __call__ File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/unittest/suite.py", line 122 in run File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/unittest/suite.py", line 84 in __call__ File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/unittest/suite.py", line 122 in run File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/unittest/suite.py", line 84 in __call__ File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/unittest/runner.py", line 176 in run File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/support/__init__.py", line 1780 in _run_suite File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/support/__init__.py", line 1814 in run_unittest File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/test_subprocess.py", line 2657 in test_main File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/libregrtest/runtest.py", line 162 in runtest_inner File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/libregrtest/runtest.py", line 115 in runtest File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/libregrtest/runtest_mp.py", line 69 in run_tests_slave File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/libregrtest/main.py", line 379 in main File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/libregrtest/main.py", line 433 in main File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/libregrtest/main.py", line 455 in main_in_temp_cwd File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/regrtest.py", line 39 in File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/runpy.py", line 85 in _run_code File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/runpy.py", line 170 in _run_module_as_main Traceback (most recent call last): File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/runpy.py", line 170, in _run_module_as_main "__main__", mod_spec) File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/runpy.py", line 85, in _run_code exec(code, run_globals) File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/__main__.py", line 3, in regrtest.main_in_temp_cwd() File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/libregrtest/main.py", line 455, in main_in_temp_cwd main() File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/libregrtest/main.py", line 433, in main Regrtest().main(tests=tests, **kwargs) File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/libregrtest/main.py", line 392, in main self.run_tests() File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/libregrtest/main.py", line 354, in run_tests run_tests_multiprocess(self) File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/libregrtest/runtest_mp.py", line 212, in run_tests_multiprocess raise Exception(msg) Exception: Child error on test_subprocess: Exit code -6 make: *** [buildbottest] Error 1 program finished with exit code 2 ---------- components: Extension Modules messages: 255586 nosy: haypo, serhiy.storchaka priority: normal severity: normal status: open title: PyObject_Call() is called with an exception set in subprocess type: crash versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 29 14:09:45 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 29 Nov 2015 19:09:45 +0000 Subject: [issue25761] Improve unpickling errors handling In-Reply-To: <1448794765.73.0.847000762162.issue25761@psf.upfronthosting.co.za> Message-ID: <1448824185.51.0.20412251345.issue25761@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +alexandre.vassalotti, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 29 15:01:06 2015 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Sun, 29 Nov 2015 20:01:06 +0000 Subject: [issue25752] asyncio.readline - add customizable line separator In-Reply-To: <1448659598.46.0.288346349625.issue25752@psf.upfronthosting.co.za> Message-ID: <1448827266.24.0.0898846994136.issue25752@psf.upfronthosting.co.za> ???? ????????? added the comment: Well, https://github.com/python/asyncio/pull/297 is ready :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 29 15:07:21 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 29 Nov 2015 20:07:21 +0000 Subject: [issue25759] Python 2.7.11rc1 not building with Visual Studio 2015 In-Reply-To: <1448741441.78.0.371130073658.issue25759@psf.upfronthosting.co.za> Message-ID: <1448827641.86.0.621061267788.issue25759@psf.upfronthosting.co.za> R. David Murray added the comment: You are aware that you can't use existing pre-compiled extension modules with your 2015 build, right? It would be great if you could open a separate issue for the double close problem. This should be a doc issue for fixing the docs. ---------- assignee: -> docs at python components: +Documentation -Interpreter Core nosy: +docs at python, r.david.murray stage: -> needs patch type: compile error -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 29 15:10:14 2015 From: report at bugs.python.org (Ayushmaan Saxena) Date: Sun, 29 Nov 2015 20:10:14 +0000 Subject: [issue25765] Installation error Message-ID: <1448827814.4.0.634101535086.issue25765@psf.upfronthosting.co.za> New submission from Ayushmaan Saxena: installation error 0x80240004 ---------- components: Installation files: Python 3.5.0 (32-bit)_20151130012741.log messages: 255589 nosy: ayushmaan121 priority: normal severity: normal status: open title: Installation error type: performance versions: Python 3.5 Added file: http://bugs.python.org/file41191/Python 3.5.0 (32-bit)_20151130012741.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 29 15:13:25 2015 From: report at bugs.python.org (SilentGhost) Date: Sun, 29 Nov 2015 20:13:25 +0000 Subject: [issue25765] Installation error In-Reply-To: <1448827814.4.0.634101535086.issue25765@psf.upfronthosting.co.za> Message-ID: <1448828005.73.0.0596297601153.issue25765@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware type: performance -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 29 15:15:48 2015 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Sun, 29 Nov 2015 20:15:48 +0000 Subject: [issue25608] ascynio readexactly() should raise ValueError if passed length <= 0 in argument In-Reply-To: <1447355475.79.0.931064144901.issue25608@psf.upfronthosting.co.za> Message-ID: <1448828148.7.0.00852955647763.issue25608@psf.upfronthosting.co.za> ???? ????????? added the comment: Okay, https://github.com/python/asyncio/pull/298 is ready ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 29 15:16:41 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 29 Nov 2015 20:16:41 +0000 Subject: [issue25763] I cannot use absolute path in sqlite3 , python 2.7.9, windows In-Reply-To: <1448816543.72.0.957954089761.issue25763@psf.upfronthosting.co.za> Message-ID: <1448828201.71.0.622115507637.issue25763@psf.upfronthosting.co.za> R. David Murray added the comment: Did you try just using the absolute file path without the file://? That should work. I don't believe uri interpretation is enabled by default, according to the docs you linked to. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 29 15:21:50 2015 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Sun, 29 Nov 2015 20:21:50 +0000 Subject: [issue18161] call fchdir if subprocess.Popen(cwd=integer|fileobject) In-Reply-To: <1370634042.31.0.748329507458.issue18161@psf.upfronthosting.co.za> Message-ID: <1448828510.34.0.93558669747.issue18161@psf.upfronthosting.co.za> ???? ????????? added the comment: Do not understand what should be done in order to fix that... It will be nice if I can create pull request by myself ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 29 15:26:42 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 29 Nov 2015 20:26:42 +0000 Subject: [issue25766] __bytes__ doesn't work for str subclasses Message-ID: <1448828802.95.0.345172708456.issue25766@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Special __bytes__ method is purposed for converting to bytes with bytes constructor (as well as __str__ and __float__ for str and float). But this doesn't work if the class is a subclass of str. >>> class X: ... def __bytes__(self): ... return b'abc' ... >>> bytes(X()) b'abc' >>> class Y(str): ... def __bytes__(self): ... return b'abc' ... >>> bytes(Y()) Traceback (most recent call last): File "", line 1, in TypeError: string argument without an encoding ---------- components: Interpreter Core files: str___bytes__.patch keywords: patch messages: 255593 nosy: serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: __bytes__ doesn't work for str subclasses type: behavior versions: Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file41192/str___bytes__.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 29 15:30:32 2015 From: report at bugs.python.org (Kovid Goyal) Date: Sun, 29 Nov 2015 20:30:32 +0000 Subject: [issue25759] Python 2.7.11rc1 not building with Visual Studio 2015 In-Reply-To: <1448741441.78.0.371130073658.issue25759@psf.upfronthosting.co.za> Message-ID: <1448829032.14.0.854326624381.issue25759@psf.upfronthosting.co.za> Kovid Goyal added the comment: Yes, I am aware. I embed python in my application, which includes large C++ libraries. Those libraries are going to start requiring to be compiled with a modern compiler soon, which means I need python to also be compiled with a modern compiler. I already manually compile all python extensions in my build system, so that is not a problem. And before someone suggests I upgrade to python 3, porting half a million lines of python is simply not worth it for me. I'll be happy to open a separate bug report, but first I want some advice. I have got all the other tests passing as well, except one single test. test_gzip.test_many_append. The reason that test fails is apparently because of a buffering bug in the stdio C functions in VS 2015. Combining lots of seeks relative to SEEK_CUR causes read() to return incorrect data. I can make the test pass by modify the gzip module to open files with bufferring=0, or by putting in a seek(0, 0) to cause the stdio layer to flush its read buffer at the appropriate point. However, this is not an actual fix, just an inefficient workaround. My question is, how do I properly workaround this bug? And how come this bug is not triggered in Python 3.5.0? Am I diagnosing this correctly? Any other alternative explanations? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 29 15:40:48 2015 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Sun, 29 Nov 2015 20:40:48 +0000 Subject: [issue24660] Heapq + functools.partial : TypeError: unorderable types In-Reply-To: <1437220850.78.0.931988105122.issue24660@psf.upfronthosting.co.za> Message-ID: <1448829648.26.0.78647093526.issue24660@psf.upfronthosting.co.za> ???? ????????? added the comment: Yes, this is not a bug. Python 3.5 works as expected. Orderable lambda is the bug in python2.7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 29 15:43:05 2015 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Sun, 29 Nov 2015 20:43:05 +0000 Subject: [issue24523] coroutine asyncio.wait() does not preserve order of elements In-Reply-To: <1435473054.25.0.727716281024.issue24523@psf.upfronthosting.co.za> Message-ID: <1448829785.84.0.18656787971.issue24523@psf.upfronthosting.co.za> ???? ????????? added the comment: Yes this is not a bug. Use asyncio.gather(), it preserves order of elements :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 29 16:17:54 2015 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Sun, 29 Nov 2015 21:17:54 +0000 Subject: [issue15500] Python should support naming threads In-Reply-To: <1343650770.87.0.181202709436.issue15500@psf.upfronthosting.co.za> Message-ID: <1448831874.13.0.79792867333.issue15500@psf.upfronthosting.co.za> Changes by ???? ????????? : ---------- nosy: +mmarkk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 29 16:20:20 2015 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Sun, 29 Nov 2015 21:20:20 +0000 Subject: [issue12460] SocketServer.shutdown() does not have "timeout=None" parameter In-Reply-To: <1309512688.11.0.74406934883.issue12460@psf.upfronthosting.co.za> Message-ID: <1448832020.36.0.543392212135.issue12460@psf.upfronthosting.co.za> ???? ????????? added the comment: Please close this bug since asyncio is much more suitable, and things like socketserver is obsolete as I think. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 29 17:21:29 2015 From: report at bugs.python.org (Elizabeth Myers) Date: Sun, 29 Nov 2015 22:21:29 +0000 Subject: [issue25767] asyncio documentation section 18.5.2.3.1. (Windows) links to French Wikipedia in English docs Message-ID: <1448835689.06.0.772038280657.issue25767@psf.upfronthosting.co.za> New submission from Elizabeth Myers: The link for HPET in the asyncio documentation (18.5.2.3.1 Windows, final paragraph, see https://docs.python.org/3/library/asyncio-eventloops.html#windows) links to https://fr.wikipedia.org/wiki/High_Precision_Event_Timer for the HPET link even though the document is in English (it should link to the English Wikipedia version instead). ---------- assignee: docs at python components: Documentation messages: 255598 nosy: Elizacat, docs at python priority: normal severity: normal status: open title: asyncio documentation section 18.5.2.3.1. (Windows) links to French Wikipedia in English docs type: enhancement versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 29 17:34:09 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 29 Nov 2015 22:34:09 +0000 Subject: [issue25696] "make -j9 install" fails because bininstall target requires the libainstall target In-Reply-To: <1448202702.88.0.964294450431.issue25696@psf.upfronthosting.co.za> Message-ID: <1448836449.33.0.714880615034.issue25696@psf.upfronthosting.co.za> Martin Panter added the comment: Please go ahead with bininstall-3.patch if you prefer. It certainly avoids the problem you reported. Although I still encourage you to not add the dash before the command. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 29 17:44:15 2015 From: report at bugs.python.org (Nicholas Chammas) Date: Sun, 29 Nov 2015 22:44:15 +0000 Subject: [issue25768] compileall functions do not document return values Message-ID: <1448837055.66.0.314303073696.issue25768@psf.upfronthosting.co.za> New submission from Nicholas Chammas: I'm using the public functions of Python's built-in compileall module. https://docs.python.org/3/library/compileall.html#public-functions There doesn't appear to be documentation of what each of these functions returns. I figured out, for example, that compileall.compile_file() returns 1 when the file compiles successfully, and 0 if not. If this is "official" behavior, it would be good to see it documented so that we can rely on it. I'd be happy to submit a patch to fix this if a committer is willing to shepherd a new contributor (me) through the process. Otherwise, this is probably a quick fix for experienced contributors. ---------- assignee: docs at python components: Documentation messages: 255600 nosy: Nicholas Chammas, docs at python priority: normal severity: normal status: open title: compileall functions do not document return values type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 29 18:05:32 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 29 Nov 2015 23:05:32 +0000 Subject: [issue25627] distutils : file "bdist_rpm.py" does not quote filenames when executing the rpm command In-Reply-To: <1447535612.69.0.122030151224.issue25627@psf.upfronthosting.co.za> Message-ID: <1448838332.47.0.0543500546591.issue25627@psf.upfronthosting.co.za> Martin Panter added the comment: Okay so now I see 2.7 doesn?t support the context manager. I was mainly curious why you didn?t want to use subprocess. However a bigger problem with your first patch is shlex.quote() does not appear to be in Python 2 either. If you want to use proc.communicate() rather than reading line by line, perhaps subprocess.check_output() would be simpler. I?m not familiar with the RPM command but if there is only a modest amount of output it should be good enough. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 29 18:11:34 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 29 Nov 2015 23:11:34 +0000 Subject: [issue25742] locale.setlocale does not work with unicode strings In-Reply-To: <1448636049.37.0.145831829956.issue25742@psf.upfronthosting.co.za> Message-ID: <1448838694.04.0.369499883858.issue25742@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 29 18:21:55 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 29 Nov 2015 23:21:55 +0000 Subject: [issue12460] SocketServer.shutdown() does not have "timeout=None" parameter In-Reply-To: <1309512688.11.0.74406934883.issue12460@psf.upfronthosting.co.za> Message-ID: <1448839315.39.0.320739293186.issue12460@psf.upfronthosting.co.za> Martin Panter added the comment: Closing as retracted by original reporter. (Also, I wonder how useful the timeout would be. Adding a timeout isn?t going to fix a hanging server.) ---------- nosy: +martin.panter resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 29 18:41:03 2015 From: report at bugs.python.org (jingtao chen) Date: Sun, 29 Nov 2015 23:41:03 +0000 Subject: [issue25763] I cannot use absolute path in sqlite3 , python 2.7.9, windows In-Reply-To: <1448816543.72.0.957954089761.issue25763@psf.upfronthosting.co.za> Message-ID: <1448840463.92.0.310756569796.issue25763@psf.upfronthosting.co.za> jingtao chen added the comment: wow...It works... ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 29 21:20:33 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 30 Nov 2015 02:20:33 +0000 Subject: [issue25764] PyObject_Call() is called with an exception set in subprocess In-Reply-To: <1448824151.78.0.622422139525.issue25764@psf.upfronthosting.co.za> Message-ID: <1448850033.59.0.0655751951772.issue25764@psf.upfronthosting.co.za> Martin Panter added the comment: This looks like an intermittent (1 in ~5) failure in at least the Open Indiana 3.5 and 3.x buildbots. My guess is that fork() has failed, and because preexec_fn is in use, the code tries to call gc.enable() with the fork() exception already set. My patch adds a test and fixes that. Victor already fixed a similar error for the cleanup branch of subprocess_fork_exec() in Issue 22290. ---------- keywords: +patch nosy: +martin.panter stage: -> patch review Added file: http://bugs.python.org/file41193/preexec-fork.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 29 22:29:49 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 30 Nov 2015 03:29:49 +0000 Subject: [issue5319] stdout error at interpreter shutdown fails to return OS error status In-Reply-To: <1235065081.04.0.732738239861.issue5319@psf.upfronthosting.co.za> Message-ID: <20151130032946.31403.94899@psf.io> Roundup Robot added the comment: New changeset 6b08429a3932 by Martin Panter in branch 'default': Issue #5319: New Py_FinalizeEx() API to exit with status 120 on failure https://hg.python.org/cpython/rev/6b08429a3932 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 29 22:54:08 2015 From: report at bugs.python.org (Eryk Sun) Date: Mon, 30 Nov 2015 03:54:08 +0000 Subject: [issue25763] I cannot use absolute path in sqlite3 , python 2.7.9, windows In-Reply-To: <1448816543.72.0.957954089761.issue25763@psf.upfronthosting.co.za> Message-ID: <1448855648.58.0.0131483953734.issue25763@psf.upfronthosting.co.za> Changes by Eryk Sun : ---------- resolution: -> not a bug stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 29 23:12:14 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 30 Nov 2015 04:12:14 +0000 Subject: [issue5319] stdout error at interpreter shutdown fails to return OS error status In-Reply-To: <1235065081.04.0.732738239861.issue5319@psf.upfronthosting.co.za> Message-ID: <1448856734.41.0.317998768442.issue5319@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks everyone for helping to get this right. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 29 23:32:51 2015 From: report at bugs.python.org (Kovid Goyal) Date: Mon, 30 Nov 2015 04:32:51 +0000 Subject: [issue25759] Python 2.7.11rc1 not building with Visual Studio 2015 In-Reply-To: <1448741441.78.0.371130073658.issue25759@psf.upfronthosting.co.za> Message-ID: <1448857971.55.0.910346895751.issue25759@psf.upfronthosting.co.za> Kovid Goyal added the comment: To answer part of my question, the reason the fseek()+fread() bug does not affect python 3.5.0 appears to be because it implements its own buffering and does not use fseek()/fread() at all. Sigh, I really hope the answer does not end up being that I have to re-implement fseek()/ftell()/fread()/fwrite() using lseek()/read()/write() on windows. Or I could wait and hope Microsoft fixes the bug :) As a first step, to confirm that the bug is in the CRT, I'll have the gzip module record all reads/seeks/tells and then see if I can reproduce the bug in a plain C program. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 30 00:16:04 2015 From: report at bugs.python.org (lplatypus) Date: Mon, 30 Nov 2015 05:16:04 +0000 Subject: [issue25769] Crash due to using weakref referent without acquiring a strong reference Message-ID: <1448860564.76.0.866220529061.issue25769@psf.upfronthosting.co.za> New submission from lplatypus: I have encountered some crashes in a multithreaded application which appear to be due to a bug in weakref_richcompare in Objects/weakref.c (I am using Python 2.7.9, but the same weakref code exists in 3.5 and hg default branch too) weakref_richcompare ends with the statement: return PyObject_RichCompare(PyWeakref_GET_OBJECT(self), PyWeakref_GET_OBJECT(other), op); At this point the code has established that the referents of "self" and "other" are still alive, and it is trying to compare the referents. However it has not acquired a strong reference to the referents, so I think it is possible for one of them to be deleted half way through this comparison. This can lead to a crash, because PyObject_RichCompare assumes that the PyObject*?s it was passed will remain usable for the duration of the call. The crash dumps I have seen involve data corruption consistent with one of these PyObject's being deleted and the memory used for something else, eg: 00 python27!try_3way_compare+0x15 [objects\object.c @ 712] 01 python27!try_3way_to_rich_compare+0xb [objects\object.c @ 901] 02 python27!do_richcmp+0x2c [objects\object.c @ 935] 03 python27!PyObject_RichCompare+0x99 [objects\object.c @ 982] 04 python27!weakref_richcompare+0x6a [objects\weakrefobject.c @ 212] In this example, in try_3way_compare the value of v->ob_type was 0x5f637865, which is ASCII "exc_" and not a valid pointer at all. Other places in weakrefobject.c seem to have a similar weakness, eg in weakref_hash and weakref_repr. I have not been successful in producing a small test case to demonstrate this crash. ---------- components: Interpreter Core messages: 255608 nosy: ldeller priority: normal severity: normal status: open title: Crash due to using weakref referent without acquiring a strong reference type: crash versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 30 00:43:30 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 30 Nov 2015 05:43:30 +0000 Subject: [issue25701] Document that tp_setattro and tp_setattr are used for deleting attributes In-Reply-To: <1448261904.1.0.459120146493.issue25701@psf.upfronthosting.co.za> Message-ID: <1448862210.55.0.569777596582.issue25701@psf.upfronthosting.co.za> Martin Panter added the comment: In the python-dev thread, Nick Coghlan gave some arguments and examples where PyObject_SetAttr() is intended to be used for deletion. So I will keep my changes for PyObject_SetAttr(), and also _SetAttrString() for consistency. My second patch documents deletion with sq_ass_item(), mp_ass_subscript(), and PySequence_SetItem(). PyObject_SetItem() does not look like it deletes items. It explicitly considers value == NULL to be an error. As a consequence, PyMapping_SetItemString() does not delete either. PySequence_SetItem() does accept NULL to delete the item. I think this is reasonable, to keep it consistent with sq_ass_item(), so I documented it. PySequence_SetSlice() also accepts NULL to delete the slice. But I am more reluctant to document this, because I don?t know of any slot or other code that would benefit. So I have left it as is for the time being. ---------- Added file: http://bugs.python.org/file41194/setattr.2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 30 01:06:53 2015 From: report at bugs.python.org (lplatypus) Date: Mon, 30 Nov 2015 06:06:53 +0000 Subject: [issue25769] Crash due to using weakref referent without acquiring a strong reference In-Reply-To: <1448860564.76.0.866220529061.issue25769@psf.upfronthosting.co.za> Message-ID: <1448863613.99.0.616314226333.issue25769@psf.upfronthosting.co.za> lplatypus added the comment: I think the fix for this is simply a matter of using Py_INCREF/Py_DECREF around usage of the referent. This should only be necessary for nontrivial usages where the GIL might be released. Here is a patch. ---------- keywords: +patch Added file: http://bugs.python.org/file41195/issue25769-weakref.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 30 01:10:42 2015 From: report at bugs.python.org (Kovid Goyal) Date: Mon, 30 Nov 2015 06:10:42 +0000 Subject: [issue25759] Python 2.7.11rc1 not building with Visual Studio 2015 In-Reply-To: <1448741441.78.0.371130073658.issue25759@psf.upfronthosting.co.za> Message-ID: <1448863842.11.0.661577792842.issue25759@psf.upfronthosting.co.za> Kovid Goyal added the comment: Doesn't seem like a bug in the CRT, I cannot reproduce in a plain CRT program, so now I get to try to figure out what is broken in fileobject.c by VS 2015. That's a relief :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 30 01:56:54 2015 From: report at bugs.python.org (SilentGhost) Date: Mon, 30 Nov 2015 06:56:54 +0000 Subject: [issue25627] distutils : file "bdist_rpm.py" does not quote filenames when executing the rpm command In-Reply-To: <1447535612.69.0.122030151224.issue25627@psf.upfronthosting.co.za> Message-ID: <1448866614.87.0.572087810018.issue25627@psf.upfronthosting.co.za> SilentGhost added the comment: OK, here is seemingly python2-proof patch. At least it shouldn't have glaring syntax errors on python2 (as the previous one did). But I'd appreciate if some RPM people could actually run the test. ---------- Added file: http://bugs.python.org/file41196/issue25627_4.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 30 03:18:40 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 30 Nov 2015 08:18:40 +0000 Subject: [issue25764] PyObject_Call() is called with an exception set in subprocess In-Reply-To: <1448824151.78.0.622422139525.issue25764@psf.upfronthosting.co.za> Message-ID: <1448871520.61.0.220252759125.issue25764@psf.upfronthosting.co.za> STINNER Victor added the comment: > Assertion failed: !PyErr_Occurred(), file Objects/abstract.c, line 2158 Quick reminder: it's not a major bug if PyObject_Call() is called with an exception set. The exception will be kept in some cases. But I added the assertion because the exception is lost in some other cases. Example: calling hasattr(obj, name) replaces the current exception with an AttributeError and then clears the AttributeError exception if the object doesn't have the attribute. > My guess is that fork() has failed, Oh good job, it's exactly that: I'm able to reproduce the bug with your unit test (from your attached patch). If I recall correctly, there is no overallocation on Solaris (OpenIndiana), and this buildbot is running low memory (MemoryError is very common). fork() can likely fail under low memory. > and because preexec_fn is in use, the code tries to call gc.enable() with the fork() exception already set. My patch adds a test and fixes that. Hum, I think that your patch can be simplified. Replace: if (pid == -1) { PyErr_SetFromErrno(PyExc_OSError); ... if (need_to_reenable_gc && _enable_gc(gc_module)) ... with: if (need_to_reenable_gc && _enable_gc(gc_module)) ... ... if (pid == -1) { PyErr_SetFromErrno(PyExc_OSError); What do you think? > Victor already fixed a similar error for the cleanup branch of subprocess_fork_exec() in Issue 22290. I reproduced the issue on Linux with pyfailmalloc. You can play with pyfailmalloc to try to find similar bugs. The Bitbucket repository contains the latest debug_cpython.patch which adds some more checks to make the analysis faster and more effective, and debug_cpython.gdb contains commands to run it. https://bitbucket.org/haypo/pyfailmalloc ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 30 05:17:13 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 30 Nov 2015 10:17:13 +0000 Subject: [issue25764] PyObject_Call() is called with an exception set in subprocess In-Reply-To: <1448824151.78.0.622422139525.issue25764@psf.upfronthosting.co.za> Message-ID: <1448878633.43.0.772665695998.issue25764@psf.upfronthosting.co.za> Martin Panter added the comment: Couldn?t re-enabling garbage collection cause errno to be overwritten? Even if I saved errno until later, there is still the RuntimeError from releasing the import lock to worry about. Now that I look closer, I see the lock release code path sets this exception, but does not return NULL. Another bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 30 05:24:15 2015 From: report at bugs.python.org (Kovid Goyal) Date: Mon, 30 Nov 2015 10:24:15 +0000 Subject: [issue25759] Python 2.7.11rc1 not building with Visual Studio 2015 In-Reply-To: <1448741441.78.0.371130073658.issue25759@psf.upfronthosting.co.za> Message-ID: <1448879055.66.0.832044779058.issue25759@psf.upfronthosting.co.za> Kovid Goyal added the comment: I take it back, my methodology in reproducing the function calls used by the gzip module was flawed. It does look like a bug in the CRT, but I have not been able to isolate a simple way of reproducing it. I have however, found a workaround for it, that has an acceptable performance impact. https://github.com/kovidgoyal/cpython/commit/72ae720ab057b1ac0402d67a7195d575d34afbbd Now all tests pass (except for tcl/tk and distutils, neither of which I care about -- well I will probably need to fix up distutils at some point, but not now :). Running testsuite as ./PCbuild/amd64/python_d.exe Lib/test/regrtest.py -u network,cpu,subprocess,urlfetch @steve: Thank you for all the work you did porting python 3.x to VS 2015, that certainly made by life a lot easier. I would of course, be ecstatic if you were to consider merging my work into the python 2.7 branch, but if not, I understand -- no one likes to maintain a legacy codebase. In any case, for interested third parties, my work is available here: https://github.com/kovidgoyal/cpython (2.7 branch) and instructions on building python on windows using a nice cygwin environment are here: https://github.com/kovidgoyal/calibre/blob/master/setup/installer/windows/notes2.rst ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 30 05:36:29 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 30 Nov 2015 10:36:29 +0000 Subject: [issue25627] distutils : file "bdist_rpm.py" does not quote filenames when executing the rpm command In-Reply-To: <1447535612.69.0.122030151224.issue25627@psf.upfronthosting.co.za> Message-ID: <1448879789.09.0.667624437123.issue25627@psf.upfronthosting.co.za> Martin Panter added the comment: I left some comments on the code review. I think this definitely needs someone able to test it; I don?t think I am up to it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 30 05:49:24 2015 From: report at bugs.python.org (Armin Rigo) Date: Mon, 30 Nov 2015 10:49:24 +0000 Subject: [issue25769] Crash due to using weakref referent without acquiring a strong reference In-Reply-To: <1448860564.76.0.866220529061.issue25769@psf.upfronthosting.co.za> Message-ID: <1448880564.81.0.972439451612.issue25769@psf.upfronthosting.co.za> Armin Rigo added the comment: PyWeakref_GET_OBJECT() is inherently dangerous: the weakref might go away not only the next time the GIL is released, but also the next time the code does any seemingly unrelated Py_DECREF() (which might decref the object into inexistence) or memory allocation (which might trigger the GC). I'd suggest adding the comment above in the docs and reviewing all usages inside CPython's code base. ---------- nosy: +arigo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 30 06:14:14 2015 From: report at bugs.python.org (SilentGhost) Date: Mon, 30 Nov 2015 11:14:14 +0000 Subject: [issue25627] distutils : file "bdist_rpm.py" does not quote filenames when executing the rpm command In-Reply-To: <1447535612.69.0.122030151224.issue25627@psf.upfronthosting.co.za> Message-ID: <1448882054.99.0.42113190688.issue25627@psf.upfronthosting.co.za> SilentGhost added the comment: Updated version of the patch including Martin's suggestions. ---------- Added file: http://bugs.python.org/file41197/issue25627_5.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 30 08:28:31 2015 From: report at bugs.python.org (Armin Rigo) Date: Mon, 30 Nov 2015 13:28:31 +0000 Subject: [issue25769] Crash due to using weakref referent without acquiring a strong reference In-Reply-To: <1448860564.76.0.866220529061.issue25769@psf.upfronthosting.co.za> Message-ID: <1448890111.23.0.763430995141.issue25769@psf.upfronthosting.co.za> Armin Rigo added the comment: Actually, Py_DECREF() may also release the GIL by calling a Python __del__() method; it doesn't have to directly decref the exact object. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 30 09:00:45 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 30 Nov 2015 14:00:45 +0000 Subject: [issue25759] Python 2.7.11rc1 not building with Visual Studio 2015 In-Reply-To: <1448741441.78.0.371130073658.issue25759@psf.upfronthosting.co.za> Message-ID: <1448892045.59.0.669601261713.issue25759@psf.upfronthosting.co.za> R. David Murray added the comment: Unfortunately it is unlikely we'll merge it, since because of the compiled extension issue we have a negative motivation for supporting anything other than the release compiler currently used. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 30 09:03:13 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 30 Nov 2015 14:03:13 +0000 Subject: [issue15500] Python should support exporting thread names to the OS In-Reply-To: <1343650770.87.0.181202709436.issue15500@psf.upfronthosting.co.za> Message-ID: <1448892193.3.0.492998611785.issue15500@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- stage: -> needs patch title: Python should support naming threads -> Python should support exporting thread names to the OS versions: +Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 30 10:10:49 2015 From: report at bugs.python.org (Kovid Goyal) Date: Mon, 30 Nov 2015 15:10:49 +0000 Subject: [issue25759] Python 2.7.11rc1 not building with Visual Studio 2015 In-Reply-To: <1448741441.78.0.371130073658.issue25759@psf.upfronthosting.co.za> Message-ID: <1448896249.19.0.995210947057.issue25759@psf.upfronthosting.co.za> Kovid Goyal added the comment: No worries, as I said, I understand, I would probably do the same, were I in your shoes. I have found that being a maintainer of a complex software project tends to naturally increase conservatism :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 30 10:38:07 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 30 Nov 2015 15:38:07 +0000 Subject: [issue25718] itertools.accumulate __reduce__/__setstate__ bug In-Reply-To: <1448352443.54.0.731172452763.issue25718@psf.upfronthosting.co.za> Message-ID: <20151130153740.648.68042@psf.io> Roundup Robot added the comment: New changeset 095d21df9374 by Serhiy Storchaka in branch '3.4': Issue #25718: Fixed copying object with state with boolean value is false. https://hg.python.org/cpython/rev/095d21df9374 New changeset 3d39e1e2dcb3 by Serhiy Storchaka in branch '2.7': Issue #25718: Fixed copying object with state with boolean value is false. https://hg.python.org/cpython/rev/3d39e1e2dcb3 New changeset fecb07050aae by Serhiy Storchaka in branch '3.5': Issue #25718: Fixed copying object with state with boolean value is false. https://hg.python.org/cpython/rev/fecb07050aae New changeset 962086677306 by Serhiy Storchaka in branch 'default': Issue #25718: Fixed copying object with state with boolean value is false. https://hg.python.org/cpython/rev/962086677306 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 30 11:39:52 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 30 Nov 2015 16:39:52 +0000 Subject: [issue25765] Installation error In-Reply-To: <1448827814.4.0.634101535086.issue25765@psf.upfronthosting.co.za> Message-ID: <1448901592.49.0.778884425747.issue25765@psf.upfronthosting.co.za> Steve Dower added the comment: Hard to tell, but you may just need to reboot. I'd also make sure you've installed all Windows Updates that you need, as the one we're trying to install should be in there (which means our installer doesn't have to do it). The error code is from Windows Update (which we sometimes need to run as part of the install), and there's so much spam out there these days that it is impossible to find out what it means. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 30 11:56:51 2015 From: report at bugs.python.org (Eryk Sun) Date: Mon, 30 Nov 2015 16:56:51 +0000 Subject: [issue25765] Installation error In-Reply-To: <1448827814.4.0.634101535086.issue25765@psf.upfronthosting.co.za> Message-ID: <1448902611.54.0.741665085232.issue25765@psf.upfronthosting.co.za> Eryk Sun added the comment: > The error code is from Windows Update (which we sometimes need to > run as part of the install), and there's so much spam out there > these days that it is impossible to find out what it means. The error is WU_E_NOT_INITIALIZED [1], "the object could not be initialized" -- whatever object it's talking about. [1]: https://support.microsoft.com/en-us/kb/938205 ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 30 14:58:46 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 30 Nov 2015 19:58:46 +0000 Subject: [issue25718] itertools.accumulate __reduce__/__setstate__ bug In-Reply-To: <1448352443.54.0.731172452763.issue25718@psf.upfronthosting.co.za> Message-ID: <1448913526.67.0.0720199522187.issue25718@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The bug in the copy module is fixed. As for accumulate's __reduce__, I don't think we can do something. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 30 17:50:27 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 30 Nov 2015 22:50:27 +0000 Subject: [issue25698] test regressions introduced with the fix for #22995 In-Reply-To: <1448218706.46.0.334921108763.issue25698@psf.upfronthosting.co.za> Message-ID: <1448923827.0.0.934989111746.issue25698@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: This seems entirely reproducible in a local Xenial sbuild using the source packages in https://launchpad.net/~doko/+archive/ubuntu/toolchain/+packages Interestingly, inspection of the built artifacts in the schroot after all is done yields: # find . -name copy_reg.py? | xargs ls -l -rw-rw-r-- 1 barry barry 5597 Nov 30 16:52 ./Lib/copy_reg.pyc -rw-rw-r-- 1 barry barry 5553 Nov 30 16:53 ./Lib/copy_reg.pyo -rw-rw-r-- 1 barry barry 5091 Nov 30 17:03 ./debian/tmp-dbg/usr/lib/python2.7/copy_reg.pyc -rw-rw-r-- 1 barry barry 5047 Nov 30 17:03 ./debian/tmp-dbg/usr/lib/python2.7/copy_reg.pyo -rw-rw-r-- 1 barry barry 5091 Nov 30 17:02 ./debian/tmp-shdbg/usr/lib/python2.7/copy_reg.pyc -rw-rw-r-- 1 barry barry 5047 Nov 30 17:02 ./debian/tmp-shdbg/usr/lib/python2.7/copy_reg.pyo Those are debug builds, so it seems reasonable they are different sizes than the non-debug artifacts in Lib, right? And since they are self-consistent in size, it seems like it wouldn't be caused by a pyc/pyo write bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 30 17:55:18 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 30 Nov 2015 22:55:18 +0000 Subject: [issue25698] test regressions introduced with the fix for #22995 In-Reply-To: <1448218706.46.0.334921108763.issue25698@psf.upfronthosting.co.za> Message-ID: <1448924118.56.0.79706023212.issue25698@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: First failure in test run afaict: ====================================================================== ERROR: test_recursive_dict_subclass_and_inst (test.test_cpickle.cStringIOCPicklerFastTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/build/python2.7-96oGYh/python2.7-2.7.11~rc1/Lib/test/test_cpickle.py", line 175, in wrapper func(self) File "/build/python2.7-96oGYh/python2.7-2.7.11~rc1/Lib/test/pickletester.py", line 819, in test_recursive_dict_subclass_and_inst self.check_recursive_collection_and_inst(MyDict.fromkeys) File "/build/python2.7-96oGYh/python2.7-2.7.11~rc1/Lib/test/pickletester.py", line 790, in check_recursive_collection_and_inst s = self.dumps(y, proto) File "/build/python2.7-96oGYh/python2.7-2.7.11~rc1/Lib/test/test_cpickle.py", line 141, in dumps p.dump(arg) AttributeError: 'module' object has no attribute '_reduce_ex' ====================================================================== ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 30 17:56:29 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 30 Nov 2015 22:56:29 +0000 Subject: [issue25698] test regressions introduced with the fix for #22995 In-Reply-To: <1448218706.46.0.334921108763.issue25698@psf.upfronthosting.co.za> Message-ID: <1448924189.83.0.0867664284188.issue25698@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: But if I just run test_cpickle.py, it succeeds! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 30 18:13:50 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 30 Nov 2015 23:13:50 +0000 Subject: [issue25698] test regressions introduced with the fix for #22995 In-Reply-To: <1448218706.46.0.334921108763.issue25698@psf.upfronthosting.co.za> Message-ID: <1448925230.39.0.112354878366.issue25698@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could you please add debugging output to check that the copy_reg module is empty if tests failed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 30 18:19:07 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 30 Nov 2015 23:19:07 +0000 Subject: [issue25698] test regressions introduced with the fix for #22995 In-Reply-To: <1448218706.46.0.334921108763.issue25698@psf.upfronthosting.co.za> Message-ID: <1448925547.29.0.17463965754.issue25698@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: I set a breakpoint where the error occurs. I'm in test_cpickle.py dumps(). Doing cPickle.dumps(arg) in the bp, I get the error. arg is: (Pdb) arg {<__main__.H object at 0x7ff8e2a870d0>: None} (Pdb) type(arg) Look again at the AttributeError: (Pdb) cPickle.dumps(arg) *** AttributeError: 'module' object has no attribute '_reduce_ex' First, why is that trying to find the attribute of a module object instead of the MyDict instance? I even tried this just to discount the effects of __main__.H: (Pdb) cPickle.dumps(type(arg)()) *** AttributeError: 'module' object has no attribute '_reduce_ex' (as you'd expect, type(arg)() is just an instance of a MyDict. Two questions: why is it trying to get the attribute on a module object, and why is the attribute it's trying to get '_reduce_ex' instead of '__reduce_ex__'? The attribute to get is taken from the __reduce_ex___str in cPickle.c, which gets defined as: #define INIT_STR(S) if (!( S ## _str=PyString_InternFromString(#S))) return -1; ... INIT_STR(__reduce_ex__); This is a compile-time definition, so it makes no sense that it would be trying to find the wrong attribute in some cases (e.g. when running the full regrtest.py) but not in others (e.g. running just test_cpickle.py). But I can find no other references to a string containing "reduce_ex" so the cPickle version has to be it. And that gets initialized in init_stuff(), called from initcPickle() so I don't see any other way for it to get corrupted. cPickle.dumps({}) works just fine, so it's an artifact of the MyDict. That's all I've figured out for now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 30 18:25:37 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 30 Nov 2015 23:25:37 +0000 Subject: [issue25698] test regressions introduced with the fix for #22995 In-Reply-To: <1448218706.46.0.334921108763.issue25698@psf.upfronthosting.co.za> Message-ID: <1448925937.52.0.810679644275.issue25698@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Default __reduce_ex__ and __reduce__ implementations call copy_reg._reduce_ex. cPickle.dumps({}) works because __reduce_ex__ is not called, dict is supported by pickle directly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 30 18:26:23 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 30 Nov 2015 23:26:23 +0000 Subject: [issue25698] test regressions introduced with the fix for #22995 In-Reply-To: <1448218706.46.0.334921108763.issue25698@psf.upfronthosting.co.za> Message-ID: <1448925983.58.0.121384938966.issue25698@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: ... for protocols < 2. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 30 20:10:00 2015 From: report at bugs.python.org (Dimitri John Ledkov) Date: Tue, 01 Dec 2015 01:10:00 +0000 Subject: [issue25751] ctypes.util , Shell Injection in find_library() In-Reply-To: <1448655560.8.0.523539379986.issue25751@psf.upfronthosting.co.za> Message-ID: <1448932200.8.0.534727280577.issue25751@psf.upfronthosting.co.za> Dimitri John Ledkov added the comment: Whilst fixed in 3.5, it is not fixed in 2.7. And the reporter believes this is a security vulnerability. Can this be cherry-picked into the 2.7 branch? ---------- nosy: +xnox _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 30 20:54:54 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 01 Dec 2015 01:54:54 +0000 Subject: [issue25751] ctypes.util , Shell Injection in find_library() In-Reply-To: <1448655560.8.0.523539379986.issue25751@psf.upfronthosting.co.za> Message-ID: <1448934894.98.0.248212800211.issue25751@psf.upfronthosting.co.za> Martin Panter added the comment: I do not believe 3.5 is fixed either: $ python3.5 Python 3.5.0 (default, Sep 20 2015, 11:28:25) [GCC 5.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import ctypes.util >>> ctypes.util.find_library("; echo Hello shell >&2") Hello shell >>> Issue 22636 has a patch with some review comments, but is is still open. I think it needs someone to take another look, perhaps update the patch, and get it committed. I will mark the other issue as a bug fix for 2.7 and 3.4+. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 30 20:56:30 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 01 Dec 2015 01:56:30 +0000 Subject: [issue22636] avoid using a shell in ctypes.util: replace os.popen with subprocess In-Reply-To: <1413325975.89.0.175884398711.issue22636@psf.upfronthosting.co.za> Message-ID: <1448934990.95.0.520261695536.issue22636@psf.upfronthosting.co.za> Martin Panter added the comment: Marking for bug fix in 2.7, requested in Issue 25751. ---------- type: enhancement -> behavior versions: +Python 2.7, Python 3.4, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 30 21:07:11 2015 From: report at bugs.python.org (Joe Jevnik) Date: Tue, 01 Dec 2015 02:07:11 +0000 Subject: [issue25770] expose name, args, and kwargs from methodcaller Message-ID: <1448935631.22.0.209196895729.issue25770@psf.upfronthosting.co.za> New submission from Joe Jevnik: This patch adds 3 properties to methodcaller objects for inspecting the object at runtime: 1. 'name': the name of the method to call 2. 'args': the position arguments to pass to the method 3. 'keywords': the keyword arguments to pass to the method args and keywords act like functools.partial (that is why I did not name it kwargs). I noticed that recently the repr changed to expose this information which helps in the debugging use case; however, this allows us to use the methodcaller to maybe construct a new methodcaller with different args, or call a different method with the same args. ---------- components: Library (Lib) files: methodcaller-attrs.patch keywords: patch messages: 255636 nosy: llllllllll priority: normal severity: normal status: open title: expose name, args, and kwargs from methodcaller type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file41198/methodcaller-attrs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 30 21:17:09 2015 From: report at bugs.python.org (Emanuel Barry) Date: Tue, 01 Dec 2015 02:17:09 +0000 Subject: [issue25770] expose name, args, and kwargs from methodcaller In-Reply-To: <1448935631.22.0.209196895729.issue25770@psf.upfronthosting.co.za> Message-ID: <1448936229.12.0.820374886411.issue25770@psf.upfronthosting.co.za> Changes by Emanuel Barry : ---------- nosy: +ebarry stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 30 21:43:44 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 01 Dec 2015 02:43:44 +0000 Subject: [issue25764] PyObject_Call() is called with an exception set in subprocess In-Reply-To: <1448824151.78.0.622422139525.issue25764@psf.upfronthosting.co.za> Message-ID: <1448937824.48.0.119144935453.issue25764@psf.upfronthosting.co.za> Martin Panter added the comment: This patch fixes the exception when releasing the import lock. I also moved the Py_XDECREF(gc_module) back out to where it was to keep the patch to a minimum, but I don?t really see a way to simplify it much more. Apparently Solaris supports posix_spawn(), which doesn?t require double the memory like fork(). But implementing that would be a significant project, and was rejected in Issue 20104. ---------- Added file: http://bugs.python.org/file41199/preexec-fork.2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 30 22:52:31 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 01 Dec 2015 03:52:31 +0000 Subject: [issue25708] runpy hides traceback for some exceptions In-Reply-To: <1448290164.96.0.435205932558.issue25708@psf.upfronthosting.co.za> Message-ID: <1448941951.14.0.744147420262.issue25708@psf.upfronthosting.co.za> Martin Panter added the comment: I think there are a couple of related bugs here, with open reports: 1. Issue 14285: runpy catches various exceptions including AttributeError, and incorrectly assumes this means you gave it a bad module or package name. 2. Issue 19771: runpy incorrectly interprets exceptions such as in (1) as meaning the package doesn?t have a __main__ submodule. But these exceptions can happen even if hello.__main__ exists. My patch there changes the error message to: /home/proj/python/cpython/python: Error while finding spec for 'hello.__main__' (AttributeError: module 'random' has no attribute 'dsgjdgj') 3. Issue 16217: runpy should handle exceptions from user code by printing out the relevant traceback, rather than letting the Python interpreter print out all the internal runpy frames. Marking this as a dupe of Issue 14285, but I think a proper solution to that would probably affect the other two as well. ---------- nosy: +martin.panter resolution: -> duplicate status: open -> closed superseder: -> Traceback wrong on ImportError while executing a package _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 30 22:55:21 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 01 Dec 2015 03:55:21 +0000 Subject: [issue14285] Traceback wrong on ImportError while executing a package In-Reply-To: <1331621436.28.0.000669565075438.issue14285@psf.upfronthosting.co.za> Message-ID: <1448942121.49.0.333259768039.issue14285@psf.upfronthosting.co.za> Martin Panter added the comment: I suspect a proper solution of this bug would also help with Issue 16217 (provide only the relevant traceback for exceptions from user code). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 30 23:57:37 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 01 Dec 2015 04:57:37 +0000 Subject: [issue25767] asyncio documentation section 18.5.2.3.1. (Windows) links to French Wikipedia in English docs In-Reply-To: <1448835689.06.0.772038280657.issue25767@psf.upfronthosting.co.za> Message-ID: <20151201045734.27936.62082@psf.io> Roundup Robot added the comment: New changeset f475379bf22c by Zachary Ware in branch '3.4': Issue #25767: Link to English Wikipedia instead of French. https://hg.python.org/cpython/rev/f475379bf22c New changeset fee19d2d7713 by Zachary Ware in branch '3.5': Issue #25767: Merge with 3.4 https://hg.python.org/cpython/rev/fee19d2d7713 New changeset 734247d5d0f9 by Zachary Ware in branch 'default': Closes #25767: Merge with 3.5 https://hg.python.org/cpython/rev/734247d5d0f9 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 30 23:57:52 2015 From: report at bugs.python.org (Zachary Ware) Date: Tue, 01 Dec 2015 04:57:52 +0000 Subject: [issue25767] asyncio documentation section 18.5.2.3.1. (Windows) links to French Wikipedia in English docs In-Reply-To: <1448835689.06.0.772038280657.issue25767@psf.upfronthosting.co.za> Message-ID: <1448945871.99.0.199128243577.issue25767@psf.upfronthosting.co.za> Zachary Ware added the comment: Thanks for the report! ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________