From report at bugs.python.org Tue Apr 1 00:16:36 2014 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 31 Mar 2014 22:16:36 +0000 Subject: [issue16716] Deprecate OSError aliases in the doc In-Reply-To: <1355861242.44.0.0203808398116.issue16716@psf.upfronthosting.co.za> Message-ID: <1396304196.07.0.258108900102.issue16716@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Close the issue after #f5dda52a4ccd and #8d5f005a0da3 ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 00:17:14 2014 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 31 Mar 2014 22:17:14 +0000 Subject: [issue21117] inspect: PartialSignature and PartialParameter classes In-Reply-To: <1396297836.4.0.601810070188.issue21117@psf.upfronthosting.co.za> Message-ID: <1396304234.88.0.0458184458275.issue21117@psf.upfronthosting.co.za> Yury Selivanov added the comment: @Nick: > Oops: already bound positional-*only* arguments should be hidden. Hm, good catch. I'm not sure we currently do this. I'll check if this needs to be fixed (in 3.4.1 too). > I'm +0 on new types to clean that up if necessary, but would prefer it if we could just improve the translation to ordinary signature objects instead. I'm not sure I understand what you mean by "translation to ordinary signature objects". Could you please elaborate on this? @R. David: > I believe it is a python invariant that a == b implies hash(a) == hash(b). I think that 'hash(a) == hash(b)' means that 'a == b' (strongly). But not reverse. Or am I wrong? > I don't see why the two signatures should be equal. I'm not even sure why the bound argument shows up in the signature of the partial. Well, why shouldn't they be equal? They have same parameters, same default values. Quoting pep 362: """...two signatures are equal only when their corresponding parameters are equal and have the exact same names...""". Moreover, this behaviour is implemented since 3.3. But their hashes shouldn't be equal, that's something I can agree on. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 00:29:52 2014 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 31 Mar 2014 22:29:52 +0000 Subject: [issue21117] inspect: PartialSignature and PartialParameter classes In-Reply-To: <1396304234.88.0.0458184458275.issue21117@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: On 1 Apr 2014 08:17, "Yury Selivanov" wrote: > > > I'm +0 on new types to clean that up if necessary, but would prefer it if > we could just improve the translation to ordinary signature objects instead. > > I'm not sure I understand what you mean by "translation to ordinary signature objects". Could you please elaborate on this? If arguments bound by position disappear from the signature, and those bound by keyword are mapped to keyword-only parameters with a default, we should get a valid and accurate signature. That's a 3.4.1 bug fix, rather than a 3.5 feature. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 00:37:56 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Mon, 31 Mar 2014 22:37:56 +0000 Subject: [issue18644] Got ResourceWarning: unclosed file when using test function from formatter module In-Reply-To: <1375537519.43.0.405840418589.issue18644@psf.upfronthosting.co.za> Message-ID: <1396305476.15.0.386598767297.issue18644@psf.upfronthosting.co.za> A.M. Kuchling added the comment: Version 5 of the patch looks fine; Vajrasky, I think you can go ahead and commit it. (I didn't understand RDM's comment about pydoc using DumbWriter; in 3.4, it doesn't seem to me that pydoc does. What am I missing?) ---------- nosy: +akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 00:45:03 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 31 Mar 2014 22:45:03 +0000 Subject: [issue16716] Deprecate OSError aliases in the doc In-Reply-To: <1355861242.44.0.0203808398116.issue16716@psf.upfronthosting.co.za> Message-ID: <1396305903.35.0.23293695827.issue16716@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Andrew, please revert this. The modify() method is deprecated, so the "deprecated" markup is inappropriate here. ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 00:45:50 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 31 Mar 2014 22:45:50 +0000 Subject: [issue16716] Deprecate OSError aliases in the doc In-Reply-To: <1355861242.44.0.0203808398116.issue16716@psf.upfronthosting.co.za> Message-ID: <1396305950.73.0.714860447839.issue16716@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Oops, trying again: The modify() method is not deprecated, so the "deprecated" markup is inappropriate here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 00:46:11 2014 From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=) Date: Mon, 31 Mar 2014 22:46:11 +0000 Subject: [issue7676] IDLE shell shouldn't use TABs In-Reply-To: <1263213381.47.0.181451927584.issue7676@psf.upfronthosting.co.za> Message-ID: <1396305971.13.0.104428337268.issue7676@psf.upfronthosting.co.za> Westley Mart?nez added the comment: I think the prompt should be in margins, completely separate from the input. It is just meant to be a guide anyway, and make this would make it easy to copy code from the interactive shell to a file. I think output should be in a separate window or frame altogether. I see no reason for keeping it tied with the input. ---------- nosy: +westley.martinez _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 01:08:53 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 31 Mar 2014 23:08:53 +0000 Subject: [issue16716] Deprecate OSError aliases in the doc In-Reply-To: <1355861242.44.0.0203808398116.issue16716@psf.upfronthosting.co.za> Message-ID: <3fyTr446gyz7LjT@mail.python.org> Roundup Robot added the comment: New changeset 7b219429c404 by Andrew Svetlov in branch '3.4': #16716: remove deprecation warning http://hg.python.org/cpython/rev/7b219429c404 New changeset 1c6c2ec8916a by Andrew Svetlov in branch 'default': #16716: remove deprecation warning http://hg.python.org/cpython/rev/1c6c2ec8916a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 01:09:06 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Mon, 31 Mar 2014 23:09:06 +0000 Subject: [issue21118] str.translate is absurdly slow in majority of use cases (takes 3x to 10x longer than similar functions) Message-ID: <1396307346.31.0.221715925478.issue21118@psf.upfronthosting.co.za> New submission from Josh Rosenberg: String translation functions, at least in other languages, are typically a performance optimization when you *really* need the speed. In exchange for paying the memory cost and one-time work to create a translation table, you get much faster 1 to 1 and deletion of characters. In Python 3, str.translate is usually a performance pessimization, not optimization. While it does a few things similar functions (e.g. str.replace) can't do, like perform a translation where the inputs and outputs overlap ('abc' -> 'bca' wouldn't work with str.replace), and it handles the full Unicode range ('\u0f01\u0f02' -> '\u0f03\u0f04' can't be done by encoding, using bytes.translate, then decoding again), when another approach is available, str.translate is almost always the slowest. While it may not be practical to make the general case for str.translate match the performance of bytes.translate, it should at least be possible to improve upon it in many common cases. My timing data (see attached file for how it was produced): $ python.exe translate_timing.py Testing 1-1 translation bytes.translate 0.05638575777521804 str.translate 2.9639258423152874 str.translate from bytes trans 1.6307581351818357 str.encode->bytes.translate->bytes.decode 0.09472254504689914 str.replace 0.2507745649580393 Testing deletion bytes.translate 0.05367317344084199 str.translate 2.360142494240577 str.encode->bytes.translate->bytes.decode 0.0629345277274993 str.replace 0.31173443413690904 Testing enlarging translations str.translate 2.33631417640283 str.replace 0.41248187325160757 Obviously, this is somewhat contrived, but it illustrates my point that the common case (ASCII or latin-1 strings) are far too slow. In every case, str.translate loses to every competitor, including itself when you pass it a translation table produced by bytes.translate, and including the case where a pure Python function calls str.replace over and over. A large part of the problem is clearly the use of a dict to perform lookups; as seen in the 1-1 test case, str.translate using the result of str.maketrans takes nearly twice as long as when it uses the result of a similar bytes.maketrans. While I have not profiled the code, I suspect the remainder is a combination of the overhead involving conversion of Py_UCS4 to PyLong for general purpose lookup, handling the multiple ways the translation target can be expressed (a Unicode ordinal or a str object), and the code that checks for and resizes the output buffer each time. I have ideas for a solution involving a special purpose translation object to be produced by str.maketrans for cases where the translation table will produce an equal or smaller string (all to values are None or length 1 or lower strings), and the from values all fall in a small enough range (say, 1024) to avoid excessive memory usage from large translation table objects. But I'd like to know whether such a change (including modifying the behavior of str.maketrans to produce an unspecified mapping object, instead of the current dict) is desired, acceptable, what have you. ---------- components: Unicode files: translate_timing.py messages: 215283 nosy: ezio.melotti, haypo, josh.rosenberg priority: normal severity: normal status: open title: str.translate is absurdly slow in majority of use cases (takes 3x to 10x longer than similar functions) type: performance versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file34688/translate_timing.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 01:09:47 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 31 Mar 2014 23:09:47 +0000 Subject: [issue21118] str.translate is absurdly slow in majority of use cases (takes 3x to 10x longer than similar functions) In-Reply-To: <1396307346.31.0.221715925478.issue21118@psf.upfronthosting.co.za> Message-ID: <1396307387.67.0.519338978853.issue21118@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 01:10:56 2014 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 31 Mar 2014 23:10:56 +0000 Subject: [issue16716] Deprecate OSError aliases in the doc In-Reply-To: <3fyTr446gyz7LjT@mail.python.org> Message-ID: Andrew Svetlov added the comment: The "deprecated markup" is removed. Sorry. Thanks to quick report. On Tue, Apr 1, 2014 at 2:08 AM, Roundup Robot wrote: > > Roundup Robot added the comment: > > New changeset 7b219429c404 by Andrew Svetlov in branch '3.4': > #16716: remove deprecation warning > http://hg.python.org/cpython/rev/7b219429c404 > > New changeset 1c6c2ec8916a by Andrew Svetlov in branch 'default': > #16716: remove deprecation warning > http://hg.python.org/cpython/rev/1c6c2ec8916a > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 01:17:05 2014 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 31 Mar 2014 23:17:05 +0000 Subject: [issue16716] Deprecate OSError aliases in the doc In-Reply-To: <1355861242.44.0.0203808398116.issue16716@psf.upfronthosting.co.za> Message-ID: <1396307825.82.0.307669753918.issue16716@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Close the issue again after fixing Antoine's objection. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 01:32:32 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Mon, 31 Mar 2014 23:32:32 +0000 Subject: [issue21118] str.translate is absurdly slow in majority of use cases (takes up to 60x longer than similar functions) In-Reply-To: <1396307346.31.0.221715925478.issue21118@psf.upfronthosting.co.za> Message-ID: <1396308752.47.0.417793911214.issue21118@psf.upfronthosting.co.za> Changes by Josh Rosenberg : ---------- title: str.translate is absurdly slow in majority of use cases (takes 3x to 10x longer than similar functions) -> str.translate is absurdly slow in majority of use cases (takes up to 60x longer than similar functions) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 01:38:33 2014 From: report at bugs.python.org (Julian Mehnle) Date: Mon, 31 Mar 2014 23:38:33 +0000 Subject: [issue8271] str.decode('utf8', 'replace') -- conformance with Unicode 5.2.0 In-Reply-To: <1270002492.52.0.790856673013.issue8271@psf.upfronthosting.co.za> Message-ID: <1396309113.98.0.822528044305.issue8271@psf.upfronthosting.co.za> Changes by Julian Mehnle : ---------- nosy: +jmehnle _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 02:01:43 2014 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 01 Apr 2014 00:01:43 +0000 Subject: [issue21117] inspect: PartialSignature and PartialParameter classes In-Reply-To: <1396297836.4.0.601810070188.issue21117@psf.upfronthosting.co.za> Message-ID: <1396310503.87.0.0172810366683.issue21117@psf.upfronthosting.co.za> Yury Selivanov added the comment: @Nick: Agreed on positional-only stuff. > If arguments bound by position disappear from the signature, and those > bound by keyword are mapped to keyword-only parameters with a default, we > should get a valid and accurate signature. But what about my example from the first message: def foo(a, b): pass foo_partial = functools.partial(foo, 'spam') 'foo_partial' now has the following signature: (a='spam', b); where 'a' is a positional_or_keyword parameter, i.e. you can still do 'foo_partial(10, 20)', or 'foo_partial(b=20, a=10)'. (a='spam', b) is not a valid python pure function signature, but is a perfectly valid signature of partial function. And since its arguments aren't positional-only, we shouldn't hide anything. That's why I have this private '_partial_kwarg' attribute, which I don't like and want to remove by adding a PartialParameter subclass. Otherwise, we have something that is hidden and non-documented, but affects Parameter.__hash__ and some other logic. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 02:36:08 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 01 Apr 2014 00:36:08 +0000 Subject: [issue17390] display python version on idle title bar In-Reply-To: <1362920194.83.0.464215113749.issue17390@psf.upfronthosting.co.za> Message-ID: <1396312568.84.0.572973699705.issue17390@psf.upfronthosting.co.za> Terry J. Reedy added the comment: As far as I can tell, there are 4 window classes to be concerned with. (Dialogs would be a separate issue.) EditorWindow |- PyShellEditorWindow - EW+breakpoints, replaces WE in PyShellFileList |- OutputWindow - used by Find in Files |- PyShell - the visible shell window PyShellEditorWindow does not override the title methods and is of no concern to us. If we want the title for all these windows to start with 'Python', we should 'factor' that out and start with it at the beginning of EditorWindow.saved_change_hook (and change other things in EW). Thinking ahead, another possible use for OutputWindow is for containing the result of running an external program on a file. I think that a leading 'Python' would be fine something like Python: PyFlakes output for OutputWindow.py Adding the flexibility of a title parameter to OutputWindow instead of EditorWindow seems about right. If we do that, the override of .short_title for PyShell in the first patch should be removed and the title passed in to the one and only call that creates a PyShell (PyShell.py, 315). I would like to add some minimal automated tests (maybe in a new test_misc.py file) using either mock classes or unittest.mock (which I have not used yet). ---------- stage: needs patch -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 02:53:26 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 01 Apr 2014 00:53:26 +0000 Subject: [issue20578] BufferedIOBase.readinto1 is missing In-Reply-To: <1391991229.05.0.363628736117.issue20578@psf.upfronthosting.co.za> Message-ID: <1396313606.05.0.749790929523.issue20578@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 03:04:04 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 01 Apr 2014 01:04:04 +0000 Subject: [issue7676] IDLE shell shouldn't use TABs In-Reply-To: <1263213381.47.0.181451927584.issue7676@psf.upfronthosting.co.za> Message-ID: <1396314244.56.0.985560996456.issue7676@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > IDLE defaults to indenting with 4 spaces in editor windows, > but hard TABs in the Python Shell window. This is inconsistent > with PEP 8; what's worse, it's makes copy-paste code between > the shell and editor windows confusing and dangerous! I also teach Python and find this to be a major PITA. A Cntl-T turns tabs off but leaves the tab spacing at eight. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 03:18:06 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 01 Apr 2014 01:18:06 +0000 Subject: [issue7676] IDLE shell shouldn't use TABs In-Reply-To: <1263213381.47.0.181451927584.issue7676@psf.upfronthosting.co.za> Message-ID: <1396315086.03.0.176378074806.issue7676@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Continuing my last post ... Fix 4 is to put prompts in a narrow window to the left of and kept in synch with the main shell input/output window. This is the approach used by Heblikar in #17535. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 03:30:37 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 01 Apr 2014 01:30:37 +0000 Subject: [issue12387] IDLE save keyboard shortcut problem In-Reply-To: <1308765598.77.0.79184481064.issue12387@psf.upfronthosting.co.za> Message-ID: <1396315837.15.0.942774226884.issue12387@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- versions: +Python 3.4, Python 3.5 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 03:53:16 2014 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 01 Apr 2014 01:53:16 +0000 Subject: [issue21117] inspect: PartialSignature and PartialParameter classes In-Reply-To: <1396297836.4.0.601810070188.issue21117@psf.upfronthosting.co.za> Message-ID: <1396317196.78.0.416514369444.issue21117@psf.upfronthosting.co.za> Yury Selivanov added the comment: @Nick: oh, it took me some time to realize that your suggestion to transform positional-or-keyword to keyword-only parameters is correct. If we do this, we no longer need '_partial_kwarg' hack. I'll work on the patch. Thank you. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 05:04:44 2014 From: report at bugs.python.org (Lars Andersson) Date: Tue, 01 Apr 2014 03:04:44 +0000 Subject: [issue21119] asyncio create_connection resource warning Message-ID: <1396321484.68.0.174945090803.issue21119@psf.upfronthosting.co.za> New submission from Lars Andersson: The attached code generates an unclosed socket ResourceWarning when timing out trying to connect to an unreachable address. Probably not terribly serious, but in my case, it generates distracting warnings during unit testing. I have looked briefly at the asyncio code but it's not immediately obvious to me how to fix it. ---------- components: Library (Lib) files: timeout.py messages: 215291 nosy: landersson priority: normal severity: normal status: open title: asyncio create_connection resource warning type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file34689/timeout.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 05:16:45 2014 From: report at bugs.python.org (Zachary Ware) Date: Tue, 01 Apr 2014 03:16:45 +0000 Subject: [issue19501] Buildbot testing of 3.2 broken In-Reply-To: <1383625464.91.0.832501203458.issue19501@psf.upfronthosting.co.za> Message-ID: <1396322205.42.0.318949853673.issue19501@psf.upfronthosting.co.za> Zachary Ware added the comment: With the demise of the 3.2 buildbot configuration, closing this issue. ---------- resolution: -> out of date stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 05:25:38 2014 From: report at bugs.python.org (paul j3) Date: Tue, 01 Apr 2014 03:25:38 +0000 Subject: [issue14156] argparse.FileType for '-' doesn't work for a mode of 'rb' In-Reply-To: <1330513271.31.0.437438851478.issue14156@psf.upfronthosting.co.za> Message-ID: <1396322738.42.0.986594943728.issue14156@psf.upfronthosting.co.za> Changes by paul j3 : ---------- nosy: +paul.j3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 05:34:43 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Tue, 01 Apr 2014 03:34:43 +0000 Subject: [issue20995] Use Better Default Ciphers for the SSL Module In-Reply-To: <1395324676.75.0.303580402974.issue20995@psf.upfronthosting.co.za> Message-ID: <1396323283.45.0.631719898403.issue20995@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 05:37:50 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Tue, 01 Apr 2014 03:37:50 +0000 Subject: [issue20996] Backport TLS 1.1 and 1.2 support for ssl_version In-Reply-To: <1395325005.18.0.706730120112.issue20996@psf.upfronthosting.co.za> Message-ID: <1396323470.0.0.894815309815.issue20996@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 06:19:11 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Tue, 01 Apr 2014 04:19:11 +0000 Subject: [issue21057] TextIOWrapper does not support reading bytearrays or memoryviews In-Reply-To: <1395720869.89.0.455515257207.issue21057@psf.upfronthosting.co.za> Message-ID: <1396325951.32.0.124139014868.issue21057@psf.upfronthosting.co.za> Nikolaus Rath added the comment: Thanks for the feedback! I have attached an updated patch. I did not include any testcase because the patch did not create any new code paths, so I was assuming it'd be covered by the existing test case. But of course I was wrong. In the revised patch, I added a testcase based on your example of a more complex memoryview. (Note, however, that even with the previous implementation using nbytes = PySequence_Size(input_chunk) this test does not fail, because nbytes is used only to estimate the size of the text string). ---------- Added file: http://bugs.python.org/file34690/issue21057.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 06:33:58 2014 From: report at bugs.python.org (Zachary Ware) Date: Tue, 01 Apr 2014 04:33:58 +0000 Subject: [issue19962] Create a 'python.bat' script to invoke interpreter from source root In-Reply-To: <1386862429.77.0.358851450829.issue19962@psf.upfronthosting.co.za> Message-ID: <1396326838.42.0.101998310854.issue19962@psf.upfronthosting.co.za> Zachary Ware added the comment: This appears to work correctly for PGO builds and x64 builds. Does anyone have any objections to this, or suggestions for improvement? ---------- versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 07:38:29 2014 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 01 Apr 2014 05:38:29 +0000 Subject: [issue21117] inspect.signature: inaccuracies for partial functions In-Reply-To: <1396297836.4.0.601810070188.issue21117@psf.upfronthosting.co.za> Message-ID: <1396330709.94.0.79456526935.issue21117@psf.upfronthosting.co.za> Nick Coghlan added the comment: I believe Yury already figured out what I meant, but to make it entirely clear, after the change, this example: def foo(a, b): pass foo_partial = functools.partial(foo, 'spam') foo_partial2 = functools.partial(foo, a='spam') Should lead to the following signature for both "foo_partial" and "foo_partial2": (b, *, a='spam') That accurately indicates that "a" is now effectively a keyword only parameter - the first supplied positional argument will map to "b", and attempting to supply *two* positional arguments will fail. Correctly handing *args may get a little interesting, but should be feasible. ---------- stage: -> needs patch title: inspect: PartialSignature and PartialParameter classes -> inspect.signature: inaccuracies for partial functions type: enhancement -> behavior versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 09:03:42 2014 From: report at bugs.python.org (=?utf-8?b?TcOpZMOpcmljIEJvcXVpZW4=?=) Date: Tue, 01 Apr 2014 07:03:42 +0000 Subject: [issue21116] Failure to create multiprocessing shared arrays larger than 50% of memory size under linux In-Reply-To: <1396294667.97.0.287941619482.issue21116@psf.upfronthosting.co.za> Message-ID: <1396335822.77.0.525837734343.issue21116@psf.upfronthosting.co.za> M?d?ric Boquien added the comment: I have now signed the contributor's agreement. As for the unit test I was looking at it. However, I was wondering how to write a test that would have triggered the problem. It only shows up for very large arrays and it depends on occupied memory and the configuration of the temp dir. Or should I simply write a test creating for instance a 100 MB array and checking it has the right length? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 09:19:49 2014 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 01 Apr 2014 07:19:49 +0000 Subject: [issue21111] PyLong_AsUnsignedLongAndOverflow does not exist In-Reply-To: <1396272396.7.0.644063349125.issue21111@psf.upfronthosting.co.za> Message-ID: <1396336789.41.0.397592472319.issue21111@psf.upfronthosting.co.za> Mark Dickinson added the comment: Sounds reasonable to me. Were there particular uses you needed this for? And do you want to work on a patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 09:36:51 2014 From: report at bugs.python.org (paul j3) Date: Tue, 01 Apr 2014 07:36:51 +0000 Subject: [issue13824] argparse.FileType opens a file and never closes it In-Reply-To: <1326975939.94.0.524131708506.issue13824@psf.upfronthosting.co.za> Message-ID: <1396337811.53.0.995154993809.issue13824@psf.upfronthosting.co.za> paul j3 added the comment: >From http://bugs.python.org/issue14156 "argparse.FileType for '-' doesn't work for a mode of 'rb'" I learned that 'stdin/out' can be embedded in an 'open' by using the 'fileno()' and 'closefd=False' (so it isn't closed at the end of open). With this, the dummy file context that I implemented in the previous patch, could be replaced with: partial(open, sys.stdin.fileno(), mode=self._mode,..., closefd=False) However, as Steven Bethard wrote in the earlier issue, setting up tests when stdin/out will be redirected is not a trivial problem. So I don't yet have a testable patch. --------------- And just for the record, the 'osaccess' testing that I wrote earlier, probably should also test that proposed output file string is not already a directory. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 09:43:00 2014 From: report at bugs.python.org (paul j3) Date: Tue, 01 Apr 2014 07:43:00 +0000 Subject: [issue14156] argparse.FileType for '-' doesn't work for a mode of 'rb' In-Reply-To: <1330513271.31.0.437438851478.issue14156@psf.upfronthosting.co.za> Message-ID: <1396338180.22.0.57519345114.issue14156@psf.upfronthosting.co.za> paul j3 added the comment: A related issue http://bugs.python.org/issue13824 "argparse.FileType opens a file and never closes it" I proposed a FileContext class that returns a `partial(open, filename,...)' context object. The issues of how to deal with stdin/out are similar. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 10:10:21 2014 From: report at bugs.python.org (Andrey) Date: Tue, 01 Apr 2014 08:10:21 +0000 Subject: [issue21120] PyArena type is used in headers from the limited API Message-ID: <1396339821.73.0.473299529971.issue21120@psf.upfronthosting.co.za> New submission from Andrey: Hi all, The PyArena data type is defined in the pyarena.h under the #ifndef Py_LIMITED_API statement, so it's not included in the limited api. But this type is used in Python-ast.h, ast.h and asdl.h headers that included in the limited api, because they don't contain any checks for Py_LIMITED_API. May be all these header files (Python-ast.h, ast.h, asdl.h) should begin with "#ifndef Py_LIMITED_API" (excluded from the limited api)? Thanks. ---------- components: Library (Lib) messages: 215300 nosy: aponomarenko priority: normal severity: normal status: open title: PyArena type is used in headers from the limited API type: compile error versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 10:23:37 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 01 Apr 2014 08:23:37 +0000 Subject: [issue21118] str.translate is absurdly slow in majority of use cases (takes up to 60x longer than similar functions) In-Reply-To: <1396307346.31.0.221715925478.issue21118@psf.upfronthosting.co.za> Message-ID: <1396340617.89.0.519156771668.issue21118@psf.upfronthosting.co.za> STINNER Victor added the comment: str.translate() currently allocates a buffer of UCS4 characters. translate_writer.patch: - modify _PyUnicode_TranslateCharmap() to use the _PyUnicodeWriter API - drop optimizations for error handlers different than "ignore" because there is no unit tests for them, and str.translate() uses "ignore". It's safer to drop untested optimization. - cleanup also the code: charmaptranslate_output() is now responsible to handle charmaptranslate_lookup() result (to decrement the reference coutner) str.translate() may be a little bit faster when translating ASCII to ASCII for large string, but not so much. bytes.translate() is much faster because it builds a C array of 256 items to fast table lookup, whereas str.translate() requires a Python dict lookup for each character, which is much slower. codecs.charmap_build() (PyUnicode_BuildEncodingMap()) creates a C array ("a three-level trie") for fast lookup. It is used with codecs.charmap_encode() for 8-bit encodings. We may reuse it for simple cases, like translating ASCII to ASCII. ---------- keywords: +patch Added file: http://bugs.python.org/file34691/translate_writer.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 10:55:29 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 01 Apr 2014 08:55:29 +0000 Subject: [issue21118] str.translate is absurdly slow in majority of use cases (takes up to 60x longer than similar functions) In-Reply-To: <1396307346.31.0.221715925478.issue21118@psf.upfronthosting.co.za> Message-ID: <1396342529.59.0.327476441062.issue21118@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 11:00:01 2014 From: report at bugs.python.org (dellair jie) Date: Tue, 01 Apr 2014 09:00:01 +0000 Subject: [issue21085] compile error Python3.3 on Cygwin In-Reply-To: <1396019829.85.0.386935527155.issue21085@psf.upfronthosting.co.za> Message-ID: <1396342801.15.0.0703813395557.issue21085@psf.upfronthosting.co.za> dellair jie added the comment: Martin, Here is the values presented on Python 3.4.0, in fact they are the same as 3.3.2, please note the key difference. /* #undef HAVE_SIGTIMEDWAIT */ #define HAVE_SIGWAIT 1 #define HAVE_SIGWAITINFO 1 The SIGTIMEDWAIT is undef while the SIGWAIT is defined. The patch Victor found (https://github.com/Alexpux/MSYS2-packages/blob/master/python3/3.3.2-cygwin-siginfo.patch) to modify sigalmodule.c works on both 3.3.2 and 3.4 (at least the build went through the sign failure.) So shall we close this issue? Petrov, Thanks a loot! The patch you offered about parser works with 3.3.2 and 3.4. There is further issues with the build on Cygwin and I will raise it in a separate issue. Br, Dellair ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 11:08:47 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 01 Apr 2014 09:08:47 +0000 Subject: [issue21085] compile error Python3.3 on Cygwin In-Reply-To: <1396019829.85.0.386935527155.issue21085@psf.upfronthosting.co.za> Message-ID: <1396343327.89.0.425406004413.issue21085@psf.upfronthosting.co.za> STINNER Victor added the comment: > So shall we close this issue? Nope. Could you please try the test described in msg215249? We might integrate https://github.com/Alexpux/MSYS2-packages/blob/master/python3/3.3.2-cygwin-siginfo.patch but it would be better to fix sigwaitinfo() if it works without si_band. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 12:06:41 2014 From: report at bugs.python.org (Lotus Qin) Date: Tue, 01 Apr 2014 10:06:41 +0000 Subject: [issue21113] Error usage of class.__bases__ In-Reply-To: <1396276234.22.0.492654933854.issue21113@psf.upfronthosting.co.za> Message-ID: <1396346801.07.0.457374212161.issue21113@psf.upfronthosting.co.za> Lotus Qin added the comment: get the __doc__ in a wrong way, it works now. ---------- resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 12:42:13 2014 From: report at bugs.python.org (nils) Date: Tue, 01 Apr 2014 10:42:13 +0000 Subject: [issue21121] -Werror=declaration-after-statement is added even for extension modules through setup.py Message-ID: <1396348933.92.0.0275278232722.issue21121@psf.upfronthosting.co.za> New submission from nils: I got an error while rebuilding a module for 3.4. This was a ISO C90 error but setup.py explicitely adds "-std=c99" to the gcc parameters, and indeed it is used. fifo.h:114:5: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement] uint32_t ofs = fifo->write_count - fifo->write_offset; However, Py 3.4 seems to add -Werror=declaration-after-statement also for extension modules. This should not happe (said also Yhg1s in #python). Attached is a file that shows the setup.py and also the error log. ---------- components: Build, Distutils, Extension Modules files: pybug.txt messages: 215305 nosy: dstufft, eric.araujo, nilsge priority: normal severity: normal status: open title: -Werror=declaration-after-statement is added even for extension modules through setup.py versions: Python 3.4 Added file: http://bugs.python.org/file34692/pybug.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 13:38:02 2014 From: report at bugs.python.org (Robert Kuska) Date: Tue, 01 Apr 2014 11:38:02 +0000 Subject: [issue1298835] Add a vendor-packages directory for system-supplied modules Message-ID: <1396352282.92.0.150817306328.issue1298835@psf.upfronthosting.co.za> Robert Kuska added the comment: Ok, I have started a thread at pypa-devs google group. https://groups.google.com/forum/#!topic/pypa-dev/r6qsAmJl9t0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 14:11:00 2014 From: report at bugs.python.org (Jonas Wagner) Date: Tue, 01 Apr 2014 12:11:00 +0000 Subject: [issue21122] CPython fails to build modules with LLVM LTO on Mac OS Message-ID: <1396354260.96.0.514432416417.issue21122@psf.upfronthosting.co.za> New submission from Jonas Wagner: CPython fails to build with LLVM's link-time optimization (LTO) in Mac OS. Very similar commands work on Linux. I'm currently configuring CPython as follows: on Linux: RANLIB="ar -s --plugin=/path/to/llvm/lib/LLVMgold.so" CC=/path/to/llvm/bin/clang CXX=/path/to/llvm/bin/clang++ CFLAGS="-g -flto" LDFLAGS="-flto" ./configure on Mac OS: CC=/path/to/llvm/bin/clang CXX=/path/to/llvm/bin/clang++ CFLAGS="-g -flto" LDFLAGS="-flto" ./configure The RANLIB variable should not be needed on Mac, because its toolchain does not need a GOLD plugin. On Linux, the above builds correctly and passes most of the test suite. On Mac, I receive the following error (similar for other extensions): building '_scproxy' extension /usr/bin/clang -Wno-unused-result -Werror=declaration-after-statement -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -g -flto -I../cpython/Include -I. -I/usr/local/include -I../cpython/Include -I../cpython-lto-build -c ../cpython/Modules/_scproxy.c -o build/temp.macosx-10.9-x86_64-3.5/path/to/cpython/Modules/_scproxy.o /usr/bin/clang -bundle -undefined dynamic_lookup -flto build/temp.macosx-10.9-x86_64-3.5/path/to/cpython/Modules/_scproxy.o -L/usr/local/lib -o build/lib.macosx-10.9-x86_64-3.5/_scproxy.so -framework SystemConfiguration -framework CoreFoundation *** WARNING: renaming "_scproxy" since importing it failed: dlopen(build/lib.macosx-10.9-x86_64-3.5/_scproxy.so, 2): Symbol not found: __Py_NoneStruct Referenced from: build/lib.macosx-10.9-x86_64-3.5/_scproxy.so Expected in: flat namespace in build/lib.macosx-10.9-x86_64-3.5/_scproxy.so ---------- components: Extension Modules messages: 215307 nosy: Sjlver priority: normal severity: normal status: open title: CPython fails to build modules with LLVM LTO on Mac OS type: compile error versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 14:13:34 2014 From: report at bugs.python.org (dellair jie) Date: Tue, 01 Apr 2014 12:13:34 +0000 Subject: [issue21085] compile error Python3.3 on Cygwin In-Reply-To: <1396019829.85.0.386935527155.issue21085@psf.upfronthosting.co.za> Message-ID: <1396354414.27.0.166265285124.issue21085@psf.upfronthosting.co.za> dellair jie added the comment: Victor, Would you please be more specific on test_signal? Br, Dellair ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 14:14:50 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 01 Apr 2014 12:14:50 +0000 Subject: [issue21122] CPython fails to build modules with LLVM LTO on Mac OS In-Reply-To: <1396354260.96.0.514432416417.issue21122@psf.upfronthosting.co.za> Message-ID: <1396354490.09.0.586814516222.issue21122@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 14:14:56 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 01 Apr 2014 12:14:56 +0000 Subject: [issue21122] CPython fails to build modules with LLVM LTO on Mac OS In-Reply-To: <1396354260.96.0.514432416417.issue21122@psf.upfronthosting.co.za> Message-ID: <1396354496.16.0.659919382081.issue21122@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +koobs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 14:28:05 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 01 Apr 2014 12:28:05 +0000 Subject: [issue21085] compile error Python3.3 on Cygwin In-Reply-To: <1396019829.85.0.386935527155.issue21085@psf.upfronthosting.co.za> Message-ID: <1396355285.24.0.125500700686.issue21085@psf.upfronthosting.co.za> STINNER Victor added the comment: > Would you please be more specific on test_signal? Please try to compile Python 3.4 with the attached cygwin_si_band.patch applied, and then run test_signal. I would like to know if all tests pass, and if not, which tests are failing. I also would like to know if test_sigwaitinfo() runs on Cygwin. I'm not sure that signal.alarm(1) is available on Windows, whereas test_sigwaitinfo() uses this function. Or you can test manually sigwaitinfo(). Example on Windows using SIGINT and CTRL+c to send a signal: >>> import signal >>> info = signal.sigwaitinfo({signal.SIGINT}) ^C >>> info signal.struct_siginfo(si_signo=2, si_code=128, si_errno=0, si_pid=0, si_uid=0, si_status=3, si_band=0) I don't know how to test sigwaitinfo() on Windows. ---------- keywords: +patch Added file: http://bugs.python.org/file34693/cygwin_si_band.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 15:12:27 2014 From: report at bugs.python.org (Dirkjan Ochtman) Date: Tue, 01 Apr 2014 13:12:27 +0000 Subject: [issue20767] Some python extensions can't be compiled with clang 3.4 In-Reply-To: <1393335198.15.0.97052317234.issue20767@psf.upfronthosting.co.za> Message-ID: <1396357947.33.0.420013114208.issue20767@psf.upfronthosting.co.za> Changes by Dirkjan Ochtman : ---------- nosy: +djc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 15:12:52 2014 From: report at bugs.python.org (Dirkjan Ochtman) Date: Tue, 01 Apr 2014 13:12:52 +0000 Subject: [issue20767] Some python extensions can't be compiled with clang 3.4 In-Reply-To: <1393335198.15.0.97052317234.issue20767@psf.upfronthosting.co.za> Message-ID: <1396357972.59.0.827102639713.issue20767@psf.upfronthosting.co.za> Dirkjan Ochtman added the comment: Can we have some more feedback on this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 15:16:15 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 01 Apr 2014 13:16:15 +0000 Subject: [issue21122] CPython fails to build modules with LLVM LTO on Mac OS In-Reply-To: <1396354260.96.0.514432416417.issue21122@psf.upfronthosting.co.za> Message-ID: <1396358175.12.0.675265430495.issue21122@psf.upfronthosting.co.za> STINNER Victor added the comment: What is your clang version? See also issue #20767. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 15:16:22 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 01 Apr 2014 13:16:22 +0000 Subject: [issue20767] Some python extensions can't be compiled with clang 3.4 In-Reply-To: <1393335198.15.0.97052317234.issue20767@psf.upfronthosting.co.za> Message-ID: <1396358182.11.0.247820687887.issue20767@psf.upfronthosting.co.za> STINNER Victor added the comment: See also issue #21122. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 15:16:58 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 01 Apr 2014 13:16:58 +0000 Subject: [issue21120] PyArena type is used in headers from the limited API In-Reply-To: <1396339821.73.0.473299529971.issue21120@psf.upfronthosting.co.za> Message-ID: <1396358218.33.0.361587724107.issue21120@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 15:18:11 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 01 Apr 2014 13:18:11 +0000 Subject: [issue21111] PyLong_AsUnsignedLongAndOverflow does not exist In-Reply-To: <1396272396.7.0.644063349125.issue21111@psf.upfronthosting.co.za> Message-ID: <1396358291.32.0.124181456379.issue21111@psf.upfronthosting.co.za> STINNER Victor added the comment: > Sounds reasonable to me. Were there particular uses you needed this for? And do you want to work on a patch? I don't understand why PyArg_Parse*() functions have formats for integers checking overflow for signed integers, but not for unsigned integers. For the zlib module, I had to develop my own format format (to get an unsigned int with overflow check) :-( ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 15:20:06 2014 From: report at bugs.python.org (Jonas Wagner) Date: Tue, 01 Apr 2014 13:20:06 +0000 Subject: [issue21122] CPython fails to build modules with LLVM LTO on Mac OS In-Reply-To: <1396354260.96.0.514432416417.issue21122@psf.upfronthosting.co.za> Message-ID: <1396358406.12.0.825908404532.issue21122@psf.upfronthosting.co.za> Jonas Wagner added the comment: I am indeed using Clang 3.4 (both the one that ships with Mac OS, and a version compiled from the sources). However, the errors I get are rather different than #20767. In particular, Clang finishes successfully and does produce shared object files; they just don't seem to be loadable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 15:29:58 2014 From: report at bugs.python.org (Dirkjan Ochtman) Date: Tue, 01 Apr 2014 13:29:58 +0000 Subject: [issue20767] Some python extensions can't be compiled with clang 3.4 In-Reply-To: <1393335198.15.0.97052317234.issue20767@psf.upfronthosting.co.za> Message-ID: <1396358998.01.0.801321996235.issue20767@psf.upfronthosting.co.za> Dirkjan Ochtman added the comment: That does look to be a different issue, though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 15:37:46 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 01 Apr 2014 13:37:46 +0000 Subject: [issue18644] Got ResourceWarning: unclosed file when using test function from formatter module In-Reply-To: <1375537519.43.0.405840418589.issue18644@psf.upfronthosting.co.za> Message-ID: <1396359466.31.0.620529966891.issue18644@psf.upfronthosting.co.za> R. David Murray added the comment: There were a bunch of changes to pydoc in 3.4, so I'm not surprised that it doesn't use DumbWriter any more (possibly as part of the formatter pending deprecation). I think I was answering why it wasn't deprecated as part of the htmllib deprecation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 15:59:25 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 01 Apr 2014 13:59:25 +0000 Subject: [issue21117] inspect.signature: inaccuracies for partial functions In-Reply-To: <1396297836.4.0.601810070188.issue21117@psf.upfronthosting.co.za> Message-ID: <1396360765.29.0.731173040518.issue21117@psf.upfronthosting.co.za> R. David Murray added the comment: OK, I didn't even realize that was possible with partial. Now I understand Yuri's original point. His example is wrong: >>> def foo(a, b): ... print(a, b) >>> x2 = partial(foo, 'x') >>> str(inspect.signature(x2)) '(b)' This is the correct example: >>> x = partial(foo, a='x') >>> x('b') Traceback (most recent call last): File "", line 1, in TypeError: foo() got multiple values for argument 'a' The current signature for this is the one Yuri gave: >>> str(inspect.signature(x)) "(a='x', b)" Which is about as close as one can come to the rather non-intuitve (non-pythonic?) behavior that partial has here. Perhaps this a bug in partial? If so it is unfortunately one with ugly backward compatibility implications. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 16:01:48 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 01 Apr 2014 14:01:48 +0000 Subject: [issue21121] -Werror=declaration-after-statement is added even for extension modules through setup.py In-Reply-To: <1396348933.92.0.0275278232722.issue21121@psf.upfronthosting.co.za> Message-ID: <1396360908.35.0.511682265451.issue21121@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: +larry priority: normal -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 16:02:37 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 01 Apr 2014 14:02:37 +0000 Subject: [issue21117] inspect.signature: inaccuracies for partial functions In-Reply-To: <1396297836.4.0.601810070188.issue21117@psf.upfronthosting.co.za> Message-ID: <1396360957.48.0.577714680557.issue21117@psf.upfronthosting.co.za> R. David Murray added the comment: By "didn't know that was possible", I mean binding a positional argument as a keyword argument in the partial. If nobody else thought that was possible, maybe can just fix it :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 16:23:56 2014 From: report at bugs.python.org (dellair jie) Date: Tue, 01 Apr 2014 14:23:56 +0000 Subject: [issue21085] compile error Python3.3 on Cygwin In-Reply-To: <1396019829.85.0.386935527155.issue21085@psf.upfronthosting.co.za> Message-ID: <1396362236.41.0.150284452513.issue21085@psf.upfronthosting.co.za> dellair jie added the comment: Victor, I suppose that Python needs to be built successfully before running test_signal. Three patches were applied in Python 3.4.0. However, the build failed to build _struct module. Should I open another Issue to track it? As long as the build goes through completely on Cygwin, I will go back and do the signal test. Br, Dellair ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 16:52:29 2014 From: report at bugs.python.org (dellair jie) Date: Tue, 01 Apr 2014 14:52:29 +0000 Subject: [issue21123] Compilation error on _struct module on Python 3.4 Message-ID: <1396363947.51.0.530971318271.issue21123@psf.upfronthosting.co.za> New submission from dellair jie: Dear all, I am compiling Python 3.4 on Cygwin 1.7.17. The following has been done in order to reach the point where _struct module failed. > A clean Python 3.4 > Applied patches: cygwin_si_band.patch in Issue21085 0001-CYGWIN-issue13756-Python-make-fail-on-cygwin.patch in issue13756 0019-MINGW-export-_PyNode_SizeOf-as-PyAPI-for-parser-modu.patch in issue186373 > configure + make The issue happened during make: building '_struct' extension gcc -Wno-unused-result -Werror=declaration-after-statement -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I./Include -I. -IInclude -I/cygdrive/c/temp/Python-3.4.0/Include -I/cygdrive/c/temp/Python-3.4.0 -c /cygdrive/c/temp/Python-3.4.0/Modules/_struct.c -o build/temp.cygwin-1.7.17-i686-3.4/cygdrive/c/temp/Python-3.4.0/Modules/_struct.o /cygdrive/c/temp/Python-3.4.0/Modules/_struct.c:1630:5: error: initializer element is not constant /cygdrive/c/temp/Python-3.4.0/Modules/_struct.c:1630:5: error: (near initialization for ?unpackiter_type.ob_base.ob_base.ob_type?) Please feel free to find the build.log and the output of _struct.c.txt (gcc with -dD -E -DPy_BUILD_core) for more information. Thanks in advance, Br, Dellair ---------- files: _struct.c.txt messages: 215320 nosy: dellair.jie priority: normal severity: normal status: open title: Compilation error on _struct module on Python 3.4 versions: Python 3.4 Added file: http://bugs.python.org/file34694/_struct.c.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 16:52:48 2014 From: report at bugs.python.org (dellair jie) Date: Tue, 01 Apr 2014 14:52:48 +0000 Subject: [issue21124] Compilation error on _struct module on Python 3.4 Message-ID: <1396363951.96.0.324613047949.issue21124@psf.upfronthosting.co.za> New submission from dellair jie: Dear all, I am compiling Python 3.4 on Cygwin 1.7.17. The following has been done in order to reach the point where _struct module failed. > A clean Python 3.4 > Applied patches: cygwin_si_band.patch in Issue21085 0001-CYGWIN-issue13756-Python-make-fail-on-cygwin.patch in issue13756 0019-MINGW-export-_PyNode_SizeOf-as-PyAPI-for-parser-modu.patch in issue186373 > configure + make The issue happened during make: building '_struct' extension gcc -Wno-unused-result -Werror=declaration-after-statement -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I./Include -I. -IInclude -I/cygdrive/c/temp/Python-3.4.0/Include -I/cygdrive/c/temp/Python-3.4.0 -c /cygdrive/c/temp/Python-3.4.0/Modules/_struct.c -o build/temp.cygwin-1.7.17-i686-3.4/cygdrive/c/temp/Python-3.4.0/Modules/_struct.o /cygdrive/c/temp/Python-3.4.0/Modules/_struct.c:1630:5: error: initializer element is not constant /cygdrive/c/temp/Python-3.4.0/Modules/_struct.c:1630:5: error: (near initialization for ?unpackiter_type.ob_base.ob_base.ob_type?) Please feel free to find the build.log and the output of _struct.c.txt (gcc with -dD -E -DPy_BUILD_core) for more information. Thanks in advance, Br, Dellair ---------- files: _struct.c.txt messages: 215321 nosy: dellair.jie priority: normal severity: normal status: open title: Compilation error on _struct module on Python 3.4 versions: Python 3.4 Added file: http://bugs.python.org/file34695/_struct.c.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 16:53:31 2014 From: report at bugs.python.org (dellair jie) Date: Tue, 01 Apr 2014 14:53:31 +0000 Subject: [issue21124] Compilation error on _struct module on Python 3.4 In-Reply-To: <1396363951.96.0.324613047949.issue21124@psf.upfronthosting.co.za> Message-ID: <1396364011.06.0.757117395079.issue21124@psf.upfronthosting.co.za> dellair jie added the comment: The full build log ---------- Added file: http://bugs.python.org/file34696/Build.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 17:14:32 2014 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 01 Apr 2014 15:14:32 +0000 Subject: [issue21117] inspect.signature: inaccuracies for partial functions In-Reply-To: <1396297836.4.0.601810070188.issue21117@psf.upfronthosting.co.za> Message-ID: <1396365272.84.0.0777403290447.issue21117@psf.upfronthosting.co.za> Yury Selivanov added the comment: @Nick: Ouch... I'm halfway through the implementation, and it seems like your idea isn't going to work. Example (from unittest): def foo(a=1, b=2, c=3): pass _foo = partial(foo, a=10, c=13) Now, the signature for "_foo", with your logic applied, will be: (b=2, *, a=10, c=13) If, however, you try to do the following call: _foo(11) It will fail with a TypeError "got multiple values for argument 'a'", because 'partial' will actually do this call: foo(11, a=10, c=13) I now remember this obstacle, that's why I have '_partial_kwarg'. So unfortunately, why I really like your idea, I don't think we can make it work. Now, I still want to get rid the '_partial_kwarg' attribute. Are you guys OK, if I introduce PartialParameter & PartialSignature classes? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 17:16:04 2014 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 01 Apr 2014 15:16:04 +0000 Subject: [issue21117] inspect.signature: inaccuracies for partial functions In-Reply-To: <1396297836.4.0.601810070188.issue21117@psf.upfronthosting.co.za> Message-ID: <1396365364.59.0.388192725013.issue21117@psf.upfronthosting.co.za> Yury Selivanov added the comment: @R. David: Yes, thank you, David. Too bad I haven't seen your last messages before I started working on the patch... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 17:32:41 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 01 Apr 2014 15:32:41 +0000 Subject: [issue21117] inspect.signature: inaccuracies for partial functions In-Reply-To: <1396297836.4.0.601810070188.issue21117@psf.upfronthosting.co.za> Message-ID: <1396366361.89.0.745609595555.issue21117@psf.upfronthosting.co.za> R. David Murray added the comment: We'll have to wait for Nick to chime in, but I'll make a couple of comments. First, I think this is a bug in partial, so I think we need to decide what, if anything, to do about that first, before we decide if signature needs to compensate for it or not. The other comment is about ==/__hash__, in case that is involved in the solution: two objects may very well have the same __hash__ and *not* be equal, but they cannot have different __hash__es and *be* equal. The equality comparison algorithm uses __hash__ as a shortcut. If two objects have different hashes, they are not equal and we return False. If they have the same hash, then a full equality comparison is done before the result of __eq__ is returned. You will understand that this must be the case if you think about the nature of hashing: it throws away information. Cryptographic hashes used for identification are constructed such that the *probability* of a collision is very low, but it is still not zero, so how they are used is just as important as how they work. Our __hash__es are generally not that strong, so collision is likely. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 17:36:16 2014 From: report at bugs.python.org (Glenn Maynard) Date: Tue, 01 Apr 2014 15:36:16 +0000 Subject: [issue21125] traceback.extract_tb says "quadruple" when it means "tuple" Message-ID: <1396366576.76.0.132198557562.issue21125@psf.upfronthosting.co.za> New submission from Glenn Maynard: https://docs.python.org/2/library/traceback.html "A ?pre-processed? stack trace entry is a quadruple (filename, line number, function name, text) representing the information that is usually printed for a stack trace." There's no such thing as a "quadruple". This should be "tuple". ---------- assignee: docs at python components: Documentation messages: 215326 nosy: Glenn.Maynard, docs at python priority: normal severity: normal status: open title: traceback.extract_tb says "quadruple" when it means "tuple" _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 17:50:20 2014 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 01 Apr 2014 15:50:20 +0000 Subject: [issue21117] inspect.signature: inaccuracies for partial functions In-Reply-To: <1396297836.4.0.601810070188.issue21117@psf.upfronthosting.co.za> Message-ID: <1396367420.35.0.852885369118.issue21117@psf.upfronthosting.co.za> Yury Selivanov added the comment: > First, I think this is a bug in partial, so I think we need to decide what, if anything, to do about that first, before we decide if signature needs to compensate for it or not. Agree. Although, it looks like it's not something that partial is doing, it seems like this call logic is implemented somewhere way deeper. > The other comment is about ==/__hash__ [...] Agree. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 17:55:29 2014 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 01 Apr 2014 15:55:29 +0000 Subject: [issue21117] inspect.signature: inaccuracies for partial functions In-Reply-To: <1396297836.4.0.601810070188.issue21117@psf.upfronthosting.co.za> Message-ID: <1396367729.9.0.312070708265.issue21117@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Although, it looks like it's not something that partial is doing, it seems like this call logic is implemented somewhere way deeper. Forget about what I said. Yes, it's a "bug" in partial. Fixing it, will require having the code from "Signature.bind" reflected to C -- IOW you need to introspect the callable, get information about its parameters, and then compute the actual args & kwargs. Which will make functools.partial much much slower. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 17:58:35 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 01 Apr 2014 15:58:35 +0000 Subject: [issue21117] inspect.signature: inaccuracies for partial functions In-Reply-To: <1396297836.4.0.601810070188.issue21117@psf.upfronthosting.co.za> Message-ID: <1396367915.94.0.56061652158.issue21117@psf.upfronthosting.co.za> R. David Murray added the comment: Oh, the error message comes from deep in the guts of python, yes. I'm saying that the fact that partial lets you write partial(foo, a='bar') when a is a positional argument is a bug. Even if other people agree with me (and they may not, "consenting adults" and all that), it may be a bug we are stuck with. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 18:02:28 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 01 Apr 2014 16:02:28 +0000 Subject: [issue21125] traceback.extract_tb says "quadruple" when it means "tuple" In-Reply-To: <1396366576.76.0.132198557562.issue21125@psf.upfronthosting.co.za> Message-ID: <1396368148.28.0.800262190439.issue21125@psf.upfronthosting.co.za> R. David Murray added the comment: A google for quadruple got me wikipedia as the first hit, with this as the match text: "Quadruple may refer to: A 4-tuple, ..." So, it's tech-speak. The alternative would be to say either "a 4-tuple" or "a tuple of four elements". I'm fine with someone making that change, but I don't think it is terrible that the word is used the way it is. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 18:27:10 2014 From: report at bugs.python.org (dellair jie) Date: Tue, 01 Apr 2014 16:27:10 +0000 Subject: [issue21123] Compilation error on _struct module on Python 3.4 In-Reply-To: <1396363947.51.0.530971318271.issue21123@psf.upfronthosting.co.za> Message-ID: <1396369630.4.0.0656938624477.issue21123@psf.upfronthosting.co.za> dellair jie added the comment: Duplicated with Issue21124 ---------- resolution: -> duplicate status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 18:54:09 2014 From: report at bugs.python.org (Giampaolo Rodola') Date: Tue, 01 Apr 2014 16:54:09 +0000 Subject: [issue21076] Turn signal.SIG* constants into enums In-Reply-To: <1395935330.94.0.38028035584.issue21076@psf.upfronthosting.co.za> Message-ID: <1396371249.66.0.0323651805571.issue21076@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: If there are no other concerns I will commit latest patch tomorrow, then do the renaming. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 19:23:02 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 01 Apr 2014 17:23:02 +0000 Subject: [issue15067] Clean up the sqlite3 docs In-Reply-To: <1339687148.5.0.0456329910944.issue15067@psf.upfronthosting.co.za> Message-ID: <3fyy6Y3VNyz7LjT@mail.python.org> Roundup Robot added the comment: New changeset 2e13f0d49b8e by Zachary Ware in branch '2.7': Issue #15067: Remove reference to a rejected PEP. http://hg.python.org/cpython/rev/2e13f0d49b8e New changeset 4a2dabac976d by Zachary Ware in branch '3.4': Issue #15067: Port 2.7 sqlite3 docs to 3.4 http://hg.python.org/cpython/rev/4a2dabac976d New changeset 2c7ebb930b64 by Zachary Ware in branch 'default': Closes #15067: Merge port of 2.7 sqlite3 docs. http://hg.python.org/cpython/rev/2c7ebb930b64 ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 19:33:01 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Tue, 01 Apr 2014 17:33:01 +0000 Subject: [issue19546] configparser leaks implementation detail In-Reply-To: <1384103812.47.0.904880324738.issue19546@psf.upfronthosting.co.za> Message-ID: <1396373581.67.0.972684284984.issue19546@psf.upfronthosting.co.za> Claudiu.Popa added the comment: But the last traceback conveys enough information, the user can see immediately that the given section does not exist. My problem with the current behaviour is that the first error distracts the user, while the actual problem is the second traceback. But I have another example which might contradict my proposal. In the example in the second traceback, it's not clear what `Bad value substitution` stands for and the first traceback adds the relevant context (the fact that key is missing). But I guess this stands for another issue, for enhancing the message for InterpolationMissingOptionError to transmit the fact that a given option is missing. Traceback (most recent call last): File "C:\Python34\lib\configparser.py", line 410, in _interpolate_some v = map[var] File "C:\Python34\lib\collections\__init__.py", line 789, in __getitem__ return self.__missing__(key) # support subclasses that define __missing__ File "C:\Python34\lib\collections\__init__.py", line 781, in __missing__ raise KeyError(key) KeyError: 'home_dir1' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "", line 1, in File "C:\Python34\lib\configparser.py", line 1204, in __getitem__ return self._parser.get(self._name, key) File "C:\Python34\lib\configparser.py", line 773, in get d) File "C:\Python34\lib\configparser.py", line 374, in before_get self._interpolate_some(parser, option, L, value, section, defaults, 1) File "C:\Python34\lib\configparser.py", line 413, in _interpolate_some option, section, rest, var) configparser.InterpolationMissingOptionError: Bad value substitution: section: [Paths] option : my_dir key : home_dir1 rawval : /lumberjack ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 20:05:04 2014 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 01 Apr 2014 18:05:04 +0000 Subject: [issue21111] PyLong_AsUnsignedLongAndOverflow does not exist In-Reply-To: <1396272396.7.0.644063349125.issue21111@psf.upfronthosting.co.za> Message-ID: <1396375504.44.0.706208212886.issue21111@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- components: +Interpreter Core -Extension Modules stage: -> needs patch type: -> enhancement versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 20:12:24 2014 From: report at bugs.python.org (Giampaolo Rodola') Date: Tue, 01 Apr 2014 18:12:24 +0000 Subject: [issue21126] Integrate doctest.run_docstring_examples() with unittest Message-ID: <1396375944.72.0.495252715824.issue21126@psf.upfronthosting.co.za> New submission from Giampaolo Rodola': In order to run a certain function via doctest run_docstring_examples() can be used: http://stackoverflow.com/a/10081450/376587 The function returns None though. I am in a situation where I want to run a single function's doctest from a unittest and want to "fail" in case the doctest fails. Patch in attachment makes run_docstring_examples() return a list of TestResults instances so that you can do: class TestFoo(unittest.TestCase): def test_foo(self): ret = doctest.run_docstring_examples(somefun, globals()) self.assertFalse(ret[0].failed) Patch lacks tests because run_docstring_examples() is currently not tested. I will open a separate ticket for that. ---------- files: doctest.patch keywords: patch messages: 215335 nosy: giampaolo.rodola, tim.peters priority: normal severity: normal status: open title: Integrate doctest.run_docstring_examples() with unittest versions: Python 3.5 Added file: http://bugs.python.org/file34697/doctest.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 20:15:52 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 01 Apr 2014 18:15:52 +0000 Subject: [issue19546] configparser leaks implementation detail In-Reply-To: <1384103812.47.0.904880324738.issue19546@psf.upfronthosting.co.za> Message-ID: <1396376152.72.0.291270675632.issue19546@psf.upfronthosting.co.za> R. David Murray added the comment: Why? Just let the context convey the information. It's not like we are building a UI here, this is for the programmer. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 20:19:01 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 01 Apr 2014 18:19:01 +0000 Subject: [issue19546] configparser leaks implementation detail In-Reply-To: <1384103812.47.0.904880324738.issue19546@psf.upfronthosting.co.za> Message-ID: <1396376341.64.0.824098708661.issue19546@psf.upfronthosting.co.za> R. David Murray added the comment: Although I will grant you that I have to guess at what the bad value substitution error message is trying to tell me, so that error message could use some improvement. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 21:56:48 2014 From: report at bugs.python.org (michael kearney) Date: Tue, 01 Apr 2014 19:56:48 +0000 Subject: [issue17846] Building Python on Windows - Supplementary info In-Reply-To: <1366919664.94.0.0931557904055.issue17846@psf.upfronthosting.co.za> Message-ID: <1396382208.16.0.202548465225.issue17846@psf.upfronthosting.co.za> michael kearney added the comment: Observation: Tools\buildbot\build.bat solves all the problems I was having. That is to say, a single command exists to build python on windows w/o problems. It has worked since at least since python 3.3.1, which I think preceded my original submission. So this has existed all this time, but has not been suggested as the solution it seems to be. What's wrong with it? Is it about to be deprecated perhaps? The DevGuide recommends external.bat in the same directory. build.bat calls external.bat and does more. Detail: If I 1. place the unzipped downloaded file folder isolated within another folder so that external projects can be built adjacent to python. 2. make certain that svn,nasm,VC++, are in my path. 3. cd to the python root 4. execute the command : Tools\buildbot\build.bat Then python_d.exe is created in the PCbuild folder. This is true for python 3.3.1, 3.3.2, 3.3.4, 3.4.0, and the current development version. I have built all since yesterday. I skipped 3.3.3 only because I didn't have the source downloaded OK, I lied a little. 1. The 3.3.1 release python.org areas had a corrupt openSSL rev d, I think. I modified my local external.bat to get a later version to solve that problem. 2. Other releases build debug tcltk release libs when debug libs are needed, and vice versa. I made copies of whatever existed and renamed the copy to whatever was required. But this is nothing compared what I was going through before. I personally like to have python.exe around also. To create python.exe, I only now open pcbuild.sln to start VC++, chose the release configuration, and hit F7. I have learned that it is best to run build.bat first before using pcbuild.sln with the VC++ IDE to build anything. It currently does not work for AMD64 but I maguessing that ti would be a good model to follow. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 23:20:24 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Tue, 01 Apr 2014 21:20:24 +0000 Subject: [issue21118] str.translate is absurdly slow in majority of use cases (takes up to 60x longer than similar functions) In-Reply-To: <1396307346.31.0.221715925478.issue21118@psf.upfronthosting.co.za> Message-ID: <1396387224.66.0.703493950061.issue21118@psf.upfronthosting.co.za> Josh Rosenberg added the comment: @haypo: Are you planning to run with this then? Or shall I pick up where your patch leaves off? Thanks for the pointer to the codecs charmap_build; it's not documented anywhere that I can tell, so I didn't even know it existed. Now to dig into the source to figure out what it does and how to use it (both in C and Python). I know about the fundamental design differences that makes bytes.translate kick str.translate's butt; my plan to make a special purpose mapping-like object that didn't require C layer code to wrap up Py_UCS4 in PyLong, or pull Py_UCS4 out of PyUnicode/PyLong objects was largely to try and get a bytes.translate like implementation, but if codecs.charmap_build()/PyUnicode_BuildEncodingMap() can get me 90% of the way there without reinventing the wheel, it's clearly worth looking at. Again, let me know if it's okay if I try to finish off the work you began, or if you'd prefer to do it yourself. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 23:34:48 2014 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 01 Apr 2014 21:34:48 +0000 Subject: [issue21117] inspect.signature: inaccuracies for partial functions In-Reply-To: <1396297836.4.0.601810070188.issue21117@psf.upfronthosting.co.za> Message-ID: <1396388088.66.0.109590825634.issue21117@psf.upfronthosting.co.za> Nick Coghlan added the comment: Huh, that actually sounds like a possible design flaw in the core argument binding semantics. I'll have to think about that one some more. In the meantime, as far as this issue goes, I'm inclined to say that signature should throw an exception to be clear that such a malformed object has *no* usable signature, as attempting to call it will always fail. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 1 23:36:22 2014 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 01 Apr 2014 21:36:22 +0000 Subject: [issue21117] inspect.signature: inaccuracies for partial functions In-Reply-To: <1396297836.4.0.601810070188.issue21117@psf.upfronthosting.co.za> Message-ID: <1396388182.9.0.616852199754.issue21117@psf.upfronthosting.co.za> Nick Coghlan added the comment: Oh, wait, it *does* have a usable signature. It's just that all the *subsequent* positional-or-keyword parameters also have to be marked as keyword-only. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 00:08:28 2014 From: report at bugs.python.org (Antony Lee) Date: Tue, 01 Apr 2014 22:08:28 +0000 Subject: [issue21127] Path objects cannot be constructed from str subclasses Message-ID: <1396390108.81.0.285327356985.issue21127@psf.upfronthosting.co.za> New submission from Antony Lee: Trying to construct a Path object from a str subclass, e.g. class S(str): pass Path(S("foo")) fails because the subclass cannot be interned. I think that the interning should simply be removed for non-exactly-str arguments (it is only here for performance reasons, right?), or at least the error should be more explicit (note, in particular, that there is no error if one tries 'Path(S("foo/bar"))' instead, which only confuses the matter more). In practice, I found out this via numpy, which provides its own str subclass, numpy.str_. ---------- components: Library (Lib) messages: 215342 nosy: Antony.Lee priority: normal severity: normal status: open title: Path objects cannot be constructed from str subclasses versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 00:22:57 2014 From: report at bugs.python.org (mattip) Date: Tue, 01 Apr 2014 22:22:57 +0000 Subject: [issue21128] testing stdlib and compatibility with pypy Message-ID: <1396390977.66.0.122853817502.issue21128@psf.upfronthosting.co.za> New submission from mattip: In continuation of issue 20887, this patch closes and removes all temp files created while running regression tests for stdlib 2.7.6 on win32 and pypy. Note that a gc.collect was required to release the closed files in test_argparse, as well as making them all rw. ---------- components: Tests files: patch messages: 215343 nosy: mattip priority: normal severity: normal status: open title: testing stdlib and compatibility with pypy type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file34698/patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 00:33:52 2014 From: report at bugs.python.org (Ned Deily) Date: Tue, 01 Apr 2014 22:33:52 +0000 Subject: [issue21122] CPython fails to build modules with LLVM LTO on Mac OS X In-Reply-To: <1396354260.96.0.514432416417.issue21122@psf.upfronthosting.co.za> Message-ID: <1396391632.16.0.846087381392.issue21122@psf.upfronthosting.co.za> Ned Deily added the comment: Just as an experiment (using the 3.4 branch and the Xcode 5.1 clang), the list of unique symbols not found during the test dlopen in setup.py when using -flto: _PyArg_ParseTuple _PyArg_ParseTupleAndKeywords _PyBaseObject_Type _PyBool_Type _PyByteArray_Type _PyBytes_Type _PyCFunction_Type _PyExc_AssertionError _PyExc_BufferError _PyExc_EOFError _PyExc_IndexError _PyExc_IOError _PyExc_KeyError _PyExc_LookupError _PyExc_MemoryError _PyExc_NotImplementedError _PyExc_OSError _PyExc_OverflowError _PyExc_RuntimeError _PyExc_TypeError _PyExc_ValueError _PyModule_Create2 __Py_NoneStruct Anyone see a pattern there? Do we know if anyone has tried to use LTO with a Python build previously? I've never tried it myself and there certainly could be ld and/or dyld differences on OS X. Also, some thought would need to go into and tests developed to see what the performance trade-offs are. For example, I could imagine that LTO might be have more impact if the standard library extension modules were statically linked, e.g. via Modules/Setup*. And there are at least three separate current build configurations to consider on OS X: unshared, --enable-shared, --enable-framework. One would need to look at things like what effect these all have on memory and shared memory footprints as well as cpu resources and real time, with and without LTO and/or other optimizations. It certainly would be an interesting project for someone with the interest and time. Potentially supporting LTO seems to me to be more of a feature than a bug so I think should be considered a 3.5 issue, at least initially. ---------- components: +Build -Extension Modules nosy: +brett.cannon, ned.deily, ronaldoussoren title: CPython fails to build modules with LLVM LTO on Mac OS -> CPython fails to build modules with LLVM LTO on Mac OS X type: compile error -> versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 01:22:27 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 01 Apr 2014 23:22:27 +0000 Subject: [issue21082] os.makedirs(exist_ok=True) is not thread-safe: umask is set temporary to 0, serious security problem In-Reply-To: <1395990246.32.0.278092008539.issue21082@psf.upfronthosting.co.za> Message-ID: <3fz65G2Rmxz7LjQ@mail.python.org> Roundup Robot added the comment: New changeset 9186f4a18584 by Benjamin Peterson in branch '3.2': remove directory mode check from makedirs (closes #21082) http://hg.python.org/cpython/rev/9186f4a18584 New changeset 6370d44013f7 by Benjamin Peterson in branch '3.3': merge 3.2 (#21082) http://hg.python.org/cpython/rev/6370d44013f7 New changeset c24dd53ab4b9 by Benjamin Peterson in branch '3.4': merge 3.3 (#21082) http://hg.python.org/cpython/rev/c24dd53ab4b9 New changeset adfcdc831e98 by Benjamin Peterson in branch 'default': merge 3.4 (#21082) http://hg.python.org/cpython/rev/adfcdc831e98 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 01:23:44 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 01 Apr 2014 23:23:44 +0000 Subject: [issue21082] os.makedirs(exist_ok=True) is not thread-safe: umask is set temporary to 0, serious security problem In-Reply-To: <1395990246.32.0.278092008539.issue21082@psf.upfronthosting.co.za> Message-ID: <1396394624.75.0.48665925301.issue21082@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I've now removed the offending behavior. exist_ok is still racy because it uses path.isdir() in the exceptional case, but fixing that can be an enhancement elsewhere. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 02:02:19 2014 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 02 Apr 2014 00:02:19 +0000 Subject: [issue21117] inspect.signature: inaccuracies for partial functions In-Reply-To: <1396297836.4.0.601810070188.issue21117@psf.upfronthosting.co.za> Message-ID: <1396396939.79.0.883776533554.issue21117@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Oh, wait, it *does* have a usable signature. It's just that all the *subsequent* positional-or-keyword parameters also have to be marked as keyword-only. Interesting idea. I'll incorporate this logic into the patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 03:01:51 2014 From: report at bugs.python.org (Ned Deily) Date: Wed, 02 Apr 2014 01:01:51 +0000 Subject: [issue21121] -Werror=declaration-after-statement is added even for extension modules through setup.py In-Reply-To: <1396348933.92.0.0275278232722.issue21121@psf.upfronthosting.co.za> Message-ID: <1396400511.22.0.476305514865.issue21121@psf.upfronthosting.co.za> Ned Deily added the comment: It looks like -Werror=declaration-after-statement was added to BASECFLAGS in configure.ac during the 3.4 development cycle by a3559c8c614b and e47806951fb2. Unfortunately, BASECFLAGS propagates through to extension module builds as well. If -Werror=declaration-after-statement should only be restricted to the build of the interpreter executable itself, one option *might be* to move the test and definition to CFLAGSFORSHARED in configure.ac. A workaround could be to define CFLAGS before rebuilding a module: export CFLAGS=$(python3.4 -c 'import sysconfig; print(sysconfig.get_config_var("CFLAGS").replace("-Werror=declaration-after-statement",""))') (As usual, my brain hurts after trying to sift through the myriad build flags and their interactions in configure.ac, Makefile, and setup.py.) ---------- nosy: +benjamin.peterson, ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 03:23:30 2014 From: report at bugs.python.org (Ned Deily) Date: Wed, 02 Apr 2014 01:23:30 +0000 Subject: [issue21124] _struct module compilation error under Cygwin 1.7.17 on Python 3.4 In-Reply-To: <1396363951.96.0.324613047949.issue21124@psf.upfronthosting.co.za> Message-ID: <1396401810.3.0.077756535556.issue21124@psf.upfronthosting.co.za> Ned Deily added the comment: This looks like a duplicate of Issue6672. ---------- components: +Build nosy: +ned.deily resolution: -> duplicate stage: -> committed/rejected status: open -> pending superseder: -> Add Mingw recognition to pyport.h to allow building extensions title: Compilation error on _struct module on Python 3.4 -> _struct module compilation error under Cygwin 1.7.17 on Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 03:26:41 2014 From: report at bugs.python.org (Ned Deily) Date: Wed, 02 Apr 2014 01:26:41 +0000 Subject: [issue21127] Path objects cannot be constructed from str subclasses In-Reply-To: <1396390108.81.0.285327356985.issue21127@psf.upfronthosting.co.za> Message-ID: <1396402001.86.0.195571389377.issue21127@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 03:31:42 2014 From: report at bugs.python.org (Ned Deily) Date: Wed, 02 Apr 2014 01:31:42 +0000 Subject: [issue21128] testing stdlib and compatibility with pypy In-Reply-To: <1396390977.66.0.122853817502.issue21128@psf.upfronthosting.co.za> Message-ID: <1396402302.15.0.732822626746.issue21128@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- keywords: +patch nosy: +serhiy.storchaka stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 04:25:10 2014 From: report at bugs.python.org (nils) Date: Wed, 02 Apr 2014 02:25:10 +0000 Subject: [issue21121] -Werror=declaration-after-statement is added even for extension modules through setup.py In-Reply-To: <1396348933.92.0.0275278232722.issue21121@psf.upfronthosting.co.za> Message-ID: <1396405510.45.0.67102675691.issue21121@psf.upfronthosting.co.za> nils added the comment: The workaround indeed works. At least I can work now until this gets officialy fixed. Thanks! export CFLAGS=$(python3.4 -c 'import sysconfig; print(sysconfig.get_config_var("CFLAGS").replace("-Werror=declaration-after-statement",""))') ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 05:07:21 2014 From: report at bugs.python.org (Mayank Gupta) Date: Wed, 02 Apr 2014 03:07:21 +0000 Subject: [issue21129] Segfault in python interpreter Message-ID: <1396408041.53.0.971896348675.issue21129@psf.upfronthosting.co.za> New submission from Mayank Gupta: If I open the python interpreter: $ python Then type def to_hex(i): result = hex(i)[2:] My interpreter segfaults (EXC_BAD_ACCESS). Here's a backtrace from lldb: (lldb) bt * thread #1: tid = 0x152e7f, 0x00000001002eff97 readline.so`call_readline + 647, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0) * frame #0: 0x00000001002eff97 readline.so`call_readline + 647 frame #1: 0x0000000100008852 Python`PyOS_Readline + 274 frame #2: 0x000000010000a0a8 Python`tok_nextc + 104 frame #3: 0x000000010000a853 Python`PyTokenizer_Get + 147 frame #4: 0x000000010000544a Python`parsetok + 218 frame #5: 0x00000001000e7722 Python`PyParser_ASTFromFile + 146 frame #6: 0x00000001000e8983 Python`PyRun_InteractiveOneFlags + 243 frame #7: 0x00000001000e8c6e Python`PyRun_InteractiveLoopFlags + 78 frame #8: 0x00000001000e9451 Python`PyRun_AnyFileExFlags + 161 frame #9: 0x00000001000ffc9f Python`Py_Main + 2111 frame #10: 0x0000000100000f14 Python I am using cpython 2.7.3. ---------- components: Interpreter Core messages: 215351 nosy: mayank priority: normal severity: normal status: open title: Segfault in python interpreter type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 05:19:47 2014 From: report at bugs.python.org (Zachary Ware) Date: Wed, 02 Apr 2014 03:19:47 +0000 Subject: [issue21129] Segfault in python interpreter In-Reply-To: <1396408041.53.0.971896348675.issue21129@psf.upfronthosting.co.za> Message-ID: <1396408787.64.0.539417593123.issue21129@psf.upfronthosting.co.za> Zachary Ware added the comment: If you're using OS X 10.9+, you'll need to upgrade your Python installation. See #18458. ---------- nosy: +zach.ware resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> interactive interpreter crashes and test_readline fails on OS X 10.9 Mavericks due to libedit update _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 06:07:26 2014 From: report at bugs.python.org (Eric Snow) Date: Wed, 02 Apr 2014 04:07:26 +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: <1396411646.14.0.00358439045796.issue4712@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +eric.snow versions: +Python 3.5 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 07:07:33 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 02 Apr 2014 05:07:33 +0000 Subject: [issue21125] traceback.extract_tb says "quadruple" when it means "tuple" In-Reply-To: <1396366576.76.0.132198557562.issue21125@psf.upfronthosting.co.za> Message-ID: <1396415253.51.0.242171628735.issue21125@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I'll make the change to 4-tuple. ---------- assignee: docs at python -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 07:11:44 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 02 Apr 2014 05:11:44 +0000 Subject: [issue21125] traceback.extract_tb says "quadruple" when it means "tuple" In-Reply-To: <1396366576.76.0.132198557562.issue21125@psf.upfronthosting.co.za> Message-ID: <3fzFrH3ZZDz7Lk7@mail.python.org> Roundup Robot added the comment: New changeset 1c112eb4eb56 by Raymond Hettinger in branch '2.7': Issue 21125: minor wording tweak. http://hg.python.org/cpython/rev/1c112eb4eb56 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 07:18:13 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 02 Apr 2014 05:18:13 +0000 Subject: [issue21125] traceback.extract_tb says "quadruple" when it means "tuple" In-Reply-To: <1396366576.76.0.132198557562.issue21125@psf.upfronthosting.co.za> Message-ID: <3fzFzm5qVnz7LjW@mail.python.org> Roundup Robot added the comment: New changeset dfa399e74fcf by Raymond Hettinger in branch '3.4': Issue 21125: minor documentation tweak. http://hg.python.org/cpython/rev/dfa399e74fcf ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 07:19:10 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 02 Apr 2014 05:19:10 +0000 Subject: [issue21125] traceback.extract_tb says "quadruple" when it means "tuple" In-Reply-To: <1396366576.76.0.132198557562.issue21125@psf.upfronthosting.co.za> Message-ID: <1396415950.91.0.316796789439.issue21125@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Thanks for the bug report, Glenn. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 07:31:55 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 02 Apr 2014 05:31:55 +0000 Subject: [issue20968] mock.MagicMock does not mock __truediv__ In-Reply-To: <1395152014.45.0.112877741.issue20968@psf.upfronthosting.co.za> Message-ID: <1396416715.16.0.975468436266.issue20968@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The patch looks clean and correct. It passes the test suite. I recommend going ahead and applying the patch. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 07:35:47 2014 From: report at bugs.python.org (Joshua Bronson) Date: Wed, 02 Apr 2014 05:35:47 +0000 Subject: [issue18652] Add itertools.first_true (return first true item in iterable) In-Reply-To: <1375610934.97.0.503658757825.issue18652@psf.upfronthosting.co.za> Message-ID: <1396416947.94.0.98164504454.issue18652@psf.upfronthosting.co.za> Changes by Joshua Bronson : ---------- nosy: +jab _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 08:02:00 2014 From: report at bugs.python.org (Stefan Behnel) Date: Wed, 02 Apr 2014 06:02:00 +0000 Subject: [issue21028] ElementTree objects should support all the same methods as Element objects In-Reply-To: <1396295386.41.0.633466181565.issue21028@psf.upfronthosting.co.za> Message-ID: <533BA7D6.3030805@behnel.de> Stefan Behnel added the comment: > Add all the element methods to the elementtree object. Ok, but why? An ElementTree object *is not* an Element. It's a representation of a document that *has* a root Element. It makes sense for a document to allow searches over its content, and the ElementTree class currently supports that, using the find*() or iter() methods. They are "deep" or "global" content accessor shortcuts, in addition to the path through the normal getroot() method. But I can't see how making ElementTree objects look and behave like their own root Element improves anything. Instead, it would just make the distinction between the two completely unclear, and would also lead to quirks like the question why iterating over a document yields the second level of children. Or the question what the "attrib" property of a document could mean. Instead of blurring it, would you have an idea what we could improve in the documentation to make this distinction clearer? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 08:51:24 2014 From: report at bugs.python.org (dellair jie) Date: Wed, 02 Apr 2014 06:51:24 +0000 Subject: [issue21124] _struct module compilation error under Cygwin 1.7.17 on Python 3.4 In-Reply-To: <1396363951.96.0.324613047949.issue21124@psf.upfronthosting.co.za> Message-ID: <1396421484.65.0.482246093434.issue21124@psf.upfronthosting.co.za> dellair jie added the comment: Neil, It doesn't look like a duplicate of Issue6672. The one in Issue6672 was for Mingw, all the patches simply added __MINGW32__ to __CYGWIN__ build structure. While my issue is, the build failed with _struct.c on Cygwin. So the module is recognized, just didn't pass the compilation. Br, Dellair ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 09:22:19 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 02 Apr 2014 07:22:19 +0000 Subject: [issue21028] ElementTree objects should support all the same methods as Element objects In-Reply-To: <1395528476.17.0.859396205804.issue21028@psf.upfronthosting.co.za> Message-ID: <1396423339.1.0.402906866219.issue21028@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > ElementTree class currently supports that, > using the find*() or iter() methods. That would be great except that ElementTree doesn't actually have an __iter__ method. > Ok, but why? The short answer is that every time I conduct Python training, people routinely trip over this issue. The whole point of the ElementTree package was to have a more pythonic interface than DOM or SAX. I'm sure there are people that argue that the requests module isn't great because it conflates requesting with authentication and password management, but the beauty of requests is that its API matches how people try to use it. The outer ElementTree object is awkward in this regard. I don't see any benefit from having this code fail: from xml.etree.ElementTree import parse catalog = parse('books.xml') for book in catalog: print book.get('id') ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 09:45:49 2014 From: report at bugs.python.org (Stefan Behnel) Date: Wed, 02 Apr 2014 07:45:49 +0000 Subject: [issue21028] ElementTree objects should support all the same methods as Element objects In-Reply-To: <1396423339.1.0.402906866219.issue21028@psf.upfronthosting.co.za> Message-ID: <533BC02C.5080704@behnel.de> Stefan Behnel added the comment: > I don't see any benefit from having this code fail: > > from xml.etree.ElementTree import parse > > catalog = parse('books.xml') > for book in catalog: > print book.get('id') Why would you expect it to work? And how? Why would it only iterate over the *children* of the root Element that it wraps, and not yield the root Element itself, and maybe any preceding or following processing instructions or comments, the doctype declaration, etc.? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 09:55:52 2014 From: report at bugs.python.org (Jonas Wagner) Date: Wed, 02 Apr 2014 07:55:52 +0000 Subject: [issue21122] CPython fails to build modules with LLVM LTO on Mac OS X In-Reply-To: <1396354260.96.0.514432416417.issue21122@psf.upfronthosting.co.za> Message-ID: <1396425352.62.0.612890900335.issue21122@psf.upfronthosting.co.za> Jonas Wagner added the comment: Thanks Ned, this is interesting! I don't know about Mac OS, but on Ubuntu, LTO and PGO apparently make Python around 10% faster (see #17781). However, that data point refers to GCC's LTO, not LLVM's. Personally I'm interested in LTO because I want to obtain whole-program LLVM bitcode files (for use in a research project about instrumentation). However, if there is something I can help (e.g., running benchmarks with different compilation settings), let me know. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 09:57:52 2014 From: report at bugs.python.org (Thomas Heller) Date: Wed, 02 Apr 2014 07:57:52 +0000 Subject: [issue21130] equivalent functools.partial instances should compare equal Message-ID: <1396425472.15.0.80240218298.issue21130@psf.upfronthosting.co.za> New submission from Thomas Heller: I think that 'equivalent' functools.partial objects should compare equal, so the following snippet SHOULD print True: >>> import functools >>> f = lambda x: x >>> a = functools.partial(f, 42) >>> b = functools.partial(f, 42) >>> a == b False >>> ---------- components: Library (Lib) messages: 215363 nosy: theller priority: normal severity: normal status: open title: equivalent functools.partial instances should compare equal type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 11:14:40 2014 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 02 Apr 2014 09:14:40 +0000 Subject: [issue21122] CPython fails to build modules with LLVM LTO on Mac OS X In-Reply-To: <1396354260.96.0.514432416417.issue21122@psf.upfronthosting.co.za> Message-ID: <1396430080.15.0.925382968571.issue21122@psf.upfronthosting.co.za> Ronald Oussoren added the comment: I've used -O4 for extensions in the past (which until recently implied LTO) and that worked fine. I'm pretty sure that I haven't used LTO for python itself, apart from a some tests with an early version llvm-gcc where using LTO for building python used to crash the compiler :-) BTW. There's no clear pattern in the missing symbols. The missing symbols for global functions could be due to aggressive inlining (and then deciding that the standalone function isn't needed anymore), but that is fairly unlikely and wouldn't explain the missing data symbols. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 11:17:18 2014 From: report at bugs.python.org (Bohuslav "Slavek" Kabrda) Date: Wed, 02 Apr 2014 09:17:18 +0000 Subject: [issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10 Message-ID: <1396430238.51.0.283909097168.issue21131@psf.upfronthosting.co.za> New submission from Bohuslav "Slavek" Kabrda: test_faulthandler.test_register_chain fails on some 64bit architectures (arm8, ppc64) with kernel >= 3.10: ====================================================================== FAIL: test_register_chain (__main__.FaultHandlerTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/builddir/build/BUILD/Python-3.3.2/Lib/test/test_faulthandler.py", line 588, in test_register_chain self.check_register(chain=True) File "/builddir/build/BUILD/Python-3.3.2/Lib/test/test_faulthandler.py", line 572, in check_register self.assertEqual(exitcode, 0) AssertionError: -11 != 0 I created a minimal reproducer (reproduces the issue on 3.3, 3.4 and dev) of this segfault (attached). When run with GC assertions turned on, Python fails with: python: /builddir/build/BUILD/Python-3.3.2/Modules/gcmodule.c:332: update_refs: Assertion `gc->gc.gc_refs == (-3)\' failed. We experienced this issue when building Python 3.3 on Fedora's arm8 builder [1], it seems that opensuse have experienced the same failure on ppc64 [2] and ubuntu has a similar issue in their 64bit arm builds [3]. It seems that this may be caused by a change in kernel, since it's only reproducible on kernel >= 3.10. A nice explanation of what goes on and how the problem can be narrowed down is at the opensuse bug report [4], this is basically where I got stuck with this problem, too. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1045193 [2] https://bugzilla.novell.com/show_bug.cgi?id=831629 [3] https://bugs.launchpad.net/ubuntu/+source/python3.4/+bug/1264354 [4] https://bugzilla.novell.com/show_bug.cgi?id=831629#c15 ---------- components: Tests files: test_register_chain_segfault_reproducer.py messages: 215365 nosy: bkabrda priority: normal severity: normal status: open title: test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10 versions: Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file34699/test_register_chain_segfault_reproducer.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 11:19:16 2014 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 02 Apr 2014 09:19:16 +0000 Subject: [issue21122] CPython fails to build modules with LLVM LTO on Mac OS X In-Reply-To: <1396354260.96.0.514432416417.issue21122@psf.upfronthosting.co.za> Message-ID: <1396430356.31.0.839051508524.issue21122@psf.upfronthosting.co.za> Ronald Oussoren added the comment: Have you tried the -export_dynamic option for ld(1): -export_dynamic Preserves all global symbols in main executables during LTO. Without this option, Link Time Optimization is allowed to inline and remove global functions. This option is used when a main executable may load a plug-in which requires certain symbols from the main executable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 11:33:14 2014 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 02 Apr 2014 09:33:14 +0000 Subject: [issue21122] CPython fails to build modules with LLVM LTO on Mac OS X In-Reply-To: <1396354260.96.0.514432416417.issue21122@psf.upfronthosting.co.za> Message-ID: <1396431194.07.0.698460125969.issue21122@psf.upfronthosting.co.za> Ronald Oussoren added the comment: This works for me (with a separate build directory): CC=clang CXX=clang++ CFLAGS="-g -flto" LDFLAGS="-flto -Wl,-export_dynamic" ../configure This is on OSX 10.9.2, with Xcode 5.1, and clang --version says: $ clang --version Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn) Target: x86_64-apple-darwin13.1.0 Thread model: posix Tests are still running, but so far there are no unexpected failures. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 11:38:11 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 02 Apr 2014 09:38:11 +0000 Subject: [issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10 In-Reply-To: <1396430238.51.0.283909097168.issue21131@psf.upfronthosting.co.za> Message-ID: <1396431491.83.0.696450789768.issue21131@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 11:56:47 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 02 Apr 2014 09:56:47 +0000 Subject: [issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10 In-Reply-To: <1396430238.51.0.283909097168.issue21131@psf.upfronthosting.co.za> Message-ID: <1396432607.89.0.149445482326.issue21131@psf.upfronthosting.co.za> STINNER Victor added the comment: "test_faulthandler.test_register_chain fails on some 64bit architectures (arm8, ppc64) with kernel >= 3.10" I am a little bit surprised that the bug depends on the kernel version. Does test_register_chain_segfault_reproducer.py also crash with chain=False? Can you check if HAVE_SIGACTION is defined in pyconfig.h? Or in Python: import sysconfig; print(sysconfig.get_config_var('HAVE_SIGACTION')). Wit chain=True, faulthandler_register() registers its signal handler with SA_NODEFER flag: --- /* if the signal is received while the kernel is executing a system call, try to restart the system call instead of interrupting it and return EINTR. */ action.sa_flags = SA_RESTART; if (chain) { /* do not prevent the signal from being received from within its own signal handler */ action.sa_flags = SA_NODEFER; } --- With chain=True, the faulthandler_user() function calls the previous signal handler with: --- #ifdef HAVE_SIGACTION if (user->chain) { (void)sigaction(signum, &user->previous, NULL); errno = save_errno; /* call the previous signal handler */ raise(signum); save_errno = errno; (void)faulthandler_register(signum, user->chain, NULL); errno = save_errno; } #else if (user->chain) { errno = save_errno; /* call the previous signal handler */ user->previous(signum); } #endif --- You can try to add "#undef HAVE_SIGACTION" in faulthandler.c (after #include "Python.h") to see if the bug can be reproduced without sigaction. The code using signal() is very different, especially when chaining signal handlers. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 11:56:54 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 02 Apr 2014 09:56:54 +0000 Subject: [issue21130] equivalent functools.partial instances should compare equal In-Reply-To: <1396425472.15.0.80240218298.issue21130@psf.upfronthosting.co.za> Message-ID: <1396432614.69.0.24840832798.issue21130@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Even equivalent functions don't compare as equal: >>> (lambda x: x*x) == (lambda x: x*x) False ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 12:08:44 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 02 Apr 2014 10:08:44 +0000 Subject: [issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10 In-Reply-To: <1396430238.51.0.283909097168.issue21131@psf.upfronthosting.co.za> Message-ID: <1396433324.45.0.18614255406.issue21131@psf.upfronthosting.co.za> STINNER Victor added the comment: Would it be possible to list the kernel version (full version including the minor version) on which the test works or crash? You are talking about "3.10" without the minor version. It may be a regression in the kernel. Example of change in Linux kernel 3.10.17: --- commit 19a420033da02200c424adfa3a7b9eed6e3a6dc2 Author: Christian Ruppert Date: Wed Oct 2 11:13:38 2013 +0200 ARC: Fix signal frame management for SA_SIGINFO commit 10469350e345599dfef3fa78a7c19fb230e674c1 upstream. Previously, when a signal was registered with SA_SIGINFO, parameters 2 and 3 of the signal handler were written to registers r1 and r2 before the register set was saved. This led to corruption of these two registers after returning from the signal handler (the wrong values were restored). With this patch, registers are now saved before any parameters are passed, thus maintaining the processor state from before signal entry. Signed-off-by: Christian Ruppert Signed-off-by: Vineet Gupta Signed-off-by: Greg Kroah-Hartman --- Extract of changes of Linux 3.10.6: --- ARM: move signal handlers into a vdso-like page ARM: make vectors page inaccessible from userspace ARM: fix a cockup in 48be69a02 (ARM: move signal handlers into a vdso-like page) ARM: fix nommu builds with 48be69a02 (ARM: move signal handlers into a vdso-like page) --- Commit: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=48be69a02 I would like to make sure that the bug is not a kernel bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 12:14:11 2014 From: report at bugs.python.org (Bohuslav "Slavek" Kabrda) Date: Wed, 02 Apr 2014 10:14:11 +0000 Subject: [issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10 In-Reply-To: <1396430238.51.0.283909097168.issue21131@psf.upfronthosting.co.za> Message-ID: <1396433651.13.0.285644235146.issue21131@psf.upfronthosting.co.za> Bohuslav "Slavek" Kabrda added the comment: I'm also surprised that this depends on kernel version, however that's what I found out (and the opensuse guys seem to only have reproduced this on kernel >= 3.10, too). - Full kernel version (uname -r output): 3.13.0-0.rc7.28.sa2.aarch64 - The reproducer *doesn't* crash with chain=False. - HAVE_SIGACTION: >>> import sysconfig; print(sysconfig.get_config_var('HAVE_SIGACTION')) 1 - I'll do rebuild with "#undef HAVE_SIGACTION" and post my results here as soon as it's finished. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 12:17:41 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 02 Apr 2014 10:17:41 +0000 Subject: [issue18652] Add itertools.first_true (return first true item in iterable) In-Reply-To: <1375610934.97.0.503658757825.issue18652@psf.upfronthosting.co.za> Message-ID: <3fzNdJ4pp7z7Ljx@mail.python.org> Roundup Robot added the comment: New changeset 3e2354dde892 by Raymond Hettinger in branch '3.4': Issue #18652: Add an itertools recipe for first_true() http://hg.python.org/cpython/rev/3e2354dde892 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 12:24:00 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 02 Apr 2014 10:24:00 +0000 Subject: [issue18652] Add itertools.first_true (return first true item in iterable) In-Reply-To: <1375610934.97.0.503658757825.issue18652@psf.upfronthosting.co.za> Message-ID: <1396434240.26.0.942711658875.issue18652@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 12:31:35 2014 From: report at bugs.python.org (Bohuslav "Slavek" Kabrda) Date: Wed, 02 Apr 2014 10:31:35 +0000 Subject: [issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10 In-Reply-To: <1396430238.51.0.283909097168.issue21131@psf.upfronthosting.co.za> Message-ID: <1396434695.16.0.616406538106.issue21131@psf.upfronthosting.co.za> Bohuslav "Slavek" Kabrda added the comment: Ok, so with "#undef HAVE_SIGACTION" both the reproducer and the original test (as well as all tests in test_faulthandler) pass fine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 12:39:27 2014 From: report at bugs.python.org (Thomas Heller) Date: Wed, 02 Apr 2014 10:39:27 +0000 Subject: [issue21130] equivalent functools.partial instances should compare equal In-Reply-To: <1396425472.15.0.80240218298.issue21130@psf.upfronthosting.co.za> Message-ID: <1396435167.9.0.687709783103.issue21130@psf.upfronthosting.co.za> Thomas Heller added the comment: Sure. I'm not sure 'equivalent' is the word I should have used. I suggest (and I would have expected) that partial instances (a, b) should compare equal when a.func == b.func \ and a.args == b.args \ and a.keywords == b.keywords ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 13:39:07 2014 From: report at bugs.python.org (Sreepriya Chalakkal) Date: Wed, 02 Apr 2014 11:39:07 +0000 Subject: [issue19662] smtpd.py should not decode utf-8 In-Reply-To: <1384944703.82.0.967643613195.issue19662@psf.upfronthosting.co.za> Message-ID: <1396438747.61.0.962750284725.issue19662@psf.upfronthosting.co.za> Sreepriya Chalakkal added the comment: Hi David, The variable decode_data is included to control decoding. But I am not sure what needs to be done while calling the process_message inside found_terminator when it is binary data. How to work around with binary data? Can you tell me what are the data types concerning binary data? ---------- Added file: http://bugs.python.org/file34700/switch_while_decode1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 13:57:54 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 02 Apr 2014 11:57:54 +0000 Subject: [issue17846] Building Python on Windows - Supplementary info In-Reply-To: <1366919664.94.0.0931557904055.issue17846@psf.upfronthosting.co.za> Message-ID: <1396439874.6.0.466765211532.issue17846@psf.upfronthosting.co.za> Martin v. L?wis added the comment: The limitation of build.bat (as you also reported) is that it builds a debug build. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 14:11:24 2014 From: report at bugs.python.org (eryksun) Date: Wed, 02 Apr 2014 12:11:24 +0000 Subject: [issue21130] equivalent functools.partial instances should compare equal In-Reply-To: <1396425472.15.0.80240218298.issue21130@psf.upfronthosting.co.za> Message-ID: <1396440684.01.0.361321627606.issue21130@psf.upfronthosting.co.za> eryksun added the comment: Function equality is based on identity, as inherited from object. But there's a precedent for this idea in method_richcompare, which compares the method's __func__ and __self__: http://hg.python.org/cpython/file/04f714765c13/Objects/classobject.c#l208 ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 14:14:13 2014 From: report at bugs.python.org (David Woakes) Date: Wed, 02 Apr 2014 12:14:13 +0000 Subject: [issue21132] Failure to import win32api Message-ID: <1396440853.53.0.482865580463.issue21132@psf.upfronthosting.co.za> New submission from David Woakes: I've seen issue 21050 and tried a complete uninstall, delete c:\python34 and install of python 3.4. I can't get win32api to load unless I copy pythoncom34.dll and psywintypes34.dll to C:\Python34\Lib\site-packages\win32 from C:\Python34\Lib\site-packages\pywin32_system32. Here's output from a python -v session: >>> import win32api Traceback (most recent call last): File "", line 1, in File "", line 2214, in _find_and_load File "", line 2203, in _find_and_load_unlocked File "", line 1191, in _load_unlocked File "", line 1161, in _load_backward_compatible File "", line 539, in _check_name_wrapper File "", line 1692, in load_module File "", line 321, in _call_with_frames_removed ImportError: DLL load failed: The specified module could not be found. >>> import pdb; pdb.pm() # C:\Python34\lib\__pycache__\pdb.cpython-34.pyc matches C:\Python34\lib\pdb.py # code object from 'C:\\Python34\\lib\\__pycache__\\pdb.cpython-34.pyc' # C:\Python34\lib\__pycache__\re.cpython-34.pyc matches C:\Python34\lib\re.py # code object from 'C:\\Python34\\lib\\__pycache__\\re.cpython-34.pyc' # C:\Python34\lib\__pycache__\sre_compile.cpython-34.pyc matches C:\Python34\lib\sre_compile.py # code object from 'C:\\Python34\\lib\\__pycache__\\sre_compile.cpython-34.pyc' # C:\Python34\lib\__pycache__\sre_parse.cpython-34.pyc matches C:\Python34\lib\sre_parse.py # code object from 'C:\\Python34\\lib\\__pycache__\\sre_parse.cpython-34.pyc' # C:\Python34\lib\__pycache__\sre_constants.cpython-34.pyc matches C:\Python34\lib\sre_constants.py # code object from 'C:\\Python34\\lib\\__pycache__\\sre_constants.cpython-34.pyc' import 'sre_constants' # <_frozen_importlib.SourceFileLoader object at 0x02EB21B0> import 'sre_parse' # <_frozen_importlib.SourceFileLoader object at 0x02EAE4B0> import 'sre_compile' # <_frozen_importlib.SourceFileLoader object at 0x027D4BF0> # C:\Python34\lib\__pycache__\copyreg.cpython-34.pyc matches C:\Python34\lib\copyreg.py # code object from 'C:\\Python34\\lib\\__pycache__\\copyreg.cpython-34.pyc' import 'copyreg' # <_frozen_importlib.SourceFileLoader object at 0x02EB23B0> import 're' # <_frozen_importlib.SourceFileLoader object at 0x027D44D0> # C:\Python34\lib\__pycache__\cmd.cpython-34.pyc matches C:\Python34\lib\cmd.py # code object from 'C:\\Python34\\lib\\__pycache__\\cmd.cpython-34.pyc' # C:\Python34\lib\__pycache__\string.cpython-34.pyc matches C:\Python34\lib\string.py # code object from 'C:\\Python34\\lib\\__pycache__\\string.cpython-34.pyc' import 'string' # <_frozen_importlib.SourceFileLoader object at 0x02EB2CB0> import 'cmd' # <_frozen_importlib.SourceFileLoader object at 0x02EAEDF0> # C:\Python34\lib\__pycache__\bdb.cpython-34.pyc matches C:\Python34\lib\bdb.py # code object from 'C:\\Python34\\lib\\__pycache__\\bdb.cpython-34.pyc' # C:\Python34\lib\__pycache__\fnmatch.cpython-34.pyc matches C:\Python34\lib\fnmatch.py # code object from 'C:\\Python34\\lib\\__pycache__\\fnmatch.cpython-34.pyc' # C:\Python34\lib\__pycache__\posixpath.cpython-34.pyc matches C:\Python34\lib\posixpath.py # code object from 'C:\\Python34\\lib\\__pycache__\\posixpath.cpython-34.pyc' import 'posixpath' # <_frozen_importlib.SourceFileLoader object at 0x02EBBFD0> import 'fnmatch' # <_frozen_importlib.SourceFileLoader object at 0x02EBBD30> # C:\Python34\lib\__pycache__\inspect.cpython-34.pyc matches C:\Python34\lib\inspect.py # code object from 'C:\\Python34\\lib\\__pycache__\\inspect.cpython-34.pyc' # C:\Python34\lib\__pycache__\ast.cpython-34.pyc matches C:\Python34\lib\ast.py # code object from 'C:\\Python34\\lib\\__pycache__\\ast.cpython-34.pyc' import 'ast' # <_frozen_importlib.SourceFileLoader object at 0x02ED7D30> # C:\Python34\lib\importlib\__pycache__\__init__.cpython-34.pyc matches C:\Python34\lib\importlib\__init__.py # code object from 'C:\\Python34\\lib\\importlib\\__pycache__\\__init__.cpython-34.pyc' # C:\Python34\lib\__pycache__\warnings.cpython-34.pyc matches C:\Python34\lib\warnings.py # code object from 'C:\\Python34\\lib\\__pycache__\\warnings.cpython-34.pyc' import 'warnings' # <_frozen_importlib.SourceFileLoader object at 0x02EF94B0> import 'importlib' # <_frozen_importlib.SourceFileLoader object at 0x02EF92D0> # C:\Python34\lib\importlib\__pycache__\machinery.cpython-34.pyc matches C:\Python34\lib\importlib\machinery.py # code object from 'C:\\Python34\\lib\\importlib\\__pycache__\\machinery.cpython-34.pyc' import 'importlib.machinery' # <_frozen_importlib.SourceFileLoader object at 0x02EF9410> # C:\Python34\lib\__pycache__\linecache.cpython-34.pyc matches C:\Python34\lib\linecache.py # code object from 'C:\\Python34\\lib\\__pycache__\\linecache.cpython-34.pyc' # C:\Python34\lib\__pycache__\tokenize.cpython-34.pyc matches C:\Python34\lib\tokenize.py # code object from 'C:\\Python34\\lib\\__pycache__\\tokenize.cpython-34.pyc' # C:\Python34\lib\__pycache__\token.cpython-34.pyc matches C:\Python34\lib\token.py # code object from 'C:\\Python34\\lib\\__pycache__\\token.cpython-34.pyc' import 'token' # <_frozen_importlib.SourceFileLoader object at 0x02F066D0> import 'tokenize' # <_frozen_importlib.SourceFileLoader object at 0x02EF9C90> import 'linecache' # <_frozen_importlib.SourceFileLoader object at 0x02EF9B70> # C:\Python34\lib\__pycache__\dis.cpython-34.pyc matches C:\Python34\lib\dis.py # code object from 'C:\\Python34\\lib\\__pycache__\\dis.cpython-34.pyc' # C:\Python34\lib\__pycache__\opcode.cpython-34.pyc matches C:\Python34\lib\opcode.py # code object from 'C:\\Python34\\lib\\__pycache__\\opcode.cpython-34.pyc' import 'opcode' # <_frozen_importlib.SourceFileLoader object at 0x02F142B0> import 'dis' # <_frozen_importlib.SourceFileLoader object at 0x02F01090> import 'inspect' # <_frozen_importlib.SourceFileLoader object at 0x02EC8550> import 'bdb' # <_frozen_importlib.SourceFileLoader object at 0x02EB2C10> # C:\Python34\lib\__pycache__\code.cpython-34.pyc matches C:\Python34\lib\code.py # code object from 'C:\\Python34\\lib\\__pycache__\\code.cpython-34.pyc' # C:\Python34\lib\__pycache__\traceback.cpython-34.pyc matches C:\Python34\lib\traceback.py # code object from 'C:\\Python34\\lib\\__pycache__\\traceback.cpython-34.pyc' import 'traceback' # <_frozen_importlib.SourceFileLoader object at 0x02F2FF70> # C:\Python34\lib\__pycache__\codeop.cpython-34.pyc matches C:\Python34\lib\codeop.py # code object from 'C:\\Python34\\lib\\__pycache__\\codeop.cpython-34.pyc' # C:\Python34\lib\__pycache__\__future__.cpython-34.pyc matches C:\Python34\lib\__future__.py # code object from 'C:\\Python34\\lib\\__pycache__\\__future__.cpython-34.pyc' import '__future__' # <_frozen_importlib.SourceFileLoader object at 0x02F24770> import 'codeop' # <_frozen_importlib.SourceFileLoader object at 0x02F24450> import 'code' # <_frozen_importlib.SourceFileLoader object at 0x02F2FB70> # C:\Python34\lib\__pycache__\glob.cpython-34.pyc matches C:\Python34\lib\glob.py # code object from 'C:\\Python34\\lib\\__pycache__\\glob.cpython-34.pyc' import 'glob' # <_frozen_importlib.SourceFileLoader object at 0x02F24690> # C:\Python34\lib\__pycache__\pprint.cpython-34.pyc matches C:\Python34\lib\pprint.py # code object from 'C:\\Python34\\lib\\__pycache__\\pprint.cpython-34.pyc' import 'pprint' # <_frozen_importlib.SourceFileLoader object at 0x02F24B90> import 'pdb' # <_frozen_importlib.SourceFileLoader object at 0x027C44D0> > (321)_call_with_frames_removed() (Pdb) locals() {'args': ('win32api', 'C:\\Python34\\lib\\site-packages\\win32\\win32api.pyd'), 'kwds': {}, 'f': } (Pdb) q ---------- components: Interpreter Core messages: 215378 nosy: woakesd priority: normal severity: normal status: open title: Failure to import win32api versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 14:17:12 2014 From: report at bugs.python.org (Masayuki Yamamoto) Date: Wed, 02 Apr 2014 12:17:12 +0000 Subject: [issue21124] _struct module compilation error under Cygwin 1.7.17 on Python 3.4 In-Reply-To: <1396363951.96.0.324613047949.issue21124@psf.upfronthosting.co.za> Message-ID: <1396441032.21.0.13963538136.issue21124@psf.upfronthosting.co.za> Masayuki Yamamoto added the comment: I wrote a patch file. In other extention module source codes, global variable PyTypeObject has initialized to using "PyVarObject_HEAD_INIT(NULL, 0)". And so, as with other modules, I tried to edit and compiling _struct.c in Cygwin 1.7.28. The module compiling was passing, And struct module passed a test "python3.4 -m test test_struct". ---------- keywords: +patch nosy: +masamoto Added file: http://bugs.python.org/file34701/3.4-struct.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 14:21:40 2014 From: report at bugs.python.org (the mulhern) Date: Wed, 02 Apr 2014 12:21:40 +0000 Subject: [issue21133] unittest discover should allow option to run each package separately Message-ID: <1396441300.71.0.677176151152.issue21133@psf.upfronthosting.co.za> New submission from the mulhern: You can run "python -m unittest discover " and the unittests discovered by discover will be run. This is nice. However, it is actually desirable to run each unittest package individually, rather than in the same interpreter instance. When run via discover, imports from previous unittests corrupt the namespace of subsequent unittests and lead to failures (usually if there are mock objects in previously imported unit tests) and successes (usually if some other test module has imported something that the current test module ought to import but does not) which are both erroneous. discover should have some option to start the interpreter afresh for each unittest package or perhaps just clear all its imports. ---------- components: Library (Lib) messages: 215380 nosy: the.mulhern priority: normal severity: normal status: open title: unittest discover should allow option to run each package separately type: enhancement versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 15:27:23 2014 From: report at bugs.python.org (Eli Bendersky) Date: Wed, 02 Apr 2014 13:27:23 +0000 Subject: [issue20375] ElementTree: Document handling processing instructions In-Reply-To: <1390539216.23.0.0362813865609.issue20375@psf.upfronthosting.co.za> Message-ID: <1396445243.38.0.173826350487.issue20375@psf.upfronthosting.co.za> Eli Bendersky added the comment: I left some comments in Rietveld. There shouldn't be a problem getting these into 3.4 too - doc changes are usually excempt from most restrictions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 15:32:10 2014 From: report at bugs.python.org (Eli Bendersky) Date: Wed, 02 Apr 2014 13:32:10 +0000 Subject: [issue21028] ElementTree objects should support all the same methods as Element objects In-Reply-To: <1396295386.41.0.633466181565.issue21028@psf.upfronthosting.co.za> Message-ID: Eli Bendersky added the comment: > Do you have concrete suggestions? Make the tree iterable? > > Add all element methods to the tree, implicitly forwarding to the root? > > Yes, that is the feature request. Add all the element methods to the > elementtree object. > > Implicitly forwarding to the root would be a reasonable way to do it, but > that is just an implementation detail. Porting over all methods of Element to ElementTree sounds like an overkill to me. How about just making a sensibly-behaving __iter__ for ElementTree? This should be easy because ElementTree already has a iter() method that behaves as needed (goes over all elements including root). Would iteration + perhaps clearer documentation solve most of the problem? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 15:49:09 2014 From: report at bugs.python.org (Brett Cannon) Date: Wed, 02 Apr 2014 13:49:09 +0000 Subject: [issue21128] testing stdlib and compatibility with pypy In-Reply-To: <1396390977.66.0.122853817502.issue21128@psf.upfronthosting.co.za> Message-ID: <1396446549.04.0.731739893036.issue21128@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 16:02:06 2014 From: report at bugs.python.org (Stefan Behnel) Date: Wed, 02 Apr 2014 14:02:06 +0000 Subject: [issue21028] ElementTree objects should support all the same methods as Element objects In-Reply-To: Message-ID: <533C185B.6090604@behnel.de> Stefan Behnel added the comment: > How about just making a sensibly-behaving __iter__ for ElementTree? Well, the problem is to determine what "sensibly-behaving" is. I can see three options. 1) tree.iter() == tree.getroot().iter() 2) iter(tree.getroot()) 3) iter([tree.getroot()]) The second option feels plain wrong to me. The last one would allow the extension towards PI/comment siblings, as I described before. There isn't currently a way to get at them (which doesn't hurt, because ET doesn't currently even pass them through from its parser, as discussed in issue 9521). Once there is a way in ET to parse them in (as in lxml), making ElementTree objects iterable would nicely solve the issue of how to process them afterwards. It's not the only solution for that problem, though, adding a ".gettoplevel()" method would similarly work. Thus, either 1) or 3) would fit the API, with the downside of 1) being that it's just completely redundant functionality and I don't consider saving 7 simple characters worth the increase in API overhead. That leaves 3) as an option. It's nice because the iteration then works on the same axis as for Elements, so x.iter() and iter(x) would behave in the same way for both classes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 16:10:37 2014 From: report at bugs.python.org (Marek Kowalski) Date: Wed, 02 Apr 2014 14:10:37 +0000 Subject: [issue21134] Segfault when stringifying UnicodeEncodeError (or UnicodeDecodeError) created with __new__() Message-ID: <1396447837.72.0.201261233456.issue21134@psf.upfronthosting.co.za> New submission from Marek Kowalski: I'm attaching a minimal script to reproduce. I tested only with 3.2 and 2.7 versions. Its possible that it has been fixed since 3.2. ---------- components: Unicode files: segv.py messages: 215384 nosy: Marek.Kowalski, ezio.melotti, haypo priority: normal severity: normal status: open title: Segfault when stringifying UnicodeEncodeError (or UnicodeDecodeError) created with __new__() type: crash versions: Python 2.7, Python 3.2 Added file: http://bugs.python.org/file34702/segv.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 16:11:43 2014 From: report at bugs.python.org (dellair jie) Date: Wed, 02 Apr 2014 14:11:43 +0000 Subject: [issue21124] _struct module compilation error under Cygwin 1.7.17 on Python 3.4 In-Reply-To: <1396363951.96.0.324613047949.issue21124@psf.upfronthosting.co.za> Message-ID: <1396447903.54.0.581317739767.issue21124@psf.upfronthosting.co.za> dellair jie added the comment: Yamamoto, Thanks, the patch you offered did make the _struct error disappeared. I will do a bit more testing. Dellair ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 16:44:38 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 02 Apr 2014 14:44:38 +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: <1396449878.1.0.161860843764.issue21134@psf.upfronthosting.co.za> STINNER Victor added the comment: Python 3.2 is not getting bugfixes anymore, only 3.4 and 3.5 (and 2.7). ---------- versions: +Python 3.4, Python 3.5 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 16:47:31 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 02 Apr 2014 14:47:31 +0000 Subject: [issue21120] PyArena type is used in headers from the limited API In-Reply-To: <1396339821.73.0.473299529971.issue21120@psf.upfronthosting.co.za> Message-ID: <1396450051.4.0.177534321742.issue21120@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 17:00:33 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 02 Apr 2014 15:00:33 +0000 Subject: [issue21118] str.translate is absurdly slow in majority of use cases (takes up to 60x longer than similar functions) In-Reply-To: <1396307346.31.0.221715925478.issue21118@psf.upfronthosting.co.za> Message-ID: <1396450833.72.0.0820949096336.issue21118@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > bytes.translate() is much faster because it builds a C array of 256 > items to fast table lookup, whereas str.translate() requires a Python > dict lookup for each character, which is much slower. It should be easy to devise a simple hash table for the common case of one-to-one translation (and also deletion). ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 17:28:02 2014 From: report at bugs.python.org (bagrat lazaryan) Date: Wed, 02 Apr 2014 15:28:02 +0000 Subject: [issue17390] display python version on idle title bar In-Reply-To: <1362920194.83.0.464215113749.issue17390@psf.upfronthosting.co.za> Message-ID: <1396452482.38.0.908029570339.issue17390@psf.upfronthosting.co.za> bagrat lazaryan added the comment: guys, the filename should be the first thing on the titlebar of idle editor window. that way, on taskbar, one can see the file that's open in editor. i suggest the format of editor's title be changed to: xxx.py - python x.y.z - path or whatever you will as separator between elements. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 18:17:07 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 02 Apr 2014 16:17:07 +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: <3fzXc306MPz7LjZ@mail.python.org> Roundup Robot added the comment: New changeset 140c5da3dc82 by Benjamin Peterson in branch '3.4': bail in unicode error's __str__ methods if the objects are not properly initialized (closes #21134) http://hg.python.org/cpython/rev/140c5da3dc82 New changeset afa7fb2cbe3b by Benjamin Peterson in branch '2.7': bail in unicode error's __str__ methods if the objects are not properly initialized (closes #21134) http://hg.python.org/cpython/rev/afa7fb2cbe3b New changeset 0aeaea247d7d by Benjamin Peterson in branch 'default': merge 3.4 (#21134) http://hg.python.org/cpython/rev/0aeaea247d7d ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 19:11:36 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 02 Apr 2014 17:11:36 +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: <1396458696.03.0.692128550231.issue21134@psf.upfronthosting.co.za> STINNER Victor added the comment: Benjamin: I don't like your change. You silently ignore the error. I would prefer to raise an exception on str(exc) if the Unicode exception object was not properly initialized. ---------- resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 19:39:26 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 02 Apr 2014 17:39:26 +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: <1396460366.81.0.575722241057.issue21134@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I don't care as long as it doesn't segfault. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 19:43:48 2014 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Wed, 02 Apr 2014 17:43:48 +0000 Subject: [issue21019] PyMethodDef ml_name is char* instead of const char* In-Reply-To: <1395483254.03.0.173099227784.issue21019@psf.upfronthosting.co.za> Message-ID: <1396460628.29.0.241985873094.issue21019@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- nosy: +tshepang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 19:44:38 2014 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Wed, 02 Apr 2014 17:44:38 +0000 Subject: [issue21027] difflib new cli interface In-Reply-To: <1395521056.07.0.611061866436.issue21027@psf.upfronthosting.co.za> Message-ID: <1396460678.13.0.979961590956.issue21027@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- nosy: +tshepang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 19:45:31 2014 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Wed, 02 Apr 2014 17:45:31 +0000 Subject: [issue21034] Python docs reference the Distribute package which has been deprecated in favor of Setuptools In-Reply-To: <1395564519.98.0.0028723182567.issue21034@psf.upfronthosting.co.za> Message-ID: <1396460731.95.0.0865311792114.issue21034@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- nosy: +tshepang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 20:32:56 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 02 Apr 2014 18:32:56 +0000 Subject: [issue17846] Building Python on Windows - Supplementary info In-Reply-To: <1366919664.94.0.0931557904055.issue17846@psf.upfronthosting.co.za> Message-ID: <1396463575.99.0.965557123596.issue17846@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Since a debug build (F7 in VS) is the only thing I have ever built, or that a developer like me needs to build, that is not a limitation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 20:45:55 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 02 Apr 2014 18:45:55 +0000 Subject: [issue17390] display python version on idle title bar In-Reply-To: <1362920194.83.0.464215113749.issue17390@psf.upfronthosting.co.za> Message-ID: <1396464355.39.0.165549610812.issue17390@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Bagrat, are you on XP by any chance? In Win7, all windows for a program are attached to one program icon on the taskbar, which has the program name. When I hover over the program icon, mini views of each window are displayed, with each window view showing about 30 chars of the window title. For instance "Python 3.4.0: CallTipsWindow", which is fine for me. Moving the mouse over the mini window displays the complete title. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 20:57:13 2014 From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=) Date: Wed, 02 Apr 2014 18:57:13 +0000 Subject: [issue20942] _frozen_importlib should not have a __file__ attribute In-Reply-To: <1394948547.33.0.586299720319.issue20942@psf.upfronthosting.co.za> Message-ID: <1396465033.61.0.53753013693.issue20942@psf.upfronthosting.co.za> Bo?tjan Mejak added the comment: No one interested in fixing this anymore, despite the patch and all? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 21:11:45 2014 From: report at bugs.python.org (Brett Cannon) Date: Wed, 02 Apr 2014 19:11:45 +0000 Subject: [issue20942] _frozen_importlib should not have a __file__ attribute In-Reply-To: <1394948547.33.0.586299720319.issue20942@psf.upfronthosting.co.za> Message-ID: <1396465905.36.0.648047921907.issue20942@psf.upfronthosting.co.za> Brett Cannon added the comment: My Python free time is on Fridays, which is when I plan to make a final call and either apply to Python 3.4 and 3.5 or just Python 3.5. ---------- assignee: -> brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 22:03:45 2014 From: report at bugs.python.org (Eijebong) Date: Wed, 02 Apr 2014 20:03:45 +0000 Subject: [issue21135] Remove useless _vb_pattern parameter in cgi.valid_boundary Message-ID: <1396469025.05.0.161523900352.issue21135@psf.upfronthosting.co.za> New submission from Eijebong: The parameter _vb_pattern parameter in cgi.valid_boundary has no reason to exist since it's forced to a value later. ---------- components: Library (Lib) files: valid_boundary.patch keywords: patch messages: 215396 nosy: Eijebong priority: normal severity: normal status: open title: Remove useless _vb_pattern parameter in cgi.valid_boundary type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file34703/valid_boundary.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 22:19:09 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 02 Apr 2014 20:19:09 +0000 Subject: [issue21130] equivalent functools.partial instances should compare equal In-Reply-To: <1396425472.15.0.80240218298.issue21130@psf.upfronthosting.co.za> Message-ID: <1396469949.18.0.147527406623.issue21130@psf.upfronthosting.co.za> Raymond Hettinger added the comment: What is the use case? What would be the criteria for comparing functions? Would the func_name have to match? Would the func_defaults have to match? Would the f.__code__.co_names have to match (the internal variable names? Do the function attributes in f.__dict__ have to match? Does the func.__doc__ have to match? The problem is that functions are complex objects and the equivalence criteria means different things to different people. In the absence of a clear spec that makes sense to most people, object identity is the only sure definition of equivalence. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 22:26:24 2014 From: report at bugs.python.org (Sreepriya Chalakkal) Date: Wed, 02 Apr 2014 20:26:24 +0000 Subject: [issue19662] smtpd.py should not decode utf-8 In-Reply-To: <1384944703.82.0.967643613195.issue19662@psf.upfronthosting.co.za> Message-ID: <1396470384.03.0.261375957338.issue19662@psf.upfronthosting.co.za> Changes by Sreepriya Chalakkal : Added file: http://bugs.python.org/file34704/switch_while_decode2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 22:28:04 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 02 Apr 2014 20:28:04 +0000 Subject: [issue19640] Dynamically generate the _source attribute of namedtuple to save memory) In-Reply-To: <1384767730.42.0.112147293599.issue19640@psf.upfronthosting.co.za> Message-ID: <1396470484.64.0.509090615586.issue19640@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Victor, I don't think the added complexity is worth 2k per named tuple class. Every time I've gone down the path of lazy evaluation, I've paid an unexpected price for it down the road. If the savings were huge, it might be worth it, but that isn't the case here. This isn't really different than proposing that all docstring be in a separate module to be lazily loaded only when people look at help. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 22:33:01 2014 From: report at bugs.python.org (bagrat lazaryan) Date: Wed, 02 Apr 2014 20:33:01 +0000 Subject: [issue17390] display python version on idle title bar In-Reply-To: <1362920194.83.0.464215113749.issue17390@psf.upfronthosting.co.za> Message-ID: <1396470781.58.0.731680288062.issue17390@psf.upfronthosting.co.za> bagrat lazaryan added the comment: terry, i'm on 7 but i have my taskbar configured not to combine buttons. see the screenshot attached. (does anyone know why on earth i am not receiving email notifications when someone posts to an issue i have started or i have commented to?) ---------- Added file: http://bugs.python.org/file34705/taskbar.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 22:50:22 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 02 Apr 2014 20:50:22 +0000 Subject: [issue17862] itertools.chunks(iterable, size, fill=None) In-Reply-To: <1367165590.04.0.46648726654.issue17862@psf.upfronthosting.co.za> Message-ID: <1396471822.18.0.594612014292.issue17862@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Nothing new is happening in this thread, so I'm closing it for the reasons listed in the other posts. The main issue is that the generic concept of "break data into chunks" tends to occur is situations where the iterator protocol would be at odds with a clean solution. A reshape() method on lists would be much better suited to the task. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 22:51:27 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 02 Apr 2014 20:51:27 +0000 Subject: [issue21130] equivalent functools.partial instances should compare equal In-Reply-To: <1396425472.15.0.80240218298.issue21130@psf.upfronthosting.co.za> Message-ID: <1396471887.71.0.0521447365136.issue21130@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- Removed message: http://bugs.python.org/msg215397 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 22:52:20 2014 From: report at bugs.python.org (bagrat lazaryan) Date: Wed, 02 Apr 2014 20:52:20 +0000 Subject: [issue20198] xml.etree.ElementTree.ElementTree.write attribute sorting In-Reply-To: <1389231308.67.0.0933451284696.issue20198@psf.upfronthosting.co.za> Message-ID: <1396471940.04.0.888742395119.issue20198@psf.upfronthosting.co.za> bagrat lazaryan added the comment: well... ElementTree.py imports some c accelerators as can be seen at the end of the file. i have no idea how to get to those accelerators, and even if i had, i don't think i would make anything of them. as far as the pure python code concerns in the rest of ElementTree.py, it suffices not to sort the items in _serialize_xml: line 929 of ElementTree.py: -for k, v in sorted(items): # lexical order +for k, v in items: i gather something similar must be done in c accelerators. (by the way, does anyone know why i am not receiving email notifications when someone posts to an issue i have started or i have commented to?) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 22:52:31 2014 From: report at bugs.python.org (bagrat lazaryan) Date: Wed, 02 Apr 2014 20:52:31 +0000 Subject: [issue20198] xml.etree.ElementTree.ElementTree.write attribute sorting In-Reply-To: <1389231308.67.0.0933451284696.issue20198@psf.upfronthosting.co.za> Message-ID: <1396471951.02.0.945076109671.issue20198@psf.upfronthosting.co.za> Changes by bagrat lazaryan : ---------- versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 23:08:52 2014 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 02 Apr 2014 21:08:52 +0000 Subject: [issue21117] inspect.signature: inaccuracies for partial functions In-Reply-To: <1396297836.4.0.601810070188.issue21117@psf.upfronthosting.co.za> Message-ID: <1396472932.2.0.658335178529.issue21117@psf.upfronthosting.co.za> Yury Selivanov added the comment: Please review the attached patch. Here's the new partial signature semantics: foo(a, b, /, c, d, *args, e) partial(foo, 10) -> (b, /, c, d, *args, e) partial(foo, 10, c=11) -> (b, /, *, c=11, d, e) partial(foo, 10, 20, 30) -> (d, *args, e) partial(foo, 10, 20, 30, 40, 50) -> (*args, e) partial(foo, 10, 20, c=20) -> (*, c=20, d, e) Good news: 1. no more special attributes and other hidden hacks. 2. only with this patch we properly support functools.partial. So this is definitely something we can classify as a bug fix and push in 3.4.1. ---------- keywords: +patch Added file: http://bugs.python.org/file34706/signature_partial_fix_01.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 23:19:24 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 02 Apr 2014 21:19:24 +0000 Subject: [issue21130] equivalent functools.partial instances should compare equal In-Reply-To: <1396425472.15.0.80240218298.issue21130@psf.upfronthosting.co.za> Message-ID: <1396473564.54.0.42407103583.issue21130@psf.upfronthosting.co.za> R. David Murray added the comment: But since the two partial instances are (conceptually, I don't care how they are implemented) two separate functions, then reasoning by analogy from two identical functions not comparing equal, I would expect two partial instances to not compare equal. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 23:20:17 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Wed, 02 Apr 2014 21:20:17 +0000 Subject: [issue21116] Failure to create multiprocessing shared arrays larger than 50% of memory size under linux In-Reply-To: <1396294667.97.0.287941619482.issue21116@psf.upfronthosting.co.za> Message-ID: <1396473617.21.0.527923207564.issue21116@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Zero-filling mmap's backing file isn't really optimal: why not use truncate() instead? This way, it'll avoid completely I/O on filesystems that support sparse files, and should still work on FS that don't. ---------- nosy: +neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 23:20:50 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 02 Apr 2014 21:20:50 +0000 Subject: [issue21130] equivalent functools.partial instances should compare equal In-Reply-To: <1396425472.15.0.80240218298.issue21130@psf.upfronthosting.co.za> Message-ID: <1396473649.98.0.500262554808.issue21130@psf.upfronthosting.co.za> R. David Murray added the comment: Of course, as soon as I hit send, I had second thoughts :). I guess a partial is a binding, not a function. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 2 23:25:39 2014 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 02 Apr 2014 21:25:39 +0000 Subject: [issue17390] display python version on idle title bar In-Reply-To: <1362920194.83.0.464215113749.issue17390@psf.upfronthosting.co.za> Message-ID: <1396473939.23.0.982981841745.issue17390@psf.upfronthosting.co.za> Ezio Melotti added the comment: Other editors (e.g. Kate) use the format "filename - editor name". This is common for other applications as well (e.g. Firefox uses "page title - Mozilla Firefox"), so the request seems reasonable to me. If you want to go the extra mile you could have an option to decide if the filename should be first or not or even a format string that would allow users to fully configure the titlebar (e.g. "{file} - IDLE {version}"), but that might be out of the scope of this issue. FWIW I don't think Kate has an option for that, but it has one to show the full path in titlebar. (@bagrat: assuming your email address is correct, if you are not getting notifications they might have ended up in the spam folder.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 00:13:33 2014 From: report at bugs.python.org (=?utf-8?b?TcOpZMOpcmljIEJvcXVpZW4=?=) Date: Wed, 02 Apr 2014 22:13:33 +0000 Subject: [issue21116] Failure to create multiprocessing shared arrays larger than 50% of memory size under linux In-Reply-To: <1396294667.97.0.287941619482.issue21116@psf.upfronthosting.co.za> Message-ID: <1396476813.46.0.278551743169.issue21116@psf.upfronthosting.co.za> M?d?ric Boquien added the comment: If I remember correctly the problem is that some OS like linux (and probably others) do not really allocate space until something is written. If that's the case then the process may get killed later on when it writes something in the array. Here is a quick example: $ truncate -s 1T test.file $ ls -lh test.file -rw-r--r-- 1 mederic users 1.0T Apr 2 23:10 test.file $ df -h Filesystem Size Used Avail Use% Mounted on /dev/sdb1 110G 46G 59G 44% /home ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 01:20:53 2014 From: report at bugs.python.org (Richard Oudkerk) Date: Wed, 02 Apr 2014 23:20:53 +0000 Subject: [issue21116] Failure to create multiprocessing shared arrays larger than 50% of memory size under linux In-Reply-To: <1396294667.97.0.287941619482.issue21116@psf.upfronthosting.co.za> Message-ID: <1396480853.06.0.555216825765.issue21116@psf.upfronthosting.co.za> Richard Oudkerk added the comment: Using truncate() to zero extend is not really portable: it is only guaranteed on XSI-compliant POSIX systems. Also, the FreeBSD man page for mmap() has the following warning: WARNING! Extending a file with ftruncate(2), thus creating a big hole, and then filling the hole by modifying a shared mmap() can lead to severe file fragmentation. In order to avoid such fragmentation you should always pre-allocate the file's backing store by write()ing zero's into the newly extended area prior to modifying the area via your mmap(). The fragmentation problem is especially sensitive to MAP_NOSYNC pages, because pages may be flushed to disk in a totally random order. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 01:52:30 2014 From: report at bugs.python.org (William Ehlhardt) Date: Wed, 02 Apr 2014 23:52:30 +0000 Subject: [issue21136] fractions.Fraction.__pow__ does unneeded renormalization Message-ID: <1396482750.35.0.873465877702.issue21136@psf.upfronthosting.co.za> New submission from William Ehlhardt: The following Python runs unnecessarily slowly: import fractions fractions.Fraction(6249919, 6250000) ** 89993 The problem here is that Fraction.__pow__ constructs a new Fraction() to return, and Fraction.__new__ tries to gcd to normalize the numerator/denominator. The gcd is very, very slow, and more to the point, unnecessary; raising a normalized fraction to an integer power will always yield another normalized fraction. fractions.Fraction.__pow__ should use this trick to make the code snippet above fast. ---------- components: Library (Lib) messages: 215409 nosy: Orborde priority: normal severity: normal status: open title: fractions.Fraction.__pow__ does unneeded renormalization type: performance versions: Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 02:08:36 2014 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 03 Apr 2014 00:08:36 +0000 Subject: [issue21136] fractions.Fraction.__pow__ does unneeded renormalization In-Reply-To: <1396482750.35.0.873465877702.issue21136@psf.upfronthosting.co.za> Message-ID: <1396483716.46.0.0964389764082.issue21136@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti, mark.dickinson, rhettinger stage: -> needs patch versions: +Python 3.5 -Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 02:11:01 2014 From: report at bugs.python.org (paul j3) Date: Thu, 03 Apr 2014 00:11:01 +0000 Subject: [issue14156] argparse.FileType for '-' doesn't work for a mode of 'rb' In-Reply-To: <1330513271.31.0.437438851478.issue14156@psf.upfronthosting.co.za> Message-ID: <1396483861.09.0.220278454963.issue14156@psf.upfronthosting.co.za> paul j3 added the comment: There are a couple of complications to using 'fileno'. We probably don't want to close 'sys.stdin' or 'sys.stdout' (not even if they are redirected to other files?). That means using: open(sys.stdin.fileno(), ..., closefd=False) 'closefd', on the other hand, has to be True for string file specifications. But in 'test_argparse.py', 'sys.stdout' is redirected to an 'io.StringIO'. This has many of the same features as an open file, but 'fileno' is not implemented. So the TypeFile probably needs to make an exception for this case. I don't how this will play with a 'BytesIO' for 'wb' cases. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 02:25:20 2014 From: report at bugs.python.org (Josiah Carlson) Date: Thu, 03 Apr 2014 00:25:20 +0000 Subject: [issue1191964] asynchronous Subprocess Message-ID: <1396484720.82.0.30881713763.issue1191964@psf.upfronthosting.co.za> Josiah Carlson added the comment: Had some time to work on this today. I was missing something in my earlier versions of the code, and have managed to get overlapped IOs to work, so at least I'm not quite so far behind the dozen or so core developers who know more about the Windows pieces than I do. Richard, thank you for the post, I wasn't looking hard enough for how to get overlapped IOs to work, and your message made me look harder. On Linux, it is trivial to support the blocking communicate() and non-blocking additions. There's only one weirdness, and that's the fcntl bit flipping during write. On Windows, it's not all that difficult to switch to using overlapped IOs for *all* writes, and maybe even for communicate()-based reads, which would remove the need for threads. Ironically enough, non-blocking reads actually *don't* require overlapped IO thanks to PeekNamedPipe, which could even be used to cut the number of extra threads from 2 to 1 in communicate(). Now that I've got it working, I can do one of the following (from least changes to the most): 1. Add a "nonblocking" flag, which pre-flips the fcntl bit in Linux and uses overlapped IO on writes in Windows - this would be documented to remove the ability to call communicate() 2. As an alternative to #1, I can create a new class that lacks the communicate() method and adds the non-blocking methods 3. Gut/rewrite the Windows-based communicate() function to use overlapped IO on everything, removing the threads, and making it at least superficially like Linux (prepare your overlapped IO, then use WaitForMultipleObjects() to multiplex), while also adding the non-blocking methods Unless someone brings up an important counterpoint, I'll work on #3 tonight or tomorrow evening to get an initial code/test patch, with docs coming shortly after (if not immediately). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 03:12:54 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 03 Apr 2014 01:12:54 +0000 Subject: [issue21136] fractions.Fraction.__pow__ does unneeded renormalization In-Reply-To: <1396482750.35.0.873465877702.issue21136@psf.upfronthosting.co.za> Message-ID: <1396487574.34.0.728181695654.issue21136@psf.upfronthosting.co.za> Raymond Hettinger added the comment: This looks easily doable. ---------- assignee: -> rhettinger keywords: +easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 03:19:02 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 03 Apr 2014 01:19:02 +0000 Subject: [issue21137] Better repr for threading.Lock() Message-ID: <1396487942.81.0.581020836184.issue21137@psf.upfronthosting.co.za> New submission from Raymond Hettinger: It is really nice to have the open/closed status in the __repr__ of file objects: I would like to have the same for locks: This would be nice in logs and tracebacks for example. ---------- components: Library (Lib) keywords: easy messages: 215413 nosy: rhettinger priority: normal severity: normal status: open title: Better repr for threading.Lock() type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 03:30:58 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 03 Apr 2014 01:30:58 +0000 Subject: [issue21136] fractions.Fraction.__pow__ does unneeded renormalization In-Reply-To: <1396482750.35.0.873465877702.issue21136@psf.upfronthosting.co.za> Message-ID: <1396488658.05.0.808616051285.issue21136@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- keywords: +patch Added file: http://bugs.python.org/file34707/fraction_pow.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 03:39:20 2014 From: report at bugs.python.org (tanbro) Date: Thu, 03 Apr 2014 01:39:20 +0000 Subject: [issue21138] mimetypes.MimeType UnicodeDecodeError Message-ID: <1396489160.22.0.410580562036.issue21138@psf.upfronthosting.co.za> New submission from tanbro: when new a mimetypes.MimeType instance in a my Windows, whose default coding is mbcs, UnicdeDecodeError occurred. Python 2.7.6 (default, Nov 10 2013, 19:24:18) [MSC v.1500 32 bit (Intel)] on win 32 Type "help", "copyright", "credits" or "license" for more information. >>> from mimetypes import MimeTypes >>> mt = MimeTypes() Traceback (most recent call last): File "", line 1, in File "D:\Python27\lib\mimetypes.py", line 66, in __init__ init() File "D:\Python27\lib\mimetypes.py", line 358, in init db.read_windows_registry() File "D:\Python27\lib\mimetypes.py", line 258, in read_windows_registry for subkeyname in enum_types(hkcr): File "D:\Python27\lib\mimetypes.py", line 249, in enum_types ctype = ctype.encode(default_encoding) # omit in 3.x! UnicodeDecodeError: 'ascii' codec can't decode byte 0xc7 in position 8: ordinal not in range(128) i think this error was caused by the code in mimetypes.py's line 256 default_encoding = sys.getdefaultencoding() if change this line to: default_encoding = sys.getfilesystemencoding() such error will be resolved ---------- components: Library (Lib) messages: 215414 nosy: tanbro priority: normal severity: normal status: open title: mimetypes.MimeType UnicodeDecodeError type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 03:46:35 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Thu, 03 Apr 2014 01:46:35 +0000 Subject: [issue20375] ElementTree: Document handling processing instructions In-Reply-To: <1390539216.23.0.0362813865609.issue20375@psf.upfronthosting.co.za> Message-ID: <1396489595.95.0.60932034769.issue20375@psf.upfronthosting.co.za> Nikolaus Rath added the comment: Thanks for your feedback! I've attached an updated patch. ---------- Added file: http://bugs.python.org/file34708/issue20375.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 03:58:58 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Thu, 03 Apr 2014 01:58:58 +0000 Subject: [issue20375] ElementTree: Document handling processing instructions In-Reply-To: <1390539216.23.0.0362813865609.issue20375@psf.upfronthosting.co.za> Message-ID: <1396490338.7.0.114612696272.issue20375@psf.upfronthosting.co.za> Changes by Nikolaus Rath : Added file: http://bugs.python.org/file34709/issue20375.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 04:14:28 2014 From: report at bugs.python.org (Berker Peksag) Date: Thu, 03 Apr 2014 02:14:28 +0000 Subject: [issue21137] Better repr for threading.Lock() In-Reply-To: <1396487942.81.0.581020836184.issue21137@psf.upfronthosting.co.za> Message-ID: <1396491268.11.0.194830179379.issue21137@psf.upfronthosting.co.za> Berker Peksag added the comment: Here's a patch with a test. Example repr of threading.Lock(): $ ./python -c "import threading; print(threading.Lock())" ---------- keywords: +patch nosy: +berker.peksag Added file: http://bugs.python.org/file34710/issue21137.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 04:29:23 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 03 Apr 2014 02:29:23 +0000 Subject: [issue21139] Idle: change default reformat width from 70 to 72 Message-ID: <1396492163.57.0.51526901235.issue21139@psf.upfronthosting.co.za> New submission from Terry J. Reedy: PEP 8 specifies a limit of 72 chars for flowing text (comments, multiline strings). The current default limit for Idle's Format / Reformat Paragraph is 70. Increase it to PEP 8's 72. ---------- messages: 215417 nosy: terry.reedy priority: normal severity: normal stage: needs patch status: open title: Idle: change default reformat width from 70 to 72 type: enhancement versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 04:39:42 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 03 Apr 2014 02:39:42 +0000 Subject: [issue21139] Idle: change default reformat width from 70 to 72 In-Reply-To: <1396492163.57.0.51526901235.issue21139@psf.upfronthosting.co.za> Message-ID: <1396492782.17.0.00350677782379.issue21139@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- components: +IDLE _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 04:40:28 2014 From: report at bugs.python.org (tanbro) Date: Thu, 03 Apr 2014 02:40:28 +0000 Subject: [issue21138] mimetypes.MimeType UnicodeDecodeError In-Reply-To: <1396489160.22.0.410580562036.issue21138@psf.upfronthosting.co.za> Message-ID: <1396492828.5.0.394825209786.issue21138@psf.upfronthosting.co.za> tanbro added the comment: and in line 249, changes: if isinstance(ctype, unicode): ctype = ctype.encode(default_encoding) # omit in 3.x! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 04:47:39 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 03 Apr 2014 02:47:39 +0000 Subject: [issue21140] Idle: saving an OutputWindow should default to .txt Message-ID: <1396493259.83.0.13428125931.issue21140@psf.upfronthosting.co.za> New submission from Terry J. Reedy: If possible, when saving an instance of an OutputWindow, the file type should default to .txt (or possibly even nothing) instead of .py. At present, OutputWindows are only used for Find in Files (grep) output, which is very much not Python code. The same should be true of any other OutputWindow uses, which I except there will be, making OutputWindow saves more common. A patch should be tested and verified on Mac, Linux, and Windows. ---------- components: IDLE messages: 215419 nosy: terry.reedy priority: normal severity: normal stage: needs patch status: open title: Idle: saving an OutputWindow should default to .txt type: behavior versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 04:55:11 2014 From: report at bugs.python.org (eryksun) Date: Thu, 03 Apr 2014 02:55:11 +0000 Subject: [issue1191964] asynchronous Subprocess Message-ID: <1396493711.56.0.237973854592.issue1191964@psf.upfronthosting.co.za> eryksun added the comment: multiprocessing.connection uses the _winapi module for overlapped I/O and named pipes in case you're looking for examples: http://hg.python.org/cpython/file/3.4/Lib/multiprocessing/connection.py ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 05:39:49 2014 From: report at bugs.python.org (Zachary Ware) Date: Thu, 03 Apr 2014 03:39:49 +0000 Subject: [issue21141] Don't mention Perl in Windows build output Message-ID: <1396496389.49.0.887037786203.issue21141@psf.upfronthosting.co.za> New submission from Zachary Ware: Attached is a patch that prevents mentioning Perl in the Windows build output, thereby avoiding giving the indication that Perl is necessary to build Python. To make this work, the patch converts PCbuild/build_ssl.py into PCbuild/prepare_ssl.py and removes the actual building of OpenSSL from that script. Instead, prepare_ssl.py takes a directory name as an argument (which is assumed to be a directory containing OpenSSL sources) and does what it has always done to prepare the way for building, except now it does it for both platforms. PCbuild/build_ssl.bat is also updated to match. Meanwhile, the actual building is moved entirely within ssl.vcxproj, which now runs a short script that copies buildinf*.h and opensslconf*.h into place and calls nmake with the appropriate makefile (x64 builds also run the appropriate nasm command first). Since this is all done inside ssl.vcxproj, the dependency on python.vcxproj is dropped, allowing SSL to be built in parallel with pythoncore, tcl, tk, and tix when using the '/m' msbuild command line switch. As a part of converting build_ssl.py into prepare_ssl.py, the comments at the top of the file have been updated. Also, some dead code has been trimmed: the "-a" flag has been completely unused for a long time, and debug builds have been disabled as well; all code relating to either feature has been removed. I've tested this by successfully preparing (once) and building openssl-1.0.1f in both 32 and 64 bit builds. ---------- components: Build, Windows files: no_perl.diff keywords: patch messages: 215421 nosy: loewis, terry.reedy, tim.golden, zach.ware priority: normal severity: normal stage: patch review status: open title: Don't mention Perl in Windows build output type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file34711/no_perl.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 05:56:18 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 03 Apr 2014 03:56:18 +0000 Subject: [issue17390] display python version on idle title bar In-Reply-To: <1362920194.83.0.464215113749.issue17390@psf.upfronthosting.co.za> Message-ID: <1396497378.13.0.0209144531071.issue17390@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The general issue of Idle title bars is definitely not finished, though I may close this issue and open others. 1. 'Python' versus "Idle' versus neither in titles (assuming not both). 1a. Shell: Since the link in msg183874 is dead, I don't know what Bagrat suggested. I said 'Python' in msg183932, hinted 'Idle' in msg184620, and pushed the patch that had 'Python'. I could argue either way, but 'Python x.y.z Shell' (versus 'Idle x.y.z Shell') works as the name of the Idle product and also identifies what will run the code entered. I am now thinking 'neither' and propose making the title 'Shell x.y.z' -- see the more on this below. 1b. Editor: The patch I applied followed the same pattern, and again, I could argue for either 'Idle x.y.z' (what is doing the editing) or 'Python x.y.z' (what will run the code with F5)'. In this and the shell case, the version is the most important new information. If we consider the titles of other windows (see still more below), I think the class title should be 'Editor x.y.z'. 1c. OutputWindow: This is a bit tougher. 'Output' only works, sort of, as long as the class is only used for FIF, (Find in Files, grep). The initial title is actually '*Output*', indicating unsaved content, with no file name specified. Once saved, the title changes to "Output - ". This is a precedent for 'Editor - ' Since this issue started about adding versions, and version is not relevant to this and the following windows, a patch for OutputWindows should be a new issue. However, the design options need to be considered together. 1d. Read-only windows: We have "Debug Control", "Path Browser", and "Class Browser - Output Window". (For the last, "- Output Window" should go since it adds nothing and misleads in that the window is not an OutputWindow. It could be replaced with the class name.) 2. Order of generic and specific (or class and instance) components. Most windows have a generic title for windows of a class. Part of my thinking above in suggesting 'Shell x.y.z' and 'Editor x.y.z' for the respective classes is that none of the class titles should contain either 'Python' or 'Idle' [separate? issue 0 -- it would be a correction of the patches on this issue]. Once an OutputWindow is saved, its title has a generic and specific component, in that order. The specific component identifies the specific contents of the instance. While I expect to replace 'Output' with names that reflect the subclasses of usage, the pattern will remain the same [separate issue 1]. Before we added a generic component for editor windows, they were unique in not having one. They currently follow the output pattern. I am also thinking a giving the title for ClassBrowswer (which is really ModuleBrowser) a specific component -- the module name [separate issue 2]. My point is that we have gone from one generic-specific (class-instance) name pair to two, and soon to more. If someone wants one pair flipped, then it seems logical to me that the same person would want all such pairs flipped, for the same reason. Bagrat, is this true for you? I know you only mentioned editor pairs, but you may not have known about output pairs, and certainly not future pairs that do not exist yet. I am willing to consider a user-settable option [separate issue 3], but I would think it should cover all such pairs, and not just editor window pairs. Currently, editor window titles are also unique in repeating part of the specific title. Output windows, when saved, do not repeat the short file name. Do any other editor programs do this? I expect we may decide to eliminate the redundancy as it exist now. Notepad++ puts " - Notepad++" on the title bar and the filename on the notebook tab. When the tabbed selected changes, the title bar changes. Firefox does the title to match the tab also. There is already an issue to use tabbed notebooks with Idle and when we do that, I would expect to remove the duplication in the title and imitate Notepad++. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 07:33:30 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 03 Apr 2014 05:33:30 +0000 Subject: [issue20550] Use specific asserts in collections tests In-Reply-To: <1391804816.95.0.0835407946311.issue20550@psf.upfronthosting.co.za> Message-ID: <1396503210.54.0.700662725178.issue20550@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Sorry, I don't think this makes the tests any better as all. It is code churn for no benefit. In our own code, the "more specific tests" risk hiding important details behind the abstraction (losing knowledge of what is actually tested). For example, I don't like that assertIn actually does a "not in" test or that assertIsNot runs "is". In those two cases, it doesn't make a difference but does hint at the loss of knowledge. Also, changing tests carries a higher set of risks than changing other code because there are no tests-for-the-tests. This means that it would easy to accidentally break a test from testing what it is supposed to and not know about it. The "has a nicer error message" is a vacuous promise. The new output: Traceback (most recent call last): File "/Users/raymond/Documents/tmp14.py", line 10, in test_one self.assertIs(a, b) AssertionError: a is not b Isn't any better than the current output: Traceback (most recent call last): File "/Users/raymond/Documents/tmp14.py", line 13, in test_two self.assertTrue(a is b) AssertionError: False is not true Both of them show a failing "is" test and the first one mysteriously outputs "is not" which is technically a different operator (albeit, unimportantly so). ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 07:57:03 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 03 Apr 2014 05:57:03 +0000 Subject: [issue19505] OrderedDict views don't implement __reversed__ In-Reply-To: <1383668278.19.0.898064141243.issue19505@psf.upfronthosting.co.za> Message-ID: <1396504623.87.0.212354701711.issue19505@psf.upfronthosting.co.za> Raymond Hettinger added the comment: This is approved. Go ahead and apply the patch. One minor nit, please position the three new views classes before the _Link class rather than after. ---------- assignee: rhettinger -> serhiy.storchaka versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 08:14:09 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 03 Apr 2014 06:14:09 +0000 Subject: [issue21116] Failure to create multiprocessing shared arrays larger than 50% of memory size under linux In-Reply-To: <1396476813.46.0.278551743169.issue21116@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > If I remember correctly the problem is that some OS like linux (and probably others) do not really allocate space until something is written. If that's the case then the process may get killed later on when it writes something in the array. Yes, it's called overcommitting, and it's a good thing. It's exactly the same thing for memory: malloc() can return non-NULL, and the process will get killed when first writing to the page in case of memory pressure. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 09:38:43 2014 From: report at bugs.python.org (Richard Oudkerk) Date: Thu, 03 Apr 2014 07:38:43 +0000 Subject: [issue1191964] asynchronous Subprocess In-Reply-To: <1396493711.56.0.237973854592.issue1191964@psf.upfronthosting.co.za> Message-ID: Richard Oudkerk added the comment: I would recommended using _overlapped instead of _winapi. I intend to move multiprocessing over in future. Also note that you can do nonblocking reads by starting an overlapped read then cancelling it immediately if it fails with "incomplete". You will need to recheck if it completes anyway because of a race. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 09:39:47 2014 From: report at bugs.python.org (bagrat lazaryan) Date: Thu, 03 Apr 2014 07:39:47 +0000 Subject: [issue17390] display python version on idle title bar In-Reply-To: <1362920194.83.0.464215113749.issue17390@psf.upfronthosting.co.za> Message-ID: <1396510787.89.0.879945179989.issue17390@psf.upfronthosting.co.za> bagrat lazaryan added the comment: terry, i indeed didn't know about output windows. (or at least i didn't know i knew. by the way, what are they?) the logic behind my request is that the file being edited in the editor is the most important thing of the editor. a quick glance at the taskbar, for those like me that have it set not to combine taskbar buttons, or for those on xp and the like, should reveal what is what. (terry, i received your email but still none from issue tracker, neither in spam. the last notification i received was that of msg186751, back in 2013. do you think i should file an issue on meta tracker?) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 10:36:32 2014 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 03 Apr 2014 08:36:32 +0000 Subject: [issue21136] fractions.Fraction.__pow__ does unneeded renormalization In-Reply-To: <1396482750.35.0.873465877702.issue21136@psf.upfronthosting.co.za> Message-ID: <1396514192.08.0.489417704926.issue21136@psf.upfronthosting.co.za> Mark Dickinson added the comment: LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 10:37:34 2014 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 03 Apr 2014 08:37:34 +0000 Subject: [issue21136] fractions.Fraction.__pow__ does unneeded renormalization In-Reply-To: <1396482750.35.0.873465877702.issue21136@psf.upfronthosting.co.za> Message-ID: <1396514254.44.0.603238172009.issue21136@psf.upfronthosting.co.za> Mark Dickinson added the comment: Hmm. Does this work correctly in the case `Fraction(0, 1) ** -2`? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 10:41:19 2014 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 03 Apr 2014 08:41:19 +0000 Subject: [issue21136] fractions.Fraction.__pow__ does unneeded renormalization In-Reply-To: <1396482750.35.0.873465877702.issue21136@psf.upfronthosting.co.za> Message-ID: <1396514479.14.0.593463974075.issue21136@psf.upfronthosting.co.za> Mark Dickinson added the comment: > Does this work correctly in the case `Fraction(0, 1) ** -2`? Looks like it doesn't. How about adding a `_skip_normalization` keyword argument to `Fraction.__new__` instead? That would ensure that any future changes made to `__new__` don't get skipped by this fast path. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 10:43:11 2014 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 03 Apr 2014 08:43:11 +0000 Subject: [issue21136] fractions.Fraction.__pow__ does unneeded renormalization In-Reply-To: <1396482750.35.0.873465877702.issue21136@psf.upfronthosting.co.za> Message-ID: <1396514591.77.0.268852852614.issue21136@psf.upfronthosting.co.za> Mark Dickinson added the comment: (And other operations like `__pos__`, `__neg__` and `__abs__` would benefit from a `_skip_normalization` flag, too.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 10:50:16 2014 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 03 Apr 2014 08:50:16 +0000 Subject: [issue21142] Daily/weekly ABI scan? Message-ID: <1396515016.38.0.140196375249.issue21142@psf.upfronthosting.co.za> New submission from Nick Coghlan: At Anatoly's prompting, Andrey Ponomarenko set up ABI/API compatibility checks for CPython on the Linux upstream tracker (http://upstream-tracker.org/) Everything: http://upstream-tracker.org/versions/python.html Public API/ABI (no leading underscores): http://upstream-tracker.org/versions/python_public_api.html 3.2 limited API/stable ABI (no leading underscores): http://upstream-tracker.org/versions/python_stable_api.html Andrey's analysis in the python-ideas thread [1] indicates we've likely made some mistakes in exposing struct internals, as well as exposing new APIs unintentionally under older Py_LIMITED_API definitions. There's probably not too much (if anything) we can do to rectify the past mistakes, but we could set up a daily or weekly check (akin to the existing refleak scan) that monitored for such mistakes to prevent the introduction of any new errors along these lines. [1] https://mail.python.org/pipermail/python-dev/2014-April/133754.html ---------- messages: 215432 nosy: ncoghlan priority: normal severity: normal status: open title: Daily/weekly ABI scan? type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 11:01:52 2014 From: report at bugs.python.org (=?utf-8?b?TcOpZMOpcmljIEJvcXVpZW4=?=) Date: Thu, 03 Apr 2014 09:01:52 +0000 Subject: [issue21116] Failure to create multiprocessing shared arrays larger than 50% of memory size under linux In-Reply-To: <1396294667.97.0.287941619482.issue21116@psf.upfronthosting.co.za> Message-ID: <1396515712.44.0.679574723.issue21116@psf.upfronthosting.co.za> M?d?ric Boquien added the comment: "the process will get killed when first writing to the page in case of memory pressure." According to the documentation, the returned shared array is zeroed. https://docs.python.org/3.4/library/multiprocessing.html#module-multiprocessing.sharedctypes In that case because the entire array is written at allocation, the process is expected to get killed if allocating more memory than available. Unless I am misunderstanding something, which is entirely possible. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 11:54:45 2014 From: report at bugs.python.org (Jyrki Pulliainen) Date: Thu, 03 Apr 2014 09:54:45 +0000 Subject: [issue21143] Copy-paste error in documentation of __builtin__.max Message-ID: <1396518885.59.0.164691798901.issue21143@psf.upfronthosting.co.za> New submission from Jyrki Pulliainen: Looks like the documentation of the __builtin__.max() got copied over from the __builtin__.min. Instead of "the smallest of the positional arguments" it should say "the largest of the positional arguments". This was introduced in 3.4. Patch attached. Thanks to chiman@#python.fi for spotting this! ---------- assignee: docs at python components: Documentation files: fix-typo-in-max.patch keywords: patch messages: 215434 nosy: docs at python, nailor priority: normal severity: normal status: open title: Copy-paste error in documentation of __builtin__.max versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file34712/fix-typo-in-max.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 11:57:57 2014 From: report at bugs.python.org (Berker Peksag) Date: Thu, 03 Apr 2014 09:57:57 +0000 Subject: [issue21143] Copy-paste error in documentation of __builtin__.max In-Reply-To: <1396518885.59.0.164691798901.issue21143@psf.upfronthosting.co.za> Message-ID: <1396519077.72.0.687265714084.issue21143@psf.upfronthosting.co.za> Berker Peksag added the comment: I also fixed this as part of issue 20620. ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 12:12:37 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 Apr 2014 10:12:37 +0000 Subject: [issue21137] Better repr for threading.Lock() In-Reply-To: <1396487942.81.0.581020836184.issue21137@psf.upfronthosting.co.za> Message-ID: <1396519957.12.0.873699619742.issue21137@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The repr of threading._RLock contains owner and count, but not lock/unlock status. The repr of locks from _dummy_thread also should contain lock/unlock status. And it would be nice to have the open/closed status in the repr of other synchronization primitives: Condition, Semaphore, etc. As for tests, I think assertRegex() will produce more useful error report. ---------- nosy: +serhiy.storchaka stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 12:14:51 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 Apr 2014 10:14:51 +0000 Subject: [issue21137] Better repr for threading.Lock() In-Reply-To: <1396487942.81.0.581020836184.issue21137@psf.upfronthosting.co.za> Message-ID: <1396520091.01.0.942027619193.issue21137@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: And of course we should keep "at 0x..." part, because it is the way to distinguish different lock objects. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 12:23:47 2014 From: report at bugs.python.org (Nikolaus Demmel) Date: Thu, 03 Apr 2014 10:23:47 +0000 Subject: [issue21144] ensurepip "AssertionError: Multiple .dist-info directories" Message-ID: <1396520627.59.0.769231802002.issue21144@psf.upfronthosting.co.za> New submission from Nikolaus Demmel: I am installing python 3.4 on OS X 10.9 Mavericks via Homebrew. The Homebrew formula is: https://github.com/Homebrew/homebrew/blob/4bd9b7538297c2ecbcaba281a6db86e8d8f660c8/Library/Formula/python3.rb During the installation, `ensurepip` is called, but failes with "AssertionError: Multiple .dist-info directories". I have reported this downstream with Homebrew, but it is suggested that this is an upstream issue: https://github.com/Homebrew/homebrew/issues/28035 The ensurepip output can be seen here: https://gist.github.com/NikolausDemmel/9952010#file-python3-4-installation-with-homebrew-L685-L709 And the mentioned log file here: https://gist.github.com/NikolausDemmel/9952010#file-python3-4-installation-with-homebrew-L751-L784 ---------- messages: 215438 nosy: demmeln priority: normal severity: normal status: open title: ensurepip "AssertionError: Multiple .dist-info directories" type: crash versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 12:28:52 2014 From: report at bugs.python.org (Omer Katz) Date: Thu, 03 Apr 2014 10:28:52 +0000 Subject: [issue21145] Add the @cached_property decorator Message-ID: <1396520932.53.0.707047361064.issue21145@psf.upfronthosting.co.za> New submission from Omer Katz: cached properties are widely used in various prominent Python projects such as Django and pip (and many more). They are not very complicated and there are proven implementation out there. Unfortunately there are way too many of them. This situation leads me to suggest adding it to the builtins. Possible benefits: * Implementation in C can improve caching performance * Standardized implementation that can be used anywhere ---------- messages: 215439 nosy: Omer.Katz priority: normal severity: normal status: open title: Add the @cached_property decorator type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 12:40:06 2014 From: report at bugs.python.org (Wolfgang Maier) Date: Thu, 03 Apr 2014 10:40:06 +0000 Subject: [issue21146] update gzip usage examples in docs Message-ID: <1396521606.53.0.161098821761.issue21146@psf.upfronthosting.co.za> New submission from Wolfgang Maier: The current documentation of the gzip module should have its section "12.2.1. Examples of usage" updated to reflect the changes made to the module in Python3.2 (https://docs.python.org/3.2/whatsnew/3.2.html#gzip-and-zipfile). Currently, the recipe given for gz-compressing a file is: import gzip with open('/home/joe/file.txt', 'rb') as f_in: with gzip.open('/home/joe/file.txt.gz', 'wb') as f_out: f_out.writelines(f_in) which is clearly sub-optimal because it is line-based. An equally simple, but more efficient recipe would be: chunk_size = 1024 with open('/home/joe/file.txt', 'rb') as f_in: with gzip.open('/home/joe/file.txt.gz', 'wb') as f_out: while True: c = f_in.read(chunk_size) if not c: break d = f_out.write(c) Comparing the two examples I find a >= 2x performance gain (both in terms of CPU time and wall time). In the inverse scenario of file *de*-compression (which is not part of the docs though), the performance increase of substituting: with gzip.open('/home/joe/file.txt.gz', 'rb') as f_in: with open('/home/joe/file.txt', 'wb') as f_out: f_out.writelines(f_in) with: with gzip.open('/home/joe/file.txt.gz', 'rb') as f_in: with open('/home/joe/file.txt', 'wb') as f_out: while True: c = f_in.read(chunk_size) if not c: break d = f_out.write(c) is even higher (4-5x speed-ups). In the de-compression case, another >= 2x speed-up can be achieved by avoiding the gzip module completely and going through a zlib.decompressobj instead, but of course this is a bit more complicated and should be documented in the zlib docs rather than the gzip docs (if you're interested, I could provide my code for it though). Using the zlib library compression/decompression speed gets comparable to linux gzip/gunzip. ---------- assignee: docs at python components: Documentation messages: 215440 nosy: docs at python, wolma priority: normal severity: normal status: open title: update gzip usage examples in docs type: performance versions: Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 12:41:56 2014 From: report at bugs.python.org (Andrey) Date: Thu, 03 Apr 2014 10:41:56 +0000 Subject: [issue21142] Daily/weekly ABI scan? In-Reply-To: <1396515016.38.0.140196375249.issue21142@psf.upfronthosting.co.za> Message-ID: <1396521716.63.0.646140228406.issue21142@psf.upfronthosting.co.za> Andrey added the comment: There are just three simple steps to setup ABI checker: 1. Create ABI dump of the _reference_ version (see instructions [1]) and commit it to the source tree (ABI-ref.dump): $> abi-compliance-checker -l python -dump descriptor.xml -dump-path ABI-ref.dump 2. Create ABI dump of the _current_ version (ABI-cur.dump) 3. Compare these ABI dumps: $> abi-compliance-checker -l python -old ABI-ref.dump -new ABI-cur.dump -report-path abi-report.html To skip analysis of symbols with leading underscore pass this additional option to the tool when comparing ABI dumps: --skip-internal="\A_" For more information see [2]. [1] https://mail.python.org/pipermail/python-dev/2014-April/133754.html [2] http://ispras.linuxbase.org/index.php/ABI_compliance_checker ---------- nosy: +aponomarenko _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 13:39:42 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Apr 2014 11:39:42 +0000 Subject: [issue21145] Add the @cached_property decorator In-Reply-To: <1396520932.53.0.707047361064.issue21145@psf.upfronthosting.co.za> Message-ID: <1396525182.07.0.711384438359.issue21145@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 13:53:07 2014 From: report at bugs.python.org (Saimadhav Heblikar) Date: Thu, 03 Apr 2014 11:53:07 +0000 Subject: [issue21140] Idle: saving an OutputWindow should default to .txt In-Reply-To: <1396493259.83.0.13428125931.issue21140@psf.upfronthosting.co.za> Message-ID: <1396525987.73.0.946387280653.issue21140@psf.upfronthosting.co.za> Changes by Saimadhav Heblikar : ---------- nosy: +sahutd _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 13:57:06 2014 From: report at bugs.python.org (INADA Naoki) Date: Thu, 03 Apr 2014 11:57:06 +0000 Subject: [issue21146] update gzip usage examples in docs In-Reply-To: <1396521606.53.0.161098821761.issue21146@psf.upfronthosting.co.za> Message-ID: <1396526226.27.0.54006365625.issue21146@psf.upfronthosting.co.za> INADA Naoki added the comment: Maybe, shutil.copyfileobj() is good. import gzip import shutil with open(src, 'rb') as f_in: with gzip.open(dst, 'wb') as f_out: shutil.copyfileobj(f_in, f_out) ---------- nosy: +naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 14:44:39 2014 From: report at bugs.python.org (Wolfgang Maier) Date: Thu, 03 Apr 2014 12:44:39 +0000 Subject: [issue21146] update gzip usage examples in docs In-Reply-To: <1396521606.53.0.161098821761.issue21146@psf.upfronthosting.co.za> Message-ID: <1396529079.15.0.147890465893.issue21146@psf.upfronthosting.co.za> Wolfgang Maier added the comment: >> with open(src, 'rb') as f_in: >> with gzip.open(dst, 'wb') as f_out: >> shutil.copyfileobj(f_in, f_out) +1 !! exactly as fast as my suggestion (with compression and de-compression), but a lot clearer ! Hadn't thought of it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 14:50:40 2014 From: report at bugs.python.org (Wolfgang Maier) Date: Thu, 03 Apr 2014 12:50:40 +0000 Subject: [issue21146] update gzip usage examples in docs In-Reply-To: <1396521606.53.0.161098821761.issue21146@psf.upfronthosting.co.za> Message-ID: <1396529440.86.0.581260801454.issue21146@psf.upfronthosting.co.za> Wolfgang Maier added the comment: same speed is not surprising though as shutil.copyfileobj is implemented like this: def copyfileobj(fsrc, fdst, length=16*1024): """copy data from file-like object fsrc to file-like object fdst""" while 1: buf = fsrc.read(length) if not buf: break fdst.write(buf) which is essentially what I was proposing :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 15:15:29 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 03 Apr 2014 13:15:29 +0000 Subject: [issue20375] ElementTree: Document handling processing instructions In-Reply-To: <1390539216.23.0.0362813865609.issue20375@psf.upfronthosting.co.za> Message-ID: <3g04X00STGzQPC@mail.python.org> Roundup Robot added the comment: New changeset 871278b87c62 by Eli Bendersky in branch '3.4': Issue #20375: Clarify ET's parsing of comments and processing instructions. http://hg.python.org/cpython/rev/871278b87c62 New changeset 5c3166ec80e1 by Eli Bendersky in branch 'default': Issue #20375: Clarify ET's parsing of comments and processing instructions. http://hg.python.org/cpython/rev/5c3166ec80e1 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 15:16:19 2014 From: report at bugs.python.org (Eli Bendersky) Date: Thu, 03 Apr 2014 13:16:19 +0000 Subject: [issue20375] ElementTree: Document handling processing instructions In-Reply-To: <1390539216.23.0.0362813865609.issue20375@psf.upfronthosting.co.za> Message-ID: <1396530979.26.0.370811004256.issue20375@psf.upfronthosting.co.za> Eli Bendersky added the comment: Thanks. Doc patch committed with some slight rewording. Would you like to prepare a separate patch for the tests, default branch only this time? ---------- versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 15:17:07 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 03 Apr 2014 13:17:07 +0000 Subject: [issue21144] ensurepip "AssertionError: Multiple .dist-info directories" In-Reply-To: <1396520627.59.0.769231802002.issue21144@psf.upfronthosting.co.za> Message-ID: <1396531027.11.0.228721195452.issue21144@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +dstufft _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 15:42:00 2014 From: report at bugs.python.org (Eli Bendersky) Date: Thu, 03 Apr 2014 13:42:00 +0000 Subject: [issue19655] Replace the ASDL parser carried with CPython In-Reply-To: <1384869696.09.0.547082157855.issue19655@psf.upfronthosting.co.za> Message-ID: <1396532520.01.0.0648633142245.issue19655@psf.upfronthosting.co.za> Eli Bendersky added the comment: Since there has mostly been support for this, I'll wait a couple more days and commit it unless someones objects or asks for more time for review. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 16:19:04 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 03 Apr 2014 14:19:04 +0000 Subject: [issue21034] Python docs reference the Distribute package which has been deprecated in favor of Setuptools In-Reply-To: <1395564519.98.0.0028723182567.issue21034@psf.upfronthosting.co.za> Message-ID: <1396534744.64.0.369882999089.issue21034@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Good point. Perhaps we should reccomend https://raw.github.com/pypa/pip/master/contrib/get-pip.py instead, though? ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 16:22:29 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 03 Apr 2014 14:22:29 +0000 Subject: [issue21135] Remove useless _vb_pattern parameter in cgi.valid_boundary In-Reply-To: <1396469025.05.0.161523900352.issue21135@psf.upfronthosting.co.za> Message-ID: <3g061J6drcz7Lpq@mail.python.org> Roundup Robot added the comment: New changeset 54bd06097619 by Benjamin Peterson in branch '3.4': remove unused argument (closes #21135) http://hg.python.org/cpython/rev/54bd06097619 New changeset 2299cb5e8592 by Benjamin Peterson in branch 'default': merge 3.4 (#21135) http://hg.python.org/cpython/rev/2299cb5e8592 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 16:31:53 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 03 Apr 2014 14:31:53 +0000 Subject: [issue20887] stdlib compatibility with pypy, test_zipfile.py In-Reply-To: <1394485864.85.0.338262339301.issue20887@psf.upfronthosting.co.za> Message-ID: <3g06D907jYz7Ljn@mail.python.org> Roundup Robot added the comment: New changeset 03df2c1c6892 by Benjamin Peterson in branch '2.7': properly close files in test_zipfile (#20887) http://hg.python.org/cpython/rev/03df2c1c6892 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 16:32:29 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 03 Apr 2014 14:32:29 +0000 Subject: [issue20887] stdlib compatibility with pypy, test_zipfile.py In-Reply-To: <1394485864.85.0.338262339301.issue20887@psf.upfronthosting.co.za> Message-ID: <1396535549.86.0.00782051595504.issue20887@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Thanks for the patch. 3.x test_zipfile can be dealt with elsewhere if desired. ---------- nosy: +benjamin.peterson resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 17:01:52 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 03 Apr 2014 15:01:52 +0000 Subject: [issue21143] Copy-paste error in documentation of __builtin__.max In-Reply-To: <1396518885.59.0.164691798901.issue21143@psf.upfronthosting.co.za> Message-ID: <3g06tl5jVqz7Ljj@mail.python.org> Roundup Robot added the comment: New changeset 8fe2bb0c5851 by Raymond Hettinger in branch '3.4': Issue 21143: Fix typo in docs for max(). http://hg.python.org/cpython/rev/8fe2bb0c5851 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 17:02:20 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 03 Apr 2014 15:02:20 +0000 Subject: [issue21143] Copy-paste error in documentation of __builtin__.max In-Reply-To: <1396518885.59.0.164691798901.issue21143@psf.upfronthosting.co.za> Message-ID: <1396537340.28.0.683208891883.issue21143@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Thanks for the report. ---------- nosy: +rhettinger resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 18:02:55 2014 From: report at bugs.python.org (Saimadhav Heblikar) Date: Thu, 03 Apr 2014 16:02:55 +0000 Subject: [issue21140] Idle: saving an OutputWindow should default to .txt In-Reply-To: <1396493259.83.0.13428125931.issue21140@psf.upfronthosting.co.za> Message-ID: <1396540975.11.0.327576037507.issue21140@psf.upfronthosting.co.za> Saimadhav Heblikar added the comment: Attaching a patch. The file type on OutputWIndow defaults to .txt. Can be very easily made to default to none aswell. Tested on linux for 2.7 and 3.4.(Debian Wheezy, Gnome 3) On 2.7, made changes so that ispythonsource(in EditorWindow) behaves similar to 3.4(in EditorWindow) On both 2.7 and 3.4, made change to ispythonsource(in OutputWindow), to make it return False instead of 0(to mirror behavior in EditorWindow) ---------- keywords: +patch Added file: http://bugs.python.org/file34713/issue21140-27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 18:03:06 2014 From: report at bugs.python.org (Saimadhav Heblikar) Date: Thu, 03 Apr 2014 16:03:06 +0000 Subject: [issue21140] Idle: saving an OutputWindow should default to .txt In-Reply-To: <1396493259.83.0.13428125931.issue21140@psf.upfronthosting.co.za> Message-ID: <1396540986.96.0.988796981478.issue21140@psf.upfronthosting.co.za> Changes by Saimadhav Heblikar : Added file: http://bugs.python.org/file34714/issue21140-34.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 18:13:38 2014 From: report at bugs.python.org (=?utf-8?q?Jurko_Gospodneti=C4=87?=) Date: Thu, 03 Apr 2014 16:13:38 +0000 Subject: [issue21034] Python docs reference the Distribute package which has been deprecated in favor of Setuptools In-Reply-To: <1395564519.98.0.0028723182567.issue21034@psf.upfronthosting.co.za> Message-ID: <1396541618.35.0.465984316861.issue21034@psf.upfronthosting.co.za> Jurko Gospodneti? added the comment: Or, if you do not want to get into the specifics of how to manually install setuptools/pip, it would probably be better to just refer the user to the 'ensurepip' module for the initial installation and tell him to upgrade whatever is needed from there without going in to any further details here. 'ensurepip' module itself is documented elsewhere (https://docs.python.org/3.4/library/ensurepip.html), and that documentation should perhaps be updated to include enough information (or references to external documentation containing that information) for the user to be able to perform the upgrades. Best regards, Jurko Gospodneti? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 18:14:29 2014 From: report at bugs.python.org (Stefan Krah) Date: Thu, 03 Apr 2014 16:14:29 +0000 Subject: [issue17705] Fill Character cannot be \0 In-Reply-To: <1365785695.21.0.22745237494.issue17705@psf.upfronthosting.co.za> Message-ID: <1396541669.42.0.556606029626.issue17705@psf.upfronthosting.co.za> Stefan Krah added the comment: This looks like a duplicate of #12546. ---------- resolution: -> duplicate stage: patch review -> committed/rejected status: open -> closed versions: +Python 3.5 -Python 2.7, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 18:15:23 2014 From: report at bugs.python.org (Stefan Krah) Date: Thu, 03 Apr 2014 16:15:23 +0000 Subject: [issue17705] Fill Character cannot be \0 In-Reply-To: <1365785695.21.0.22745237494.issue17705@psf.upfronthosting.co.za> Message-ID: <1396541723.97.0.248392401529.issue17705@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- superseder: -> builtin __format__ methods cannot fill with \x00 char _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 18:22:16 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Apr 2014 16:22:16 +0000 Subject: [issue12546] builtin __format__ methods cannot fill with \x00 char In-Reply-To: <1310540286.71.0.346156272109.issue12546@psf.upfronthosting.co.za> Message-ID: <1396542136.17.0.510522692221.issue12546@psf.upfronthosting.co.za> STINNER Victor added the comment: #17705 has been closed as a duplicate of this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 18:58:37 2014 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 03 Apr 2014 16:58:37 +0000 Subject: [issue12546] builtin __format__ methods cannot fill with \x00 char In-Reply-To: <1310540286.71.0.346156272109.issue12546@psf.upfronthosting.co.za> Message-ID: <1396544317.63.0.252561092881.issue12546@psf.upfronthosting.co.za> Changes by Eric V. Smith : ---------- versions: +Python 3.4, Python 3.5 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 19:00:34 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Apr 2014 17:00:34 +0000 Subject: [issue19279] UTF-7 to UTF-8 decoding crash In-Reply-To: <1382003736.62.0.288611587107.issue19279@psf.upfronthosting.co.za> Message-ID: <1396544434.88.0.466932033908.issue19279@psf.upfronthosting.co.za> STINNER Victor added the comment: > Georg, is this issue wort to be fixed in 3.2? If yes, use the patch against 2.7. Ping? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 19:07:25 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Apr 2014 17:07:25 +0000 Subject: [issue21147] sqlite3 doesn't complain if the request contains a null character Message-ID: <1396544845.43.0.82545828662.issue21147@psf.upfronthosting.co.za> New submission from STINNER Victor: >>> import sqlite3 >>> c=sqlite3.connect(":memory:") >>> c.execute("select 1") >>> c.execute("select 1").fetchall() [(1,)] >>> c.execute("\0select 1").fetchall() [] ---------- messages: 215459 nosy: haypo priority: normal severity: normal status: open title: sqlite3 doesn't complain if the request contains a null character versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 20:38:00 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 03 Apr 2014 18:38:00 +0000 Subject: [issue21116] Failure to create multiprocessing shared arrays larger than 50% of memory size under linux In-Reply-To: <1396480853.06.0.555216825765.issue21116@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > Also, the FreeBSD man page for mmap() has the following warning: That's mostly important for real file-backed mapping. In our case, we don't want a file-backed mmap: we expect the mapping to fit entirely in memory, so the writeback/read performance isn't that important to us. > Using truncate() to zero extend is not really portable: it is only guaranteed on XSI-compliant POSIX systems. Now that's annoying. How about trying file.truncate() within a try block, and if an error is raised fallback to the zero-filling? Doing a lot of IO for an object which is supposed to be used for shared memory is sad. Or maybe it's time to add an API to access shared memory from Python (since that's really what we're trying to achieve here). > According to the documentation, the returned shared array is zeroed. > In that case because the entire array is written at allocation, the process is expected to get killed > if allocating more memory than available. Unless I am misunderstanding something, which is entirely > possible. Having the memory zero-filed doesn't require a write at all: when you do an anonymous memory mapping for let's say 1Gb, the kernel doesn't pre-emptively zero-fill it, it would be way to slow: usually it just sets up the process page table to make this area a COW of a single zero page: upon read, you'll read zeros, and upon write, it'll duplicate it as needed. The only reason the code currently zero-fills the file is to avoid the portability issues detailed by Richard. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 20:39:32 2014 From: report at bugs.python.org (Julian Taylor) Date: Thu, 03 Apr 2014 18:39:32 +0000 Subject: [issue21148] avoid memset in small tuple creation Message-ID: <1396550372.7.0.587989241442.issue21148@psf.upfronthosting.co.za> New submission from Julian Taylor: attached a prototype patch that avoids the memset of ob_item in PyTuple_New which is not necessary for the BUILD_TUPLE bytecode and PyTuple_Pack as these overwrite every entry in ob_item anyway. This improves small tuple creation by about 5%. It does this by adding a new internal function that does not use the memset loop and wrapping that in PyTuple_New that does it. _Pack and ceval call the internal function. The patch still needs cleanup I don't know where the signature for ceval.c would best go. Does the internal function need to be hidden from the DSO? microbenchmark, compiled with gcc-4.8.2 on ubuntu 14.04 amd64, default configure options: import timeit print(min(timeit.repeat("(a,)", setup="a = 1; b = 1", repeat=5, number=10**7))) print(min(timeit.repeat("(a, b)", setup="a = 1; b = 1", repeat=5, number=10**7))) before: 0.45767 0.52926 after: 0.42652 0.50122 larger tuples do not profit much as the loading is more expensive in comparison. ---------- components: Interpreter Core files: avoid-memset.patch keywords: patch messages: 215461 nosy: jtaylor priority: normal severity: normal status: open title: avoid memset in small tuple creation type: performance versions: Python 3.5 Added file: http://bugs.python.org/file34715/avoid-memset.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 21:11:39 2014 From: report at bugs.python.org (Ned Deily) Date: Thu, 03 Apr 2014 19:11:39 +0000 Subject: [issue21124] _struct module compilation error under Cygwin 1.7.17 on Python 3.4 In-Reply-To: <1396363951.96.0.324613047949.issue21124@psf.upfronthosting.co.za> Message-ID: <1396552299.63.0.0117781074165.issue21124@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: -ned.deily resolution: duplicate -> stage: committed/rejected -> superseder: Add Mingw recognition to pyport.h to allow building extensions -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 21:21:57 2014 From: report at bugs.python.org (Ned Deily) Date: Thu, 03 Apr 2014 19:21:57 +0000 Subject: [issue21034] Python docs reference the Distribute package which has been deprecated in favor of Setuptools In-Reply-To: <1395564519.98.0.0028723182567.issue21034@psf.upfronthosting.co.za> Message-ID: <1396552917.02.0.687420741272.issue21034@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 21:51:54 2014 From: report at bugs.python.org (mattip) Date: Thu, 03 Apr 2014 19:51:54 +0000 Subject: [issue21128] testing stdlib and compatibility with pypy In-Reply-To: <1396390977.66.0.122853817502.issue21128@psf.upfronthosting.co.za> Message-ID: <1396554714.19.0.404467145584.issue21128@psf.upfronthosting.co.za> mattip added the comment: the gc.collect is not needed, sorry. I updated the patch, which affects test_argparse.py (make files rw before rmtree) test_file.py (add file.close() ) test_file2k.py (add file.close() ) test_httpservers.py (add file.close() ) ---------- Added file: http://bugs.python.org/file34716/patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 22:08:22 2014 From: report at bugs.python.org (Zachary Ware) Date: Thu, 03 Apr 2014 20:08:22 +0000 Subject: [issue21141] Don't mention Perl in Windows build output In-Reply-To: <1396496389.49.0.887037786203.issue21141@psf.upfronthosting.co.za> Message-ID: <1396555702.66.0.511424606692.issue21141@psf.upfronthosting.co.za> Zachary Ware added the comment: Here's a slightly revised patch, including documentation changes in PCbuild/readme.txt. Also, this patch doesn't rename build_ssl.(bat|py), so Rietveld should accept the patch as reviewable. I think the renames should actually happen, though. ---------- Added file: http://bugs.python.org/file34717/issue21141.v2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 22:14:00 2014 From: report at bugs.python.org (Stefan Krah) Date: Thu, 03 Apr 2014 20:14:00 +0000 Subject: [issue20361] -W command line options and PYTHONWARNINGS environmental variable should not override -b / -bb command line options In-Reply-To: <1390468789.64.0.236388970509.issue20361@psf.upfronthosting.co.za> Message-ID: <1396556040.22.0.656776206185.issue20361@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 22:14:36 2014 From: report at bugs.python.org (Stefan Krah) Date: Thu, 03 Apr 2014 20:14:36 +0000 Subject: [issue20355] -W command line options should have higher priority than PYTHONWARNINGS environmental variable In-Reply-To: <1390426906.93.0.692922610327.issue20355@psf.upfronthosting.co.za> Message-ID: <1396556076.99.0.385870189399.issue20355@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 22:17:25 2014 From: report at bugs.python.org (Stefan Krah) Date: Thu, 03 Apr 2014 20:17:25 +0000 Subject: [issue19354] test_format fails on RHEL-6 In-Reply-To: <1382466990.37.0.806335115025.issue19354@psf.upfronthosting.co.za> Message-ID: <1396556245.59.0.159185547777.issue19354@psf.upfronthosting.co.za> Stefan Krah added the comment: Is this still an issue? ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 22:19:02 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Thu, 03 Apr 2014 20:19:02 +0000 Subject: [issue20375] ElementTree: Document handling processing instructions In-Reply-To: <1390539216.23.0.0362813865609.issue20375@psf.upfronthosting.co.za> Message-ID: <1396556342.73.0.498414755914.issue20375@psf.upfronthosting.co.za> Nikolaus Rath added the comment: Thanks for the commit! My intention is to fix the behavior itself for 3.5 (see issue 9521), so I think adding testcases for the old behavior in the meantime isn't necessary. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 22:20:57 2014 From: report at bugs.python.org (Devin Jeanpierre) Date: Thu, 03 Apr 2014 20:20:57 +0000 Subject: [issue21149] logging._removeHandlerRef is not threadsafe during interpreter shutdown Message-ID: <1396556457.93.0.286132850658.issue21149@psf.upfronthosting.co.za> New submission from Devin Jeanpierre: If another thread is active during interpreter shutdown, it can hold the last reference to a handler; when it drops that reference, the weakref callback -- _removeHandlerRef -- will be executed in this other thread. So while this callback is running, the main thread is replacing module globals with None. This creates a data race for the globals in logging -- for example, _releaseLock can be replaced with None after the "_releaseLock is not None" check, but before it is used. In principle I suspect this could cause a deadlock, in practice all I've seen are exception messages mentioning how None is not callable. I have attached a patch that I think resolves this issue. The patch is written against 2.7, although I expect this issue affects all versions of Python prior to 3.4 BTW, the copyright for this patch belongs to my employer, Google; please let me know if there are any contributor agreements or such that my employer needs to look at. ---------- components: Library (Lib) files: patch.diff keywords: patch messages: 215466 nosy: Devin Jeanpierre, gregory.p.smith priority: normal severity: normal status: open title: logging._removeHandlerRef is not threadsafe during interpreter shutdown versions: Python 2.7 Added file: http://bugs.python.org/file34718/patch.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 22:24:20 2014 From: report at bugs.python.org (Stefan Krah) Date: Thu, 03 Apr 2014 20:24:20 +0000 Subject: [issue18062] m68k FPU precision issue In-Reply-To: <1369515651.34.0.291697920686.issue18062@psf.upfronthosting.co.za> Message-ID: <1396556660.1.0.913476084556.issue18062@psf.upfronthosting.co.za> Stefan Krah added the comment: Can we somehow merge this issue with #20904? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 22:47:15 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 03 Apr 2014 20:47:15 +0000 Subject: [issue21150] Add quick links table to argparse docs Message-ID: <1396558035.28.0.485991636726.issue21150@psf.upfronthosting.co.za> New submission from Raymond Hettinger: The argparse module has many functions and options. It would benefit from a summary and quick links table at the top of the page just like we have for the itertools module docs and the builtins module docs. ---------- assignee: docs at python components: Documentation keywords: easy messages: 215468 nosy: docs at python, rhettinger priority: normal severity: normal stage: needs patch status: open title: Add quick links table to argparse docs versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 23:04:35 2014 From: report at bugs.python.org (Ned Deily) Date: Thu, 03 Apr 2014 21:04:35 +0000 Subject: [issue21149] logging._removeHandlerRef is not threadsafe during interpreter shutdown In-Reply-To: <1396556457.93.0.286132850658.issue21149@psf.upfronthosting.co.za> Message-ID: <1396559075.99.0.684204747974.issue21149@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 23:06:15 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 03 Apr 2014 21:06:15 +0000 Subject: [issue21148] avoid memset in small tuple creation In-Reply-To: <1396550372.7.0.587989241442.issue21148@psf.upfronthosting.co.za> Message-ID: <1396559175.45.0.131664688315.issue21148@psf.upfronthosting.co.za> Antoine Pitrou added the comment: A 5% improvement on a micro-benchmark probably means 0% on real workloads. You could try to run the benchmarks suite at http://hg.python.org/benchmarks ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 23:35:24 2014 From: report at bugs.python.org (mirabilos) Date: Thu, 03 Apr 2014 21:35:24 +0000 Subject: [issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k In-Reply-To: <1394697296.27.0.543058724281.issue20904@psf.upfronthosting.co.za> Message-ID: <1396560923.99.0.0922885779823.issue20904@psf.upfronthosting.co.za> mirabilos added the comment: Veto on m68k-float-prec.patch for Linux/m68k for now. Reasoning is same as in #18062 (thanks skrah for linking it): Enabling this *will* break Python on Linux/m68k on the most widespread emulator in all released versions of that emulator (ARAnyM) because the emulator does not handle reducing precision correctly. The same applies to all other m68k OSes running in ARAnyM (FreeMiNT comes to mind, I believe it could run Python). I think this could be applied when a released version of ARAnyM that works correctly even with this patch is in, say, Debian oldstable and RHEL, or something like that. The problem here is that this *will* create a run-time issue. (I had prepared a similar patch, but decided to fix the old dtoa code instead due to the emulator issue.) ---------- nosy: +mirabilos _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 23:39:15 2014 From: report at bugs.python.org (Eli Bendersky) Date: Thu, 03 Apr 2014 21:39:15 +0000 Subject: [issue20375] ElementTree: Document handling processing instructions In-Reply-To: <1396556342.73.0.498414755914.issue20375@psf.upfronthosting.co.za> Message-ID: Eli Bendersky added the comment: On Thu, Apr 3, 2014 at 1:19 PM, Nikolaus Rath wrote: > > Nikolaus Rath added the comment: > > Thanks for the commit! > > My intention is to fix the behavior itself for 3.5 (see issue 9521), so I > think adding testcases for the old behavior in the meantime isn't necessary. > Fair enough. So you can close this issue, then. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 23:39:50 2014 From: report at bugs.python.org (Maciej Szulik) Date: Thu, 03 Apr 2014 21:39:50 +0000 Subject: [issue1100942] Add datetime.time.strptime and datetime.date.strptime Message-ID: <1396561190.86.0.342995826674.issue1100942@psf.upfronthosting.co.za> Maciej Szulik added the comment: I've just checked the patch still applies to current HEAD. What about the question regarding 0's in date.strptime(...) I asked in previous comment? I'd like to move this issue forward now when 3.4 is released. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 23:50:40 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Thu, 03 Apr 2014 21:50:40 +0000 Subject: [issue21118] str.translate is absurdly slow in majority of use cases (takes up to 60x longer than similar functions) In-Reply-To: <1396307346.31.0.221715925478.issue21118@psf.upfronthosting.co.za> Message-ID: <1396561840.48.0.951709938773.issue21118@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Hmm... Maybe I'm testing it wrong, but I'm finding your patch is slowing down translation by a small amount on my test case; not a lot, maybe a 10% slowdown on enlarging translations, 6% for 1-1, and deletion in between. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 3 23:53:41 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 03 Apr 2014 21:53:41 +0000 Subject: [issue1100942] Add datetime.time.strptime and datetime.date.strptime Message-ID: <1396562021.84.0.0994382666219.issue1100942@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Is this documentation still valid? +.. staticmethod:: date.strptime(date_string, format) + + Return a :class:`date` corresponding to *date_string*, parsed according to + *format*. This is equivalent to ``date(*(time.strptime(date_string, + format)[0:3]))``. I understand that the latest patch includes checking for time fields in date format. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 00:04:56 2014 From: report at bugs.python.org (Sarah Mount) Date: Thu, 03 Apr 2014 22:04:56 +0000 Subject: [issue14060] Implement a CSP-style channel In-Reply-To: <1329699366.61.0.518357475552.issue14060@psf.upfronthosting.co.za> Message-ID: <1396562696.07.0.541745087724.issue14060@psf.upfronthosting.co.za> Changes by Sarah Mount : ---------- nosy: +snim2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 00:13:16 2014 From: report at bugs.python.org (Andreas Schwab) Date: Thu, 03 Apr 2014 22:13:16 +0000 Subject: [issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k In-Reply-To: <1394697296.27.0.543058724281.issue20904@psf.upfronthosting.co.za> Message-ID: <1396563196.41.0.334854177937.issue20904@psf.upfronthosting.co.za> Andreas Schwab added the comment: > Enabling this *will* break Python on Linux/m68k ??? It will not of course, it will *fix* it. You have no idea what you are talking about. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 00:33:31 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 03 Apr 2014 22:33:31 +0000 Subject: [issue21141] Don't mention Perl in Windows build output In-Reply-To: <1396496389.49.0.887037786203.issue21141@psf.upfronthosting.co.za> Message-ID: <1396564411.24.0.236072380957.issue21141@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Can you please explain what this has to do with dropping the mentioning of Perl? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 00:42:18 2014 From: report at bugs.python.org (mirabilos) Date: Thu, 03 Apr 2014 22:42:18 +0000 Subject: [issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k In-Reply-To: <1396563196.41.0.334854177937.issue20904@psf.upfronthosting.co.za> Message-ID: mirabilos added the comment: Andreas Schwab dixit: >Andreas Schwab added the comment: > >> Enabling this *will* break Python on Linux/m68k > >??? It will not of course, it will *fix* it. You have no idea what you are talking about. No: it will break Debian/m68k which heavily uses Python, because: - on real metal m68k, the asm function will be tested and work, so it will be used, including the new dtoa code - the binaries with that will be uploaded to the archive - now, on emulated m68k (ARAnyM), those binaries will use the new dtoa code instrad of the old one, but the asm instructions to change FPU precision will SILENTLY FAIL, which will lead to incorrect results bye, //mirabilos -- exceptions: a truly awful implementation of quite a nice idea. just about the worst way you could do something like that, afaic. it's like anti-design. that too? may I quote you on that? sure, tho i doubt anyone will listen ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 00:46:06 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 03 Apr 2014 22:46:06 +0000 Subject: [issue21128] testing stdlib and compatibility with pypy In-Reply-To: <1396390977.66.0.122853817502.issue21128@psf.upfronthosting.co.za> Message-ID: <1396565166.32.0.593972556203.issue21128@psf.upfronthosting.co.za> Benjamin Peterson added the comment: This patch appears to have been generated against a pypy checkout rather than a cpython checkout. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 01:06:07 2014 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 03 Apr 2014 23:06:07 +0000 Subject: [issue21149] logging._removeHandlerRef is not threadsafe during interpreter shutdown In-Reply-To: <1396556457.93.0.286132850658.issue21149@psf.upfronthosting.co.za> Message-ID: <1396566367.17.0.0457318580352.issue21149@psf.upfronthosting.co.za> Vinay Sajip added the comment: > please let me know if there are any contributor agreements Yes, there is a contributor agreement form which needs to be completed and signed: https://www.python.org/psf/contrib/contrib-form-python/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 01:18:33 2014 From: report at bugs.python.org (Andreas Schwab) Date: Thu, 03 Apr 2014 23:18:33 +0000 Subject: [issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k In-Reply-To: <1394697296.27.0.543058724281.issue20904@psf.upfronthosting.co.za> Message-ID: <1396567113.31.0.223625286777.issue20904@psf.upfronthosting.co.za> Andreas Schwab added the comment: There is no excuse for using a broken emulator. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 01:28:44 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 03 Apr 2014 23:28:44 +0000 Subject: [issue21116] Failure to create multiprocessing shared arrays larger than 50% of memory size under linux In-Reply-To: <1396294667.97.0.287941619482.issue21116@psf.upfronthosting.co.za> Message-ID: <1396567724.63.0.315747553611.issue21116@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Or maybe it's time to add an API to access shared memory from Python > (since > that's really what we're trying to achieve here). That sounds like a good idea. Especially since we now have the memoryview type. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 01:42:21 2014 From: report at bugs.python.org (mirabilos) Date: Thu, 03 Apr 2014 23:42:21 +0000 Subject: [issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k In-Reply-To: <1396567113.31.0.223625286777.issue20904@psf.upfronthosting.co.za> Message-ID: mirabilos added the comment: Andreas Schwab dixit: >There is no excuse for using a broken emulator. Sure, if nobody releases a fixed version? and even then, there?s got to be a grace period. I say that if you break ARAnyM you kill off Debian/m68k on ARAnyM (and I?ll have to shut down my buildd, too). > bye, //mirabilos -- Beware of ritual lest you forget the meaning behind it. yeah but it means if you really care about something, don't ritualise it, or you will lose it. don't fetishise it, don't obsess. or you'll forget why you love it in the first place. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 02:05:10 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Fri, 04 Apr 2014 00:05:10 +0000 Subject: [issue20375] ElementTree: Document handling processing instructions In-Reply-To: <1390539216.23.0.0362813865609.issue20375@psf.upfronthosting.co.za> Message-ID: <1396569910.38.0.834908928713.issue20375@psf.upfronthosting.co.za> Changes by Nikolaus Rath : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 02:18:06 2014 From: report at bugs.python.org (Devin Jeanpierre) Date: Fri, 04 Apr 2014 00:18:06 +0000 Subject: [issue21149] logging._removeHandlerRef is not threadsafe during interpreter shutdown In-Reply-To: <1396556457.93.0.286132850658.issue21149@psf.upfronthosting.co.za> Message-ID: <1396570686.26.0.485790516706.issue21149@psf.upfronthosting.co.za> Devin Jeanpierre added the comment: Are you sure? There should have been many previous contributions by Google, so the relevant copyright agreements _should_ have already been signed. I asked internally and was told that a corporate version of this agreement had been signed a long time ago. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 03:12:09 2014 From: report at bugs.python.org (R. David Murray) Date: Fri, 04 Apr 2014 01:12:09 +0000 Subject: [issue21149] logging._removeHandlerRef is not threadsafe during interpreter shutdown In-Reply-To: <1396556457.93.0.286132850658.issue21149@psf.upfronthosting.co.za> Message-ID: <1396573929.42.0.359110439561.issue21149@psf.upfronthosting.co.za> R. David Murray added the comment: Yes, I remember previous discussions of the corporate agreement from Google, so I'm sure it exists. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 05:09:05 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 04 Apr 2014 03:09:05 +0000 Subject: [issue21140] Idle: saving an OutputWindow should default to .txt In-Reply-To: <1396493259.83.0.13428125931.issue21140@psf.upfronthosting.co.za> Message-ID: <1396580945.45.0.437134443923.issue21140@psf.upfronthosting.co.za> Raymond Hettinger added the comment: FWIW, students commonly save shell sessions as a record of everything they tried in call. It would nice if there were a way to trigger a periodic autosave (perhaps every five minutes or so). ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 05:17:01 2014 From: report at bugs.python.org (Dave Odell) Date: Fri, 04 Apr 2014 03:17:01 +0000 Subject: [issue21151] winreg.SetValueEx causes crash if value = None Message-ID: <1396581421.46.0.554143633373.issue21151@psf.upfronthosting.co.za> New submission from Dave Odell: Here's a small program that crashes Python 3. import winreg winreg.SetValueEx(winreg.HKEY_CURRENT_USER, 'Value', 0, 3, None) I get a 0xC0000374 exception (STATUS_HEAP_CORRUPTION) when trying to run this. Here's a stack dump: (snip) ntdll.dll!RtlpLogHeapFailure+0xa4 ntdll.dll! ?? ::FNODOBFM::`string'+0x10c7c kernel32.dll!HeapFree+0xa MSVCR100.dll!free+0x1c python34.dll!PySetValueEx+0xf8 python34.dll!PyCFunction_Call+0x12d python34.dll!call_function+0x2ab python34.dll!PyEval_EvalFrameEx+0x2259 python34.dll!PyEval_EvalCodeEx+0x65c python34.dll!PyEval_EvalCode+0x2e python34.dll!builtin_exec+0x1b5 python34.dll!PyCFunction_Call+0x12d python34.dll!call_function+0x2ab python34.dll!PyEval_EvalFrameEx+0x2259 python34.dll!PyEval_EvalCodeEx+0x65c python34.dll!function_call+0x15d python34.dll!PyObject_Call+0x61 python34.dll!ext_do_call+0x2ab python34.dll!PyEval_EvalFrameEx+0x22fe python34.dll!PyEval_EvalCodeEx+0x65c python34.dll!fast_function+0x14d python34.dll!call_function+0x311 python34.dll!PyEval_EvalFrameEx+0x2259 python34.dll!PyEval_EvalCodeEx+0x65c python34.dll!PyEval_EvalCode+0x2e python34.dll!run_mod+0x53 python34.dll!PyRun_StringFlags+0x9c python34.dll!PyRun_SimpleStringFlags+0x41 python34.dll!run_command+0x55 python34.dll!Py_Main+0x683 pythonw.exe!__tmainCRTStartup+0x166 kernel32.dll!BaseThreadInitThunk+0xd ntdll.dll!RtlUserThreadStart+0x1d System is Windows 7 64-bit, with stock x86-64 Python 3.4.0 binaries. Incidentally, I was feeding the 'None' to winreg.SetValueEx because that is the value that winreg.EnumValue returns for zero-length binary values. This is somewhat unexpected; I'd personally prefer to get b'' in that instance. ---------- components: Library (Lib), Windows messages: 215486 nosy: dmo2118, stutzbach priority: normal severity: normal status: open title: winreg.SetValueEx causes crash if value = None type: crash versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 05:23:39 2014 From: report at bugs.python.org (Zachary Ware) Date: Fri, 04 Apr 2014 03:23:39 +0000 Subject: [issue21141] Don't mention Perl in Windows build output In-Reply-To: <1396496389.49.0.887037786203.issue21141@psf.upfronthosting.co.za> Message-ID: <1396581819.4.0.66664032912.issue21141@psf.upfronthosting.co.za> Zachary Ware added the comment: Sure; currently, the "ssl" project emits messages from build_ssl.py concerning the finding of Perl. On a machine with a usable Perl, it's just " Found a working perl at 'C:\Perl\bin\perl.exe'" On machines without Perl, its the more worrisome """ Can not find a suitable PERL: NO perl interpreters were found on this machine at all! Please install ActivePerl and ensure it appears on your path No Perl installation was found. Existing Makefiles are used. """ The last line of that message (and the fact that the ssl-related projects build ok anyway, if using source from svn.python.org) ought to make it clear that Perl really isn't necessary, but removing the messages entirely removes the possibility of misunderstanding. The messages are still useful if you actually need the preparation part of build_ssl.py, though, so I don't want to just remove them from the script. Divorcing the building from the preparation has other benefits as well, which IMO would stand on their own, but that wasn't my main goal here. As for the brief discussion of Perl that remains in readme.txt, I think it should stay as long as we include a mention of how to use non-svn.python.org sources, just so that anyone needing to do a non-standard build will have some warning. On the other hand, readme.txt could just give the script invocation, and leave it up to the script to recommend Perl if it's not available. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 05:42:29 2014 From: report at bugs.python.org (Madison May) Date: Fri, 04 Apr 2014 03:42:29 +0000 Subject: [issue21145] Add the @cached_property decorator In-Reply-To: <1396520932.53.0.707047361064.issue21145@psf.upfronthosting.co.za> Message-ID: <1396582949.73.0.698821697988.issue21145@psf.upfronthosting.co.za> Madison May added the comment: There's currently an example of a cached property decorator implementation in the wiki, although it doesn't leverage functools: https://wiki.python.org/moin/PythonDecoratorLibrary#Cached_Properties ---------- nosy: +madison.may _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 07:02:02 2014 From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=) Date: Fri, 04 Apr 2014 05:02:02 +0000 Subject: [issue17390] display python version on idle title bar In-Reply-To: <1362920194.83.0.464215113749.issue17390@psf.upfronthosting.co.za> Message-ID: <1396587722.79.0.334476129834.issue17390@psf.upfronthosting.co.za> Westley Mart?nez added the comment: I second that the title should start with the filename, by default. This seems to be the precedent, and it makes it easy when working with multiple files. Example: xxx.py - IDLE x.y.z: C:\mydir\xxx.py Terry, I think we can generalize this as ' - : ' and apply it to all windows. The first element essentially guarantees that the title name will be a good one for the taskbar. We can apply this to say the FIF output window: Matches for "hello" - IDLE x.y.z: C:\output.txt but maybe everything after the hyphen isn't necessary. I wonder if long titles could be annoying or distracting. Regardless, anything more specific than 'Output Window' will be better. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 07:28:56 2014 From: report at bugs.python.org (eryksun) Date: Fri, 04 Apr 2014 05:28:56 +0000 Subject: [issue21151] winreg.SetValueEx causes crash if value = None In-Reply-To: <1396581421.46.0.554143633373.issue21151@psf.upfronthosting.co.za> Message-ID: <1396589336.74.0.972755397546.issue21151@psf.upfronthosting.co.za> eryksun added the comment: In Py2Reg, the REG_BINARY (3) case sets `*retDataSize = 0` when the value is None: http://hg.python.org/cpython/file/04f714765c13/PC/winreg.c#l766 It doesn't modify *retDataBuf. Then in PySetValueEx, PyMem_DEL is called for the uninitialized address in data: http://hg.python.org/cpython/file/04f714765c13/PC/winreg.c#l1566 Py2Reg in this case could also set `*retDataBuf = NULL`. RegSetValueEx allows lpData to be NULL when cbData is 0. http://msdn.microsoft.com/en-us/library/ms724923 ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 07:45:52 2014 From: report at bugs.python.org (Maciej Szulik) Date: Fri, 04 Apr 2014 05:45:52 +0000 Subject: [issue1100942] Add datetime.time.strptime and datetime.date.strptime Message-ID: <1396590352.68.0.0552506630691.issue1100942@psf.upfronthosting.co.za> Maciej Szulik added the comment: Alexander yes it's correct. It's checking for time part in date.strptime and for time part in time.strptime. The only problem I came into is that when passing 0 hours or 0 minutes into date.strptime it won't raise an exception, though doc explicitly says: "(...) ValueError is raised if the date string (...) the time part is nonzero". So I'm not sure whether this is enough or should I add additional checks if time part was set? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 08:01:19 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 04 Apr 2014 06:01:19 +0000 Subject: [issue21136] fractions.Fraction.__pow__ does unneeded renormalization In-Reply-To: <1396482750.35.0.873465877702.issue21136@psf.upfronthosting.co.za> Message-ID: <1396591279.83.0.215043722584.issue21136@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Thanks Mark, that is an excellent suggestion. ---------- Added file: http://bugs.python.org/file34719/fraction_pow2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 08:34:34 2014 From: report at bugs.python.org (Christian Clauss) Date: Fri, 04 Apr 2014 06:34:34 +0000 Subject: [issue20969] Author of EPUB version of Python docs is set to Unknown instead of PSF In-Reply-To: <1395153249.12.0.327856107433.issue20969@psf.upfronthosting.co.za> Message-ID: <1396593274.18.0.674979582544.issue20969@psf.upfronthosting.co.za> Christian Clauss added the comment: Makefile and make.bat in https://github.com/python/pythondotorg/blob/master/docs are NOT the correct files to modify. It is unclear to where the correct files are. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 08:52:06 2014 From: report at bugs.python.org (=?utf-8?b?TcOpZMOpcmljIEJvcXVpZW4=?=) Date: Fri, 04 Apr 2014 06:52:06 +0000 Subject: [issue21116] Failure to create multiprocessing shared arrays larger than 50% of memory size under linux In-Reply-To: <1396294667.97.0.287941619482.issue21116@psf.upfronthosting.co.za> Message-ID: <1396594326.06.0.320486688012.issue21116@psf.upfronthosting.co.za> M?d?ric Boquien added the comment: Thanks for the explanations Charles-Fran?ois. I guess the new API would not be before 3.5 at least. Is there still a chance to integrate my patch (or any other) to improve the situation for the 3.4 series though? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 08:55:45 2014 From: report at bugs.python.org (Andreas Schwab) Date: Fri, 04 Apr 2014 06:55:45 +0000 Subject: [issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k In-Reply-To: (Finn Thain's message of "Fri, 4 Apr 2014 11:16:02 +1100 (EST)") Message-ID: <87zjk1fus1.fsf@igel.home> Andreas Schwab added the comment: Finn Thain writes: > until Aranym gets fixed. Aranym *is* fixed. Andreas. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 09:01:28 2014 From: report at bugs.python.org (Berker Peksag) Date: Fri, 04 Apr 2014 07:01:28 +0000 Subject: [issue20375] ElementTree: Document handling processing instructions In-Reply-To: <1390539216.23.0.0362813865609.issue20375@psf.upfronthosting.co.za> Message-ID: <1396594888.72.0.628314028402.issue20375@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> fixed stage: -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 09:01:56 2014 From: report at bugs.python.org (Josiah Carlson) Date: Fri, 04 Apr 2014 07:01:56 +0000 Subject: [issue1191964] asynchronous Subprocess Message-ID: <1396594916.93.0.389885499049.issue1191964@psf.upfronthosting.co.za> Josiah Carlson added the comment: Quick update before I head to bed. Thank you for the input, I had gotten the individual async calls working a couple days ago, and I was just working to replace the communicate() method for Windows. Yes, I'm using asyncio._overlapped, though asyncio uses subprocessing, so I needed to defer import of _overlapped until one of a couple crucial methods were being called in order to prevent issues relating to circular imports. I also ended up moving asyncio.windows_utils.pipe out to subprocess, as copying/pasting it for a third 'create an overlapped-io pipe' implementation for the standard library just doesn't make a lot of sense, and another circular import seemed like a bad idea. If/when subprocess goes away completely, someone else can move the function back. With overlapped IOs able to be cancelled, it's not all that bad to make a completely re-entrant communicate() without threads, though I made a few mistakes in my first pass tonight that I need to fix tomorrow. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 10:04:44 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 04 Apr 2014 08:04:44 +0000 Subject: [issue19491] Python Crashing When Saving Documents In-Reply-To: <1383558941.35.0.744248647996.issue19491@psf.upfronthosting.co.za> Message-ID: <1396598684.01.0.710832264873.issue19491@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I am closing this on the theory that the problem has been fixed by one of the many crash fixers since 3.2. There is certainly insufficient information to act on. Currently, a problem would have to be demonstrated with 3.4 (or possible 2.7). ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 10:06:20 2014 From: report at bugs.python.org (mirabilos) Date: Fri, 04 Apr 2014 08:06:20 +0000 Subject: [issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k In-Reply-To: <87zjk1fus1.fsf@igel.home> Message-ID: mirabilos added the comment: Andreas Schwab dixit: >Finn Thain writes: > >>Sorry, what? You seek to veto an upstream Python bug fix because it will >>lead to correct binaries that a certain emulator can't handle? That Yes, because of the value ARAnyM has for Linux/m68k development and especially testing ? for example, considering that there are no porterboxen, we can, currently, just tell people needing one to install a VM themselves, and even provide images from which to start. >>Furthermore, Andreas' bug fix was to be merged for python 3.5. Debian is >>not obliged to use that version with that patch up until Aranym gets Debian is consistent across architectures. (Well, mostly.) This patch changes a known-good but less optimal behaviour (using the old dtoa routines) by behaviour that matches the other architectures even better but only iff the FPU (FPU emulation) supports changing precision. Which it didn?t last time I looked. >>fixed. > >Aranym *is* fixed. What *precise* version of ARAnyM is the first to have been released with a fix for this issue? I never got any response to my message to upstream in which I asked for a release: (No response *at all*, mind you. Not even an ACK or ?no?.) Once we do have a fixed version, we can communicate that around. (Note that ?have? includes having e.g. backports to stable and several old *buntu versions at least.) bye, //mirabilos -- exceptions: a truly awful implementation of quite a nice idea. just about the worst way you could do something like that, afaic. it's like anti-design. that too? may I quote you on that? sure, tho i doubt anyone will listen ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 10:13:06 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 04 Apr 2014 08:13:06 +0000 Subject: [issue21152] Idle: timed autosave for shell (and maybe editor) window Message-ID: <1396599186.38.0.494576293163.issue21152@psf.upfronthosting.co.za> New submission from Terry J. Reedy: >From #21140, msg215485, Raymond Hettinger: "Students commonly save shell sessions as a record of everything they tried in call. It would nice if there were a way to trigger a periodic autosave (perhaps every five minutes or so)." ---------- components: IDLE messages: 215499 nosy: terry.reedy priority: normal severity: normal stage: needs patch status: open title: Idle: timed autosave for shell (and maybe editor) window type: enhancement versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 10:15:24 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 04 Apr 2014 08:15:24 +0000 Subject: [issue21140] Idle: saving an OutputWindow should default to .txt In-Reply-To: <1396493259.83.0.13428125931.issue21140@psf.upfronthosting.co.za> Message-ID: <1396599324.1.0.00684453048791.issue21140@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Raymond, I open #21152 with your idea. #11838 and #19042 are somewhat related but timed autosave is not a part of either. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 10:21:12 2014 From: report at bugs.python.org (Andreas Schwab) Date: Fri, 04 Apr 2014 08:21:12 +0000 Subject: [issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k In-Reply-To: (Thorsten Glaser's message of "Fri, 4 Apr 2014 08:00:31 +0000 (UTC)") Message-ID: <87siptfqtl.fsf@igel.home> Andreas Schwab added the comment: The fixed version is here: git://git.code.sf.net/p/aranym/code Andreas. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 10:29:07 2014 From: report at bugs.python.org (mattip) Date: Fri, 04 Apr 2014 08:29:07 +0000 Subject: [issue21128] testing stdlib and compatibility with pypy In-Reply-To: <1396390977.66.0.122853817502.issue21128@psf.upfronthosting.co.za> Message-ID: <1396600147.0.0.405142299598.issue21128@psf.upfronthosting.co.za> mattip added the comment: Correct, the other patches were against pypy, sorry. I now patched and tested against banch 2.7 on the python tree. ---------- Added file: http://bugs.python.org/file34720/patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 11:18:15 2014 From: report at bugs.python.org (Stefan Krah) Date: Fri, 04 Apr 2014 09:18:15 +0000 Subject: [issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k In-Reply-To: <1394697296.27.0.543058724281.issue20904@psf.upfronthosting.co.za> Message-ID: <1396603095.6.0.504893954867.issue20904@psf.upfronthosting.co.za> Stefan Krah added the comment: If the asm instructions silently fail, I'd say add a test to ./configure that detects the broken versions of the emulator in question. Or don't bother and tell people to use the proper version of the emulator. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 11:37:12 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 04 Apr 2014 09:37:12 +0000 Subject: [issue20969] Author of EPUB version of Python docs is set to Unknown instead of PSF In-Reply-To: <1395153249.12.0.327856107433.issue20969@psf.upfronthosting.co.za> Message-ID: <1396604232.56.0.223321385502.issue20969@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The PSF is not the author of the docs. Perhaps something like "Python documentation authors". ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 11:39:23 2014 From: report at bugs.python.org (Andreas Schwab) Date: Fri, 04 Apr 2014 09:39:23 +0000 Subject: [issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k In-Reply-To: <1394697296.27.0.543058724281.issue20904@psf.upfronthosting.co.za> Message-ID: <1396604363.58.0.0904944149953.issue20904@psf.upfronthosting.co.za> Andreas Schwab added the comment: There is nothing that fails. The emulator has always correctly implemented the insn. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 11:40:09 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 04 Apr 2014 09:40:09 +0000 Subject: [issue21128] testing stdlib and compatibility with pypy In-Reply-To: <1396390977.66.0.122853817502.issue21128@psf.upfronthosting.co.za> Message-ID: <1396604409.74.0.373245469298.issue21128@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I'm wondering why resource warnings are not raised in CPython? ./python -Werror -bb -m test.regrtest -uall test_argparse test_file test_httpservers ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 11:57:44 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 04 Apr 2014 09:57:44 +0000 Subject: [issue21149] logging._removeHandlerRef is not threadsafe during interpreter shutdown In-Reply-To: <1396556457.93.0.286132850658.issue21149@psf.upfronthosting.co.za> Message-ID: <3g0c5M6pNRz7Lk9@mail.python.org> Roundup Robot added the comment: New changeset b6deab7204e6 by Vinay Sajip in branch '2.7': Issue #21149: Improved thread-safety in logging cleanup during interpreter shutdown. http://hg.python.org/cpython/rev/b6deab7204e6 New changeset b5c91b61991a by Vinay Sajip in branch '3.4': Issue #21149: Improved thread-safety in logging cleanup during interpreter shutdown. http://hg.python.org/cpython/rev/b5c91b61991a New changeset 76689a706900 by Vinay Sajip in branch 'default': Closes #21149: Improved thread-safety in logging cleanup during interpreter shutdown. http://hg.python.org/cpython/rev/76689a706900 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 12:33:36 2014 From: report at bugs.python.org (Jason R. Coombs) Date: Fri, 04 Apr 2014 10:33:36 +0000 Subject: [issue21153] bdist_rpm fails if project contains files with spaces in the names Message-ID: <1396607616.44.0.695495728794.issue21153@psf.upfronthosting.co.za> New submission from Jason R. Coombs: In https://bitbucket.org/pypa/setuptools/issue/178, Eduard reported an issue that setuptools fails to install due to files in its structure with spaces in the filenames. These files have been around for some time (over two years in Distribute), but are now revealing a limitation in bdist_rpm. The aforementioned ticket demonstrates the issue, and I will be providing a script to replicate the failure shortly. ---------- components: Distutils messages: 215508 nosy: dstufft, eric.araujo, jason.coombs priority: normal severity: normal status: open title: bdist_rpm fails if project contains files with spaces in the names versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 13:00:49 2014 From: report at bugs.python.org (Jason R. Coombs) Date: Fri, 04 Apr 2014 11:00:49 +0000 Subject: [issue21153] bdist_rpm fails if project contains files with spaces in the names In-Reply-To: <1396607616.44.0.695495728794.issue21153@psf.upfronthosting.co.za> Message-ID: <1396609249.04.0.0574642087884.issue21153@psf.upfronthosting.co.za> Jason R. Coombs added the comment: The attached script (issue21153.py) replicates the failure in a Unix environment with the 'rpm' command present. ---------- Added file: http://bugs.python.org/file34721/issue21153.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 13:33:12 2014 From: report at bugs.python.org (Thomas Heller) Date: Fri, 04 Apr 2014 11:33:12 +0000 Subject: [issue21130] equivalent functools.partial instances should compare equal In-Reply-To: <1396425472.15.0.80240218298.issue21130@psf.upfronthosting.co.za> Message-ID: <1396611192.66.0.877495655671.issue21130@psf.upfronthosting.co.za> Thomas Heller added the comment: My usecase is: I create kind of bound methods with functools.partial. Apologies for the confusion by using the word 'equivalent'; what I mean is that partial instances should (IMO) compare equal when they contain the same function and args/keywords which compare equal. I guess functools.partialmethod has the same problem and I would suggest the same fix/enhancement but I have not used them yet because I have to write python2/3 compatible code. Anyway; if this behaviour is not seen as a bug then it is probably python-ideas material, but I'm too tired to start a discussion there atm. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 13:46:41 2014 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Fri, 04 Apr 2014 11:46:41 +0000 Subject: [issue17522] Add api PyGILState_Check In-Reply-To: <1363971850.69.0.260738118944.issue17522@psf.upfronthosting.co.za> Message-ID: <1396612001.81.0.38881833308.issue17522@psf.upfronthosting.co.za> Changes by Kristj?n Valur J?nsson : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 13:47:25 2014 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Fri, 04 Apr 2014 11:47:25 +0000 Subject: [issue16475] Support object instancing and recursion in marshal In-Reply-To: <1352969678.69.0.685980330217.issue16475@psf.upfronthosting.co.za> Message-ID: <1396612045.04.0.538110609979.issue16475@psf.upfronthosting.co.za> Changes by Kristj?n Valur J?nsson : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 13:50:12 2014 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Fri, 04 Apr 2014 11:50:12 +0000 Subject: [issue17969] multiprocessing crash on exit In-Reply-To: <1368444694.56.0.376585959821.issue17969@psf.upfronthosting.co.za> Message-ID: <1396612212.3.0.971523130458.issue17969@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Closing this as won-t fix. Exiting with running threads is a can of worms. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 13:57:36 2014 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Fri, 04 Apr 2014 11:57:36 +0000 Subject: [issue8410] Fix emulated lock to be 'fair' In-Reply-To: <1271361646.51.0.206027864382.issue8410@psf.upfronthosting.co.za> Message-ID: <1396612656.01.0.363602350913.issue8410@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Closing this issue. It is largely superseded. For our Python 2.7 branches, we have a custom "GIL" lock which can have different inherent semantics from the common "Lock". In particular, we can implement a "fair" PyGIL_Handoff() function to be used to yield the GIL to a waiting thread. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 13:57:51 2014 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Fri, 04 Apr 2014 11:57:51 +0000 Subject: [issue8410] Fix emulated lock to be 'fair' In-Reply-To: <1271361646.51.0.206027864382.issue8410@psf.upfronthosting.co.za> Message-ID: <1396612671.77.0.987065875539.issue8410@psf.upfronthosting.co.za> Changes by Kristj?n Valur J?nsson : ---------- resolution: -> rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 13:58:38 2014 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Fri, 04 Apr 2014 11:58:38 +0000 Subject: [issue17969] multiprocessing crash on exit In-Reply-To: <1368444694.56.0.376585959821.issue17969@psf.upfronthosting.co.za> Message-ID: <1396612718.64.0.734731424851.issue17969@psf.upfronthosting.co.za> Changes by Kristj?n Valur J?nsson : ---------- resolution: -> wont fix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 13:58:58 2014 From: report at bugs.python.org (Jason R. Coombs) Date: Fri, 04 Apr 2014 11:58:58 +0000 Subject: [issue21153] bdist_rpm fails if project contains files with spaces in the names In-Reply-To: <1396607616.44.0.695495728794.issue21153@psf.upfronthosting.co.za> Message-ID: <1396612738.12.0.645195967094.issue21153@psf.upfronthosting.co.za> Jason R. Coombs added the comment: I tried using the --install-script hook of the bdist_rpm command to update the INSTALLED_FILES listing to wrap them in quotes, but that doesn't help: http://paste.jaraco.com/uNMrQ I also delved into the RPM docs, which don't provide any guidance other than to put one file per line. I now believe that this is a bug in RPM and there's nothing that can be done in distutils to work around the issue. ---------- Added file: http://bugs.python.org/file34722/issue21153.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 14:02:15 2014 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Fri, 04 Apr 2014 12:02:15 +0000 Subject: [issue17522] Add api PyGILState_Check In-Reply-To: <1363971850.69.0.260738118944.issue17522@psf.upfronthosting.co.za> Message-ID: <1396612935.14.0.124128780924.issue17522@psf.upfronthosting.co.za> Changes by Kristj?n Valur J?nsson : ---------- resolution: -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 14:21:05 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 04 Apr 2014 12:21:05 +0000 Subject: [issue19505] OrderedDict views don't implement __reversed__ In-Reply-To: <1383668278.19.0.898064141243.issue19505@psf.upfronthosting.co.za> Message-ID: <3g0gGn2b98z7Lk0@mail.python.org> Roundup Robot added the comment: New changeset cee010fecdf5 by Serhiy Storchaka in branch 'default': Issue #19505: The items, keys, and values views of OrderedDict now support http://hg.python.org/cpython/rev/cee010fecdf5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 14:46:31 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 04 Apr 2014 12:46:31 +0000 Subject: [issue20636] Better repr for tkinter widgets In-Reply-To: <1392465181.79.0.530455860021.issue20636@psf.upfronthosting.co.za> Message-ID: <3g0gr715tpz7LkK@mail.python.org> Roundup Robot added the comment: New changeset 66770f126c71 by Serhiy Storchaka in branch 'default': Issue #20636: Improved the repr of Tkinter widgets. http://hg.python.org/cpython/rev/66770f126c71 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 14:47:57 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 04 Apr 2014 12:47:57 +0000 Subject: [issue19505] OrderedDict views don't implement __reversed__ In-Reply-To: <1383668278.19.0.898064141243.issue19505@psf.upfronthosting.co.za> Message-ID: <1396615677.52.0.0719007062331.issue19505@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Done. Thank you Raymond for your review. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 15:00:04 2014 From: report at bugs.python.org (Armin Rigo) Date: Fri, 04 Apr 2014 13:00:04 +0000 Subject: [issue21154] Small fix in 2.7.6 lang ref Message-ID: <1396616403.97.0.334401802689.issue21154@psf.upfronthosting.co.za> New submission from Armin Rigo: The docs still say that the default __hash__() is equal to id(), but that's not the case since Python 2.7. ---------- assignee: docs at python components: Documentation files: lang-ref-fix.diff keywords: patch messages: 215517 nosy: arigo, docs at python priority: normal severity: normal status: open title: Small fix in 2.7.6 lang ref versions: Python 2.7 Added file: http://bugs.python.org/file34723/lang-ref-fix.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 15:10:12 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 04 Apr 2014 13:10:12 +0000 Subject: [issue19655] Replace the ASDL parser carried with CPython In-Reply-To: <1384869696.09.0.547082157855.issue19655@psf.upfronthosting.co.za> Message-ID: <1396617012.78.0.171940980086.issue19655@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Now make fails when system Python is older than 3.4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 15:19:20 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 04 Apr 2014 13:19:20 +0000 Subject: [issue13968] Support recursive globs In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za> Message-ID: <1396617560.38.0.68525305796.issue13968@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +needs review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 15:25:37 2014 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Fri, 04 Apr 2014 13:25:37 +0000 Subject: [issue16475] Support object instancing and recursion in marshal In-Reply-To: <1352969678.69.0.685980330217.issue16475@psf.upfronthosting.co.za> Message-ID: <1396617937.69.0.0504183046037.issue16475@psf.upfronthosting.co.za> Changes by Kristj?n Valur J?nsson : ---------- resolution: -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 15:34:28 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 04 Apr 2014 13:34:28 +0000 Subject: [issue21076] Turn signal.SIG* constants into enums In-Reply-To: <1395935330.94.0.38028035584.issue21076@psf.upfronthosting.co.za> Message-ID: <3g0hvR1ym0z7LjM@mail.python.org> Roundup Robot added the comment: New changeset c9239171e429 by Giampaolo Rodola' in branch 'default': fix #21076: turn signal module constants into enums http://hg.python.org/cpython/rev/c9239171e429 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 15:35:20 2014 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Fri, 04 Apr 2014 13:35:20 +0000 Subject: [issue15139] Speed up threading.Condition wakeup In-Reply-To: <1340379512.47.0.965576630558.issue15139@psf.upfronthosting.co.za> Message-ID: <1396618520.69.0.257823774694.issue15139@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: In our 2.7 branches, this approach has been superseded with a natively impolemented _Condition class. This is even more efficient. It is available if the underlying Lock implementation is based on pthread locks (not semaphores). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 15:50:26 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 04 Apr 2014 13:50:26 +0000 Subject: [issue21076] Turn signal.SIG* constants into enums In-Reply-To: <1395935330.94.0.38028035584.issue21076@psf.upfronthosting.co.za> Message-ID: <1396619426.33.0.59215512444.issue21076@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: http://buildbot.python.org/all/builders/AMD64%20Ubuntu%20LTS%203.x/builds/4131/steps/compile/logs/stdio gcc -pthread -Xlinker -export-dynamic -o Modules/_testembed Modules/_testembed.o libpython3.5dm.a -lpthread -ldl -lutil -lm libpython3.5dm.a(config.o):(.data+0x18): undefined reference to `PyInit_signal' collect2: ld returned 1 exit status make: *** [Modules/_testembed] Error 1 ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 15:50:46 2014 From: report at bugs.python.org (Jonas Wagner) Date: Fri, 04 Apr 2014 13:50:46 +0000 Subject: [issue21122] CPython fails to build modules with LLVM LTO on Mac OS X In-Reply-To: <1396354260.96.0.514432416417.issue21122@psf.upfronthosting.co.za> Message-ID: <1396619446.04.0.634581524072.issue21122@psf.upfronthosting.co.za> Jonas Wagner added the comment: I confirm that this also works with my self-compiled Clang 3.4. -export_dynamic was the missing option. Is a good place to document this? Otherwise, I think this issue can be closed. Thanks a lot for the help! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 15:59:56 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 04 Apr 2014 13:59:56 +0000 Subject: [issue21154] Small fix in 2.7.6 lang ref In-Reply-To: <1396616403.97.0.334401802689.issue21154@psf.upfronthosting.co.za> Message-ID: <3g0jSq3ShpzT1f@mail.python.org> Roundup Robot added the comment: New changeset 6809b434752a by Benjamin Peterson in branch '2.7': note that the hash of an arbitrary object is only derived from its address (closes #21154) http://hg.python.org/cpython/rev/6809b434752a ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 16:20:36 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 04 Apr 2014 14:20:36 +0000 Subject: [issue20942] _frozen_importlib should not have a __file__ attribute In-Reply-To: <1394948547.33.0.586299720319.issue20942@psf.upfronthosting.co.za> Message-ID: <3g0jwg6hFnz7Lkk@mail.python.org> Roundup Robot added the comment: New changeset fef890bd60b1 by Brett Cannon in branch '3.4': Issue #20942: PyImport_ImportFrozenModuleObject() no longer sets http://hg.python.org/cpython/rev/fef890bd60b1 New changeset a11ec7aaac10 by Brett Cannon in branch 'default': merge of fix for issue #20942 http://hg.python.org/cpython/rev/a11ec7aaac10 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 16:20:42 2014 From: report at bugs.python.org (Georg Brandl) Date: Fri, 04 Apr 2014 14:20:42 +0000 Subject: [issue20969] Author of EPUB version of Python docs is set to Unknown instead of PSF In-Reply-To: <1395153249.12.0.327856107433.issue20969@psf.upfronthosting.co.za> Message-ID: <1396621242.37.0.201302797789.issue20969@psf.upfronthosting.co.za> Georg Brandl added the comment: The repository is http://hg.python.org/cpython. If you make a patch, please set the appropriate values in Doc/conf.py, not the makefiles. ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 16:22:05 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 04 Apr 2014 14:22:05 +0000 Subject: [issue20942] _frozen_importlib should not have a __file__ attribute In-Reply-To: <1394948547.33.0.586299720319.issue20942@psf.upfronthosting.co.za> Message-ID: <1396621325.91.0.701341914144.issue20942@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 16:18:20 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 04 Apr 2014 14:18:20 +0000 Subject: [issue15139] Speed up threading.Condition wakeup In-Reply-To: <1340379512.47.0.965576630558.issue15139@psf.upfronthosting.co.za> Message-ID: <1396621100.44.0.352943641409.issue15139@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 16:31:46 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 04 Apr 2014 14:31:46 +0000 Subject: [issue21076] Turn signal.SIG* constants into enums In-Reply-To: <1395935330.94.0.38028035584.issue21076@psf.upfronthosting.co.za> Message-ID: <3g0k9Z2BzYz7Ljw@mail.python.org> Roundup Robot added the comment: New changeset df5120efb86e by Victor Stinner in branch 'default': Issue #21076: the C signal module has been renamed to _signal http://hg.python.org/cpython/rev/df5120efb86e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 16:41:44 2014 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 04 Apr 2014 14:41:44 +0000 Subject: [issue21117] inspect.signature: inaccuracies for partial functions In-Reply-To: <1396297836.4.0.601810070188.issue21117@psf.upfronthosting.co.za> Message-ID: <1396622504.7.0.28476373789.issue21117@psf.upfronthosting.co.za> Yury Selivanov added the comment: Any comments on the patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 17:00:14 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 04 Apr 2014 15:00:14 +0000 Subject: [issue21076] Turn signal.SIG* constants into enums In-Reply-To: <1395935330.94.0.38028035584.issue21076@psf.upfronthosting.co.za> Message-ID: <3g0kpP5pFQz7LjM@mail.python.org> Roundup Robot added the comment: New changeset b1f5b5d7997f by Victor Stinner in branch 'default': Issue #21076: sigpending() is not available on Windows http://hg.python.org/cpython/rev/b1f5b5d7997f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 17:23:44 2014 From: report at bugs.python.org (Hanxue Lee) Date: Fri, 04 Apr 2014 15:23:44 +0000 Subject: [issue10976] json.loads() raises TypeError on bytes object In-Reply-To: <1295636509.41.0.0138366952356.issue10976@psf.upfronthosting.co.za> Message-ID: <1396625024.64.0.99706187276.issue10976@psf.upfronthosting.co.za> Hanxue Lee added the comment: This seems to be an issue (bug?) for Python 3.3 When calling json.loads() with a byte array, this is the error json.loads(response.data, 'latin-1') TypeError: can't use a string pattern on a bytes-like object When I decode the byte array to string json.loads(response.data.decode(), 'latin-1') I get this error TypeError: bytes or integer address expected instead of str instance ---------- nosy: +Hanxue.Lee _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 17:30:41 2014 From: report at bugs.python.org (Eli Bendersky) Date: Fri, 04 Apr 2014 15:30:41 +0000 Subject: [issue19655] Replace the ASDL parser carried with CPython In-Reply-To: <1396617012.78.0.171940980086.issue19655@psf.upfronthosting.co.za> Message-ID: Eli Bendersky added the comment: On Fri, Apr 4, 2014 at 6:10 AM, Serhiy Storchaka wrote: > > Serhiy Storchaka added the comment: > > Now make fails when system Python is older than 3.4. > > This is why the .h & .c files are checked in - someone just building Python doesn't need them regenerated at all. Only if one wants to *modify the AST*, he'll need an up-to-date Python. Otherwise we'll have to stick to the "oldest Python possible" for every script we use internally. I think this was discussed on the mailing list(s) at some point. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 17:40:31 2014 From: report at bugs.python.org (Devin Jeanpierre) Date: Fri, 04 Apr 2014 15:40:31 +0000 Subject: [issue21149] logging._removeHandlerRef is not threadsafe during interpreter shutdown In-Reply-To: <1396556457.93.0.286132850658.issue21149@psf.upfronthosting.co.za> Message-ID: <1396626031.06.0.66533127712.issue21149@psf.upfronthosting.co.za> Devin Jeanpierre added the comment: Please don't take my word for it, but my understanding is that this issue doesn't apply to 3.4+ since module globals are no longer set to None during interpreter shutdown. (So all the checks against None could even be deleted.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 18:16:22 2014 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 04 Apr 2014 16:16:22 +0000 Subject: [issue21136] fractions.Fraction.__pow__ does unneeded renormalization In-Reply-To: <1396482750.35.0.873465877702.issue21136@psf.upfronthosting.co.za> Message-ID: <1396628182.04.0.775555979057.issue21136@psf.upfronthosting.co.za> Mark Dickinson added the comment: LGTM. (For real this time :-). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 18:17:38 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 04 Apr 2014 16:17:38 +0000 Subject: [issue21088] curses addch() argument position reverses in Python3.4.0 In-Reply-To: <1396036290.82.0.606042459455.issue21088@psf.upfronthosting.co.za> Message-ID: <1396628258.64.0.981199737873.issue21088@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 18:20:21 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 04 Apr 2014 16:20:21 +0000 Subject: [issue21090] File read silently stops after EIO I/O error In-Reply-To: <1396045786.33.0.781369785301.issue21090@psf.upfronthosting.co.za> Message-ID: <1396628421.59.0.309234087829.issue21090@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 18:26:23 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 04 Apr 2014 16:26:23 +0000 Subject: [issue21090] File read silently stops after EIO I/O error In-Reply-To: <1396045786.33.0.781369785301.issue21090@psf.upfronthosting.co.za> Message-ID: <1396628783.94.0.945712584566.issue21090@psf.upfronthosting.co.za> STINNER Victor added the comment: > Python 2.7 uses C fopen() and fread(), so what happens probably is that fread() silences the error. I see that file_read() checks ferror() if fread() returned 0. I would nice to run the test in strace and attach the output of strace to see if the EIO is returneded by the kernel at least. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 18:39:26 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 04 Apr 2014 16:39:26 +0000 Subject: [issue21119] asyncio create_connection resource warning In-Reply-To: <1396321484.68.0.174945090803.issue21119@psf.upfronthosting.co.za> Message-ID: <1396629566.96.0.0743722178786.issue21119@psf.upfronthosting.co.za> STINNER Victor added the comment: Here is a patch for Python 3.5. It should be applied to Python 3.4 too. ---------- keywords: +patch nosy: +gvanrossum, haypo, yselivanov versions: +Python 3.5 Added file: http://bugs.python.org/file34724/create_connection_close.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 18:52:08 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 04 Apr 2014 16:52:08 +0000 Subject: [issue21119] asyncio create_connection resource warning In-Reply-To: <1396321484.68.0.174945090803.issue21119@psf.upfronthosting.co.za> Message-ID: <1396630328.17.0.489900460706.issue21119@psf.upfronthosting.co.za> STINNER Victor added the comment: BaseEventLoop.create_datagram_endpoint() and _UnixSelectorEventLoop.create_unix_server() have the same bug. close2.patch fixes these methods but also modify socketpair() to ensure that the 2 sockets are closed on error. I didn't audit the whole asyncio module. Note: BaseEventLoop.create_server() uses a different approach: a "completed" flag with a try/finally block. ---------- Added file: http://bugs.python.org/file34725/close2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 18:57:31 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 04 Apr 2014 16:57:31 +0000 Subject: [issue21155] asyncio: calling _UnixSelectorEventLoop.create_unix_server(sock=..., path=...) must fail Message-ID: <1396630651.69.0.156271009949.issue21155@psf.upfronthosting.co.za> New submission from STINNER Victor: _UnixSelectorEventLoop.create_unix_server() can be called with path *and* sock. In this case, the sock parameter is ignored. Attached patch changes the method to raise a ValueError, to have the same behaviour than create_connection(). ---------- files: unix.patch keywords: patch messages: 215536 nosy: gvanrossum, haypo, yselivanov priority: normal severity: normal status: open title: asyncio: calling _UnixSelectorEventLoop.create_unix_server(sock=..., path=...) must fail versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file34726/unix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 19:11:04 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 04 Apr 2014 17:11:04 +0000 Subject: [issue1100942] Add datetime.time.strptime and datetime.date.strptime Message-ID: <1396631464.17.0.909762960087.issue1100942@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: If datetime.date.strptime(date_string, format) validates format, then it is *not* equivalent to date(*(time.strptime(date_string, format)[0:3])), is it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 19:29:34 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 04 Apr 2014 17:29:34 +0000 Subject: [issue21118] str.translate is absurdly slow in majority of use cases (takes up to 60x longer than similar functions) In-Reply-To: <1396307346.31.0.221715925478.issue21118@psf.upfronthosting.co.za> Message-ID: <1396632574.08.0.398448229694.issue21118@psf.upfronthosting.co.za> STINNER Victor added the comment: translate_script.py: microbenchmark for str.translate() with various length, charsets (ASCII, latin1, UCS2, UCS4) and percentage of replacement. Result: ---------------------------+----------+--------- Summary??????????????????? | original | ??writer ---------------------------+------+--------- replace none, length=10??? | ?5.65 us | ?5.67 us replace none, length=10**3 | ??489 us | ??486 us replace none, length=10**6 | ??487 ms | ??484 ms replace 10%, length=10???? | ?5.47 us | ?5.48 us replace 10%, length=10**3? | ??455 us | ??455 us replace 10%, length=10**6? | ??455 ms | ??455 ms replace 50%, length=10???? | ?4.71 us | ??4.7 us replace 50%, length=10**3? | ??372 us | ??374 us replace 50%, length=10**6? | ??371 ms | ??373 ms replace 90%, length=10???? | ?3.88 us | ?3.93 us replace 90%, length=10**3? | ??293 us | ??297 us replace 90%, length=10**6? | ??293 ms | ??295 ms replace all, length=10???? | ?3.58 us | ?3.59 us replace all, length=10**3? | ??263 us | ??262 us replace all, length=10**6? | ??262 ms | ??261 ms ---------------------------+----------+--------- Total????????????????????? | 1.87 sec | 1.87 sec ---------------------------+----------+--------- It's exactly the same with translate_writer.patch. ---------- Added file: http://bugs.python.org/file34727/translate_script.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 19:30:07 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 04 Apr 2014 17:30:07 +0000 Subject: [issue21118] str.translate is absurdly slow in majority of use cases (takes up to 60x longer than similar functions) In-Reply-To: <1396307346.31.0.221715925478.issue21118@psf.upfronthosting.co.za> Message-ID: <1396632607.04.0.127788830808.issue21118@psf.upfronthosting.co.za> STINNER Victor added the comment: translate_writer_bench.txt: full output of the micro-benchmark. ---------- Added file: http://bugs.python.org/file34728/translate_writer_bench.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 19:35:53 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 04 Apr 2014 17:35:53 +0000 Subject: [issue21118] str.translate is absurdly slow in majority of use cases (takes up to 60x longer than similar functions) In-Reply-To: <1396307346.31.0.221715925478.issue21118@psf.upfronthosting.co.za> Message-ID: <1396632953.09.0.227045900847.issue21118@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > - drop optimizations for error handlers different than "ignore" because there is no unit tests for them, and str.translate() uses "ignore". It's safer to drop untested optimization. It is unsafe to do such nontrivial modifications for untested code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 19:39:32 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 04 Apr 2014 17:39:32 +0000 Subject: [issue21118] str.translate is absurdly slow in majority of use cases (takes up to 60x longer than similar functions) In-Reply-To: <1396307346.31.0.221715925478.issue21118@psf.upfronthosting.co.za> Message-ID: <1396633172.53.0.116726423679.issue21118@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, I tested the wrong patch :-( Here is the updated benchmark summary: ---------------------------+--------------+--------------- Summary | original | writer ---------------------------+--------------+--------------- replace none, length=10 | 5.65 us (*) | 5.53 us replace none, length=10**3 | 489 us (*) | 475 us replace none, length=10**6 | 487 ms (*) | 476 ms replace 10%, length=10 | 5.47 us (*) | 5.25 us replace 10%, length=10**3 | 455 us (*) | 447 us replace 10%, length=10**6 | 455 ms (*) | 447 ms replace 50%, length=10 | 4.71 us (*) | 4.42 us (-6%) replace 50%, length=10**3 | 372 us (*) | 352 us (-5%) replace 50%, length=10**6 | 371 ms (*) | 352 ms (-5%) replace 90%, length=10 | 3.88 us (*) | 3.53 us (-9%) replace 90%, length=10**3 | 293 us (*) | 270 us (-8%) replace 90%, length=10**6 | 293 ms (*) | 271 ms (-7%) replace all, length=10 | 3.58 us (*) | 3.24 us (-10%) replace all, length=10**3 | 263 us (*) | 236 us (-10%) replace all, length=10**6 | 262 ms (*) | 235 ms (-10%) ---------------------------+--------------+--------------- Total | 1.87 sec (*) | 1.78 sec ---------------------------+--------------+--------------- str.translate() is a little bit faster with translate_writer.patch, but I don't really care if it's not faster, it's just to cleanup to code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 19:53:46 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 04 Apr 2014 17:53:46 +0000 Subject: [issue17621] Create a lazy import loader mixin In-Reply-To: <1364925647.64.0.233663837419.issue17621@psf.upfronthosting.co.za> Message-ID: <3g0pfd3HS9z7Lkk@mail.python.org> Roundup Robot added the comment: New changeset 52b58618199c by Brett Cannon in branch 'default': Issue #17621: Introduce importlib.util.LazyLoader. http://hg.python.org/cpython/rev/52b58618199c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 19:55:06 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 04 Apr 2014 17:55:06 +0000 Subject: [issue17621] Create a lazy import loader mixin In-Reply-To: <1364925647.64.0.233663837419.issue17621@psf.upfronthosting.co.za> Message-ID: <1396634106.56.0.595175904279.issue17621@psf.upfronthosting.co.za> Brett Cannon added the comment: I went ahead and committed. I realized I could loosen the "no create_module()" requirement, but I think it could lead to more trouble than it's worth so I left it as-is for now. If people says it's an issue we can revisit it. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 19:59:20 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 04 Apr 2014 17:59:20 +0000 Subject: [issue21156] Consider moving importlib.abc.InspectLoader.source_to_code() to importlib.abc.Loader Message-ID: <1396634360.22.0.98257221553.issue21156@psf.upfronthosting.co.za> New submission from Brett Cannon: importlib.abc.InspectLoader.source_to_code exists on InspectLoader because InspectLoader.get_code() uses it. But there is technically no reason to leave it there and not simply move it up to importlib.abc.Loader(). There is also no reason to not make it a staticmethod so that one can use it without worrying about abstractmethod overrides. ---------- assignee: brett.cannon components: Library (Lib) messages: 215544 nosy: brett.cannon priority: low severity: normal stage: test needed status: open title: Consider moving importlib.abc.InspectLoader.source_to_code() to importlib.abc.Loader type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 20:00:06 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 04 Apr 2014 18:00:06 +0000 Subject: [issue21128] testing stdlib and compatibility with pypy In-Reply-To: <1396390977.66.0.122853817502.issue21128@psf.upfronthosting.co.za> Message-ID: <3g0pnx2nHgz7Llg@mail.python.org> Roundup Robot added the comment: New changeset b56341a49eab by Benjamin Peterson in branch '2.7': make temporary read-only files writable, so rmtree can remove them (#21128) http://hg.python.org/cpython/rev/b56341a49eab New changeset 6f1ac58207cc by Benjamin Peterson in branch '2.7': properly explicitly close file (#21128) http://hg.python.org/cpython/rev/6f1ac58207cc New changeset d7a37a1f2ca9 by Benjamin Peterson in branch '2.7': explicitly close file object (#21128) http://hg.python.org/cpython/rev/d7a37a1f2ca9 New changeset 9fd33a504b58 by Benjamin Peterson in branch '3.4': make temporary read-only files writable, so rmtree can remove them (#21128) http://hg.python.org/cpython/rev/9fd33a504b58 New changeset 78e75181d87f by Benjamin Peterson in branch 'default': merge 3.4 (#21128) http://hg.python.org/cpython/rev/78e75181d87f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 20:00:41 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 04 Apr 2014 18:00:41 +0000 Subject: [issue21156] Consider moving importlib.abc.InspectLoader.source_to_code() to importlib.abc.Loader In-Reply-To: <1396634360.22.0.98257221553.issue21156@psf.upfronthosting.co.za> Message-ID: <1396634441.29.0.937595187184.issue21156@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- type: behavior -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 20:01:27 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 04 Apr 2014 18:01:27 +0000 Subject: [issue21128] testing stdlib and compatibility with pypy In-Reply-To: <1396390977.66.0.122853817502.issue21128@psf.upfronthosting.co.za> Message-ID: <1396634487.12.0.0821745921929.issue21128@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 20:22:59 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 04 Apr 2014 18:22:59 +0000 Subject: [issue20998] fullmatch isn't matching correctly under re.IGNORECASE In-Reply-To: <1395351472.15.0.748115651158.issue20998@psf.upfronthosting.co.za> Message-ID: <3837898.Ef8258QMgz@raxxla> Serhiy Storchaka added the comment: Both patch are almost equivalent (my patch is much simpler but perhaps Matthew's approach is more correct in long perspective). Unfortunately Rietvield doesn't work with Matthew's patch, so I have added my comments here. > - (!ctx->match_all || ctx->ptr == state->end)) { > + ctx->ptr == state->end) { Why this check is not needed anymore? > - status = SRE(match)(state, pattern + 2*prefix_skip); > + status = SRE(match)(state, pattern + 2*prefix_skip, state->match_all); > - status = SRE(match)(state, pattern + 2); > + status = SRE(match)(state, pattern + 2, state->match_all); state->match_all is used but it is never initialized. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 20:27:23 2014 From: report at bugs.python.org (Giampaolo Rodola') Date: Fri, 04 Apr 2014 18:27:23 +0000 Subject: [issue21076] Turn signal.SIG* constants into enums In-Reply-To: <1395935330.94.0.38028035584.issue21076@psf.upfronthosting.co.za> Message-ID: <1396636043.13.0.539797112005.issue21076@psf.upfronthosting.co.za> Changes by Giampaolo Rodola' : ---------- assignee: -> giampaolo.rodola resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 20:38:32 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 04 Apr 2014 18:38:32 +0000 Subject: [issue21157] Update imp docs for a PEP 451 world Message-ID: <1396636712.05.0.464506869774.issue21157@psf.upfronthosting.co.za> New submission from Brett Cannon: imp.find_module() should point to importlib.find_spec() instead of find_loader(). As for imp.load_module() I've started a discussion on import-sig on how to best handle that. ---------- assignee: brett.cannon components: Documentation messages: 215547 nosy: brett.cannon, eric.snow, ncoghlan priority: normal severity: normal status: open title: Update imp docs for a PEP 451 world versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 20:39:39 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 04 Apr 2014 18:39:39 +0000 Subject: [issue21157] Update imp docs for a PEP 451 world In-Reply-To: <1396636712.05.0.464506869774.issue21157@psf.upfronthosting.co.za> Message-ID: <1396636779.07.0.425036607449.issue21157@psf.upfronthosting.co.za> Brett Cannon added the comment: Sorry, that should have been importlib.util.find_spec(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 20:49:34 2014 From: report at bugs.python.org (Matthew Barnett) Date: Fri, 04 Apr 2014 18:49:34 +0000 Subject: [issue20998] fullmatch isn't matching correctly under re.IGNORECASE In-Reply-To: <1395340840.43.0.0546340493094.issue20998@psf.upfronthosting.co.za> Message-ID: <1396637374.23.0.844365787024.issue20998@psf.upfronthosting.co.za> Matthew Barnett added the comment: > > - (!ctx->match_all || ctx->ptr == state->end)) { > > + ctx->ptr == state->end) { > > Why this check is not needed anymore? > After stepping through the code for that regex that fails, I concluded that the condition shouldn't depend on ctx->match_all at that point after all. > > - status = SRE(match)(state, pattern + 2*prefix_skip); > > + status = SRE(match)(state, pattern + 2*prefix_skip, > state->match_all); > > > - status = SRE(match)(state, pattern + 2); > > + status = SRE(match)(state, pattern + 2, state->match_all); > > state->match_all is used but it is never initialized. I thought I'd initialised it in all the places it's used. I admit that I find the code a little hard to follow at times... :-( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 20:59:59 2014 From: report at bugs.python.org (Ned Deily) Date: Fri, 04 Apr 2014 18:59:59 +0000 Subject: [issue21088] curses addch() argument position reverses in Python3.4.0 In-Reply-To: <1396036290.82.0.606042459455.issue21088@psf.upfronthosting.co.za> Message-ID: <1396637999.97.0.78256277029.issue21088@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: -ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 21:01:52 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 04 Apr 2014 19:01:52 +0000 Subject: [issue21157] Update imp docs for a PEP 451 world In-Reply-To: <1396636712.05.0.464506869774.issue21157@psf.upfronthosting.co.za> Message-ID: <1396638112.98.0.468671065937.issue21157@psf.upfronthosting.co.za> Brett Cannon added the comment: imp.find_module() might also best be updated to point out that importlib.import_module() exists for those cases where a replacement for sys.path is not necessary. As for imp.load_module(), it might also be best to admit that import is simply not structured to work like imp.find_module()/imp.load_module() used to assume and to not try to force a replacement into importlib where it would be better for someone on PyPI to come up with a replacement; stdlib doesn't have to be everything to everyone, especially now that import is fully exposed in Python code (imp exists mainly because import used to be behind a veil of C code). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 21:02:53 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 04 Apr 2014 19:02:53 +0000 Subject: [issue21118] str.translate is absurdly slow in majority of use cases (takes up to 60x longer than similar functions) In-Reply-To: <1396307346.31.0.221715925478.issue21118@psf.upfronthosting.co.za> Message-ID: <3g0rBN2hkmz7LkW@mail.python.org> Roundup Robot added the comment: New changeset 95d4e8124c6a by Victor Stinner in branch 'default': Issue #21118: Fix _PyUnicodeTranslateError_Create(), add missing format http://hg.python.org/cpython/rev/95d4e8124c6a New changeset 03b1dd29b327 by Victor Stinner in branch 'default': Issue #21118: Use _PyUnicodeWriter API in str.translate() to simplify and http://hg.python.org/cpython/rev/03b1dd29b327 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 21:05:00 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 04 Apr 2014 19:05:00 +0000 Subject: [issue21118] str.translate is absurdly slow in majority of use cases (takes up to 60x longer than similar functions) In-Reply-To: <1396307346.31.0.221715925478.issue21118@psf.upfronthosting.co.za> Message-ID: <1396638300.85.0.956884586836.issue21118@psf.upfronthosting.co.za> STINNER Victor added the comment: > New changeset 95d4e8124c6a by Victor Stinner in branch 'default': > Issue #21118: Fix _PyUnicodeTranslateError_Create(), add missing format > http://hg.python.org/cpython/rev/95d4e8124c6a It looks like _PyUnicode_TranslateCharmap() didn't work with error handler different than "strict", "replace", "ignore" and "xmlcharrefreplace": UnicodeTranslateError constructor crashed before my change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 21:06:00 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 04 Apr 2014 19:06:00 +0000 Subject: [issue21118] str.translate is absurdly slow in majority of use cases (takes up to 60x longer than similar functions) In-Reply-To: <1396307346.31.0.221715925478.issue21118@psf.upfronthosting.co.za> Message-ID: <3g0rFz6by6z7Llg@mail.python.org> Roundup Robot added the comment: New changeset 70990e795657 by Victor Stinner in branch '3.4': Issue #21118: Fix _PyUnicodeTranslateError_Create(), add missing format http://hg.python.org/cpython/rev/70990e795657 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 21:09:03 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 04 Apr 2014 19:09:03 +0000 Subject: [issue20383] Add a keyword-only spec argument to types.ModuleType In-Reply-To: <1390583507.98.0.199737689187.issue20383@psf.upfronthosting.co.za> Message-ID: <1396638543.68.0.350610663328.issue20383@psf.upfronthosting.co.za> Brett Cannon added the comment: I envision making this happen would also allow for importlib to be updated to rely on __spec__ when possible, with the idea that sometime in the future we can deprecate pulling attributes from a module directly and shift to always working from __spec__. ---------- assignee: -> brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 21:18:42 2014 From: report at bugs.python.org (Payden Comer) Date: Fri, 04 Apr 2014 19:18:42 +0000 Subject: [issue21158] Windows installer service could not be accessed Message-ID: <1396639122.72.0.136527705506.issue21158@psf.upfronthosting.co.za> New submission from Payden Comer: I am VERY tech saavy, so don't give me an auto reply like I'm stupid (it's happened before). Sorry for the rude start! Anyhoo, This is the only program on my pc that does this, tried registry fixes, ms fixit, cmd, services, you named it I've (most likely) done it! ---------- components: Installation files: python bug.PNG messages: 215555 nosy: thecheater887 priority: normal severity: normal status: open title: Windows installer service could not be accessed type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file34729/python bug.PNG _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 21:22:04 2014 From: report at bugs.python.org (Payden Comer) Date: Fri, 04 Apr 2014 19:22:04 +0000 Subject: [issue21158] Windows installer service could not be accessed (Python bug!) In-Reply-To: <1396639122.72.0.136527705506.issue21158@psf.upfronthosting.co.za> Message-ID: <1396639324.46.0.632942635589.issue21158@psf.upfronthosting.co.za> Changes by Payden Comer : ---------- title: Windows installer service could not be accessed -> Windows installer service could not be accessed (Python bug!) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 21:35:02 2014 From: report at bugs.python.org (Payden Comer) Date: Fri, 04 Apr 2014 19:35:02 +0000 Subject: [issue21158] Windows installer service could not be accessed (Python bug!) In-Reply-To: <1396639122.72.0.136527705506.issue21158@psf.upfronthosting.co.za> Message-ID: <1396640102.4.0.304416818853.issue21158@psf.upfronthosting.co.za> Payden Comer added the comment: Then when installing the 32 bit. (image below:) ---------- Added file: http://bugs.python.org/file34730/python bug 2.PNG _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 21:36:38 2014 From: report at bugs.python.org (R. David Murray) Date: Fri, 04 Apr 2014 19:36:38 +0000 Subject: [issue21158] Windows installer service could not be accessed (Python bug!) In-Reply-To: <1396639122.72.0.136527705506.issue21158@psf.upfronthosting.co.za> Message-ID: <1396640198.62.0.317058446272.issue21158@psf.upfronthosting.co.za> R. David Murray added the comment: I think it would be helpful for you to email the python-list mailing list. Hopefully the people there can help you refine your problem report into something we can tackle. The installer works fine for most people, so the first thing that we need in order to fix any such bug is to figure out how to reproduce it on some machine other than your own. One of our windows devs might have some questions based on your minimal current description, but you are likely to get faster help from python-list, where there are a lot more people who use windows regularly than there are on the core team. Please report any new information you discover here. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 21:38:36 2014 From: report at bugs.python.org (R. David Murray) Date: Fri, 04 Apr 2014 19:38:36 +0000 Subject: [issue21158] Windows installer service could not be accessed (Python bug!) In-Reply-To: <1396639122.72.0.136527705506.issue21158@psf.upfronthosting.co.za> Message-ID: <1396640316.52.0.758491605062.issue21158@psf.upfronthosting.co.za> R. David Murray added the comment: Sorry, I meant to delete that word 'minimal', since you have told us what you currently know, but I hit send before I did :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 21:39:09 2014 From: report at bugs.python.org (Thomas Heller) Date: Fri, 04 Apr 2014 19:39:09 +0000 Subject: [issue21157] Update imp docs for a PEP 451 world In-Reply-To: <1396636712.05.0.464506869774.issue21157@psf.upfronthosting.co.za> Message-ID: <1396640349.63.0.526586549176.issue21157@psf.upfronthosting.co.za> Changes by Thomas Heller : ---------- nosy: +theller _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 21:40:09 2014 From: report at bugs.python.org (Maciej Szulik) Date: Fri, 04 Apr 2014 19:40:09 +0000 Subject: [issue1100942] Add datetime.time.strptime and datetime.date.strptime Message-ID: <1396640409.45.0.192545814823.issue1100942@psf.upfronthosting.co.za> Maciej Szulik added the comment: You're right, I'll change this description removing 'This is equivalent...' sentence from description. I guess the same applies to time.strptime as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 22:22:50 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 04 Apr 2014 20:22:50 +0000 Subject: [issue20942] _frozen_importlib should not have a __file__ attribute In-Reply-To: <1394948547.33.0.586299720319.issue20942@psf.upfronthosting.co.za> Message-ID: <1396642970.56.0.61106458211.issue20942@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- stage: patch review -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 22:28:58 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 04 Apr 2014 20:28:58 +0000 Subject: [issue21101] Extend the PyDict C API to handle cases where the hash value is known In-Reply-To: <1396169909.67.0.904843670128.issue21101@psf.upfronthosting.co.za> Message-ID: <1396643338.08.0.722924597032.issue21101@psf.upfronthosting.co.za> Terry J. Reedy added the comment: While the question is reasonable, I agree with Raymond's answer. As a python programmer, I would not like to see d.setitem_known_hash(key, hash, d.getitem_known_hash(key, hash) + 1) Of course, "d[key] += 1" already solves the double lookup issue at the Python level. Moreover, it abbreviates the form, rather than expanding it, which is appropriate since it abbreviates the computation. You could optimize get-set even more than the current proposal by saving a reference to the slot corresponding to a key rather than the hash that leads to a slot. Exposing a slot reference probably breaks encapsulation too much. This could be avoided by another alternative: add PyDict_Mod(ify)Item(mapping, key, func). It would combine get and set: find slot, get item, set func(item), and return whatever SetItem does on success/failure. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 22:31:19 2014 From: report at bugs.python.org (Alex Gaynor) Date: Fri, 04 Apr 2014 20:31:19 +0000 Subject: [issue21101] Extend the PyDict C API to handle cases where the hash value is known In-Reply-To: <1396169909.67.0.904843670128.issue21101@psf.upfronthosting.co.za> Message-ID: <1396643479.2.0.911075269516.issue21101@psf.upfronthosting.co.za> Alex Gaynor added the comment: d[key] += 1 still does two dict lookups, and invokes the hash function twice: >>> class X(object): ... def __hash__(self): ... print "hashed" ... return 0 ... def __eq__(self, other): ... return True ... >>> d = {X(): 0} hashed >>> d[X()] hashed 0 >>> d[X()] = 3 hashed >>> d[X()] += 1 hashed hashed ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 22:40:17 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 04 Apr 2014 20:40:17 +0000 Subject: [issue21101] Extend the PyDict C API to handle cases where the hash value is known In-Reply-To: <1396643338.08.0.722924597032.issue21101@psf.upfronthosting.co.za> Message-ID: <1396644014.2308.0.camel@fsol> Antoine Pitrou added the comment: > Of course, "d[key] += 1" already solves the double lookup issue at the > Python level. What the hell are you talking about? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 23:04:48 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 04 Apr 2014 21:04:48 +0000 Subject: [issue21153] bdist_rpm fails if project contains files with spaces in the names In-Reply-To: <1396607616.44.0.695495728794.issue21153@psf.upfronthosting.co.za> Message-ID: <1396645488.91.0.950492630999.issue21153@psf.upfronthosting.co.za> ?ric Araujo added the comment: Is this a duplicate of #809163 ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 23:05:31 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 04 Apr 2014 21:05:31 +0000 Subject: [issue21150] Add quick links table to argparse docs In-Reply-To: <1396558035.28.0.485991636726.issue21150@psf.upfronthosting.co.za> Message-ID: <1396645531.4.0.449075929977.issue21150@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 23:11:25 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 04 Apr 2014 21:11:25 +0000 Subject: [issue21145] Add the @cached_property decorator In-Reply-To: <1396520932.53.0.707047361064.issue21145@psf.upfronthosting.co.za> Message-ID: <1396645885.63.0.378117225518.issue21145@psf.upfronthosting.co.za> ?ric Araujo added the comment: It could make sense to add clean, working recipes to e.g. the functools documentation. The cached_property in the wiki uses a TTL, other like Pyramid?s reify decorator make properties that ensure the fget function is called only once per instance, and there may be subtly different variants out there. I don?t know if there?s a universally useful variant that should be added to the sdlib right now. (I don?t think a C implementation is needed.) On a related note, the Python docs about desciptors may be missing entry-level explanations, as described here: http://me.veekun.com/blog/2012/05/23/python-faq-descriptors/ ---------- nosy: +eric.araujo, rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 23:16:43 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 04 Apr 2014 21:16:43 +0000 Subject: [issue21133] unittest discover should allow option to run each package separately In-Reply-To: <1396441300.71.0.677176151152.issue21133@psf.upfronthosting.co.za> Message-ID: <1396646203.39.0.750750492462.issue21133@psf.upfronthosting.co.za> ?ric Araujo added the comment: > imports from previous unittests corrupt the namespace of subsequent unittests and lead to failures > (usually if there are mock objects in previously imported unit tests) Can you tell more about this? I haven?t run into this issue with large test suites that use mocks (and mock.path monkey-patching) heavily (probably because mock.patch is active for one test method only). ---------- nosy: +eric.araujo, michael.foord versions: -Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 23:23:39 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 04 Apr 2014 21:23:39 +0000 Subject: [issue21091] EmailMessage.is_attachment should be a method In-Reply-To: <1396056379.22.0.363709068017.issue21091@psf.upfronthosting.co.za> Message-ID: <1396646619.9.0.53980951113.issue21091@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 23:30:20 2014 From: report at bugs.python.org (mirabilos) Date: Fri, 04 Apr 2014 21:30:20 +0000 Subject: [issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k In-Reply-To: <1396603095.6.0.504893954867.issue20904@psf.upfronthosting.co.za> Message-ID: mirabilos added the comment: Stefan Krah dixit: >If the asm instructions silently fail, I'd say add a test to ./configure >that detects the broken versions of the emulator in question. No, the problem is at runtime: Debian is a binary distro, and thus, packages can get built and/or used on either ARAnyM, Amiga, Atari, Macintosh, and in theory VME machines, and maybe Q40/Q60, and maybe UAE (Amiga emulator). bye, //mirabilos -- exceptions: a truly awful implementation of quite a nice idea. just about the worst way you could do something like that, afaic. it's like anti-design. that too? may I quote you on that? sure, tho i doubt anyone will listen ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 23:39:04 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 04 Apr 2014 21:39:04 +0000 Subject: [issue21130] equivalent functools.partial instances should compare equal In-Reply-To: <1396425472.15.0.80240218298.issue21130@psf.upfronthosting.co.za> Message-ID: <1396647544.05.0.20139767178.issue21130@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- stage: -> test needed type: behavior -> enhancement versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 23:42:22 2014 From: report at bugs.python.org (mirabilos) Date: Fri, 04 Apr 2014 21:42:22 +0000 Subject: [issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k In-Reply-To: <87siptfqtl.fsf@igel.home> Message-ID: mirabilos added the comment: Andreas Schwab dixit: >The fixed version is here: git://git.code.sf.net/p/aranym/code That?s a source repository. I was asking for released tarballs that have been packaged. But clearly I have been outvoted by the m68k porters. So please feel free to go ahead and break Debian/m68k on released ARAnyM. I retract my veto. bye, //mirabilos -- exceptions: a truly awful implementation of quite a nice idea. just about the worst way you could do something like that, afaic. it's like anti-design. that too? may I quote you on that? sure, tho i doubt anyone will listen ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 23:47:29 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 04 Apr 2014 21:47:29 +0000 Subject: [issue21150] Add quick links table to argparse docs In-Reply-To: <1396558035.28.0.485991636726.issue21150@psf.upfronthosting.co.za> Message-ID: <1396648049.15.0.211102868375.issue21150@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I have used both quick link tables and agree that more would be nice in spite of the added maintenance burden. The re module is one I would like to see indexed. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 23:48:09 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 04 Apr 2014 21:48:09 +0000 Subject: [issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k In-Reply-To: <1394697296.27.0.543058724281.issue20904@psf.upfronthosting.co.za> Message-ID: <1396648089.75.0.707261828597.issue20904@psf.upfronthosting.co.za> Larry Hastings added the comment: > I retract my veto. You don't have a "veto". Only Guido has that. Anyhow you have yet to reply to Mr. Schwab's assertion: > The emulator has always correctly implemented the insn. If that's true, then I don't understand what this whole argument is about. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 4 23:56:50 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 04 Apr 2014 21:56:50 +0000 Subject: [issue21101] Extend the PyDict C API to handle cases where the hash value is known In-Reply-To: <1396169909.67.0.904843670128.issue21101@psf.upfronthosting.co.za> Message-ID: <1396648610.44.0.047429918488.issue21101@psf.upfronthosting.co.za> Terry J. Reedy added the comment: "What the hell I am talking about" is what the doc says. 'd[key]' is written just once and "is evaluated just once". https://docs.python.org/3/reference/simple_stmts.html#augmented-assignment-statements PS: Try being a bit more polite. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 00:02:49 2014 From: report at bugs.python.org (David Lindquist) Date: Fri, 04 Apr 2014 22:02:49 +0000 Subject: [issue1043134] Add preferred extensions for MIME types Message-ID: <1396648969.84.0.572661511933.issue1043134@psf.upfronthosting.co.za> David Lindquist added the comment: Anyone interested in picking this up, or at least commenting on the approach I suggested in the patch? Seems like an easy fix for a long-standing bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 00:10:33 2014 From: report at bugs.python.org (Eric Snow) Date: Fri, 04 Apr 2014 22:10:33 +0000 Subject: [issue17621] Create a lazy import loader mixin In-Reply-To: <1364925647.64.0.233663837419.issue17621@psf.upfronthosting.co.za> Message-ID: <1396649433.85.0.843781999527.issue17621@psf.upfronthosting.co.za> Eric Snow added the comment: Sweet! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 00:18:12 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 04 Apr 2014 22:18:12 +0000 Subject: [issue21101] Extend the PyDict C API to handle cases where the hash value is known In-Reply-To: <1396648610.44.0.047429918488.issue21101@psf.upfronthosting.co.za> Message-ID: <533F2FA1.6070400@free.fr> Antoine Pitrou added the comment: > PS: Try being a bit more polite. You could definitely do some research before posting erroneous statements (this one isn't difficult to check, as Alex showed). Especially when the other posters (Alex and Raymond) are a lot more competent than you on the topic at hand. If you actually try to *reason* about it, there is no other way for: x[k] += to work in the general case than to execute x.__setitem__(k, x.__getitem__(k) + ) So, yes, the lookup is done twice, because it currently can't work otherwise. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 00:45:18 2014 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 04 Apr 2014 22:45:18 +0000 Subject: [issue19655] Replace the ASDL parser carried with CPython In-Reply-To: Message-ID: Nick Coghlan added the comment: IIRC, that discussion was just about Python 2 vs Python 3. Can we get the AST rebuild requirement dropped back to "python3" being 3.3+ for the time being so we don't break Fedora? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 00:47:28 2014 From: report at bugs.python.org (R. David Murray) Date: Fri, 04 Apr 2014 22:47:28 +0000 Subject: [issue21101] Extend the PyDict C API to handle cases where the hash value is known In-Reply-To: <1396169909.67.0.904843670128.issue21101@psf.upfronthosting.co.za> Message-ID: <1396651648.46.0.850583724547.issue21101@psf.upfronthosting.co.za> R. David Murray added the comment: Antoine, being polite never hurts. Terry is a valuable member of the community and sure, he sometimes makes mistakes (or trusts the docs too much?). So do the the rest of us. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 01:38:29 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 04 Apr 2014 23:38:29 +0000 Subject: [issue21118] str.translate is absurdly slow in majority of use cases (takes up to 60x longer than similar functions) In-Reply-To: <1396307346.31.0.221715925478.issue21118@psf.upfronthosting.co.za> Message-ID: <1396654709.27.0.685168985054.issue21118@psf.upfronthosting.co.za> STINNER Victor added the comment: fast_translate.patch: here is the real patch which optimize translating ASCII to ASCII. It's *much* faster: ---------------------------+-------------+--------------- Tests????????????????????? | ????writerA | ?????????fastA ---------------------------+-------------+--------------- replace none, length=10??? | ?710 ns (*) | ?169 ns (-76%) replace none, length=10**3 | 59.1 us (*) | ?997 ns (-98%) replace none, length=10**6 | 59.2 ms (*) | ?805 us (-99%) replace 10%, length=10???? | ?678 ns (*) | ?187 ns (-72%) replace 10%, length=10**3? | 58.7 us (*) | 1.02 us (-98%) replace 10%, length=10**6? | 57.5 ms (*) | ?817 us (-99%) replace 50%, length=10???? | ?559 ns (*) | ?188 ns (-66%) replace 50%, length=10**3? | 43.6 us (*) | 1.02 us (-98%) replace 50%, length=10**6? | 43.4 ms (*) | ?811 us (-98%) replace 90%, length=10???? | ?437 ns (*) | ?187 ns (-57%) replace 90%, length=10**3? | 32.4 us (*) | 1.02 us (-97%) replace 90%, length=10**6? | 31.8 ms (*) | ?805 us (-97%) replace all, length=10???? | ?386 ns (*) | ?121 ns (-69%) replace all, length=10**3? | 27.3 us (*) | ?955 ns (-96%) replace all, length=10**6? | 27.2 ms (*) | ?807 us (-97%) ---------------------------+-------------+--------------- Total????????????????????? | ?219 ms (*) | 4.05 ms (-98%) ---------------------------+-------------+--------------- I'm not sure yet that the patch doesn't make non-ASCII cases slower. ---------- Added file: http://bugs.python.org/file34731/fast_translate.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 01:43:34 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 04 Apr 2014 23:43:34 +0000 Subject: [issue21118] str.translate is absurdly slow in majority of use cases (takes up to 60x longer than similar functions) In-Reply-To: <1396307346.31.0.221715925478.issue21118@psf.upfronthosting.co.za> Message-ID: <1396655014.96.0.361943980337.issue21118@psf.upfronthosting.co.za> STINNER Victor added the comment: translate_script_ascii.py: the benchmark script used to test fast_translate.patch. ---------- Added file: http://bugs.python.org/file34732/translate_script_ascii.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 01:48:52 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 04 Apr 2014 23:48:52 +0000 Subject: [issue21101] Extend the PyDict C API to handle cases where the hash value is known In-Reply-To: <1396169909.67.0.904843670128.issue21101@psf.upfronthosting.co.za> Message-ID: <1396655332.54.0.627454504875.issue21101@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Raymond identified a need and a possible solution. The important part of my post was suggesting another possible solution. Please focus on that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 01:56:45 2014 From: report at bugs.python.org (Jason R. Coombs) Date: Fri, 04 Apr 2014 23:56:45 +0000 Subject: [issue21153] bdist_rpm fails if project contains files with spaces in the names In-Reply-To: <1396607616.44.0.695495728794.issue21153@psf.upfronthosting.co.za> Message-ID: <1396655805.14.0.371062509025.issue21153@psf.upfronthosting.co.za> Jason R. Coombs added the comment: Yes. Exactly. ---------- resolution: -> duplicate status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 02:09:58 2014 From: report at bugs.python.org (Michael Foord) Date: Sat, 05 Apr 2014 00:09:58 +0000 Subject: [issue21133] unittest discover should allow option to run each package separately In-Reply-To: <1396441300.71.0.677176151152.issue21133@psf.upfronthosting.co.za> Message-ID: <1396656598.84.0.877166901011.issue21133@psf.upfronthosting.co.za> Michael Foord added the comment: This is only an issue if a test package pollutes its environment without cleaning up (puts mocks in place that it doesn't remove for example). Fixing this would require discover to use multiple processes to run tests, which isn't going to happen (at least not soon). A better fix is to have test clean up after themselves properly. ---------- resolution: -> wont fix stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 02:45:25 2014 From: report at bugs.python.org (Vinay Sajip) Date: Sat, 05 Apr 2014 00:45:25 +0000 Subject: [issue21149] logging._removeHandlerRef is not threadsafe during interpreter shutdown In-Reply-To: <1396556457.93.0.286132850658.issue21149@psf.upfronthosting.co.za> Message-ID: <1396658725.97.0.240059580818.issue21149@psf.upfronthosting.co.za> Vinay Sajip added the comment: The release notes say about PEP 442 that "As part of this change, module globals are no longer forcibly set to None during interpreter shutdown in most cases". I haven't looked at the PEP in detail, so I'm not sure specifically what "most cases" means - so I played it safe. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 08:52:39 2014 From: report at bugs.python.org (Josiah Carlson) Date: Sat, 05 Apr 2014 06:52:39 +0000 Subject: [issue1191964] asynchronous Subprocess Message-ID: <1396680759.71.0.922749643029.issue1191964@psf.upfronthosting.co.za> Josiah Carlson added the comment: All of the standard tests plus another few that I added all pass on Windows and Linux. I've got some cleanup and a couple more tests to add tomorrow, then I'll post a patch. I ended up not using any overlapped IO cancellation in the Windows variant of communicate(), as there is no benefit to doing so, and the function is as re-entrant as the original. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 10:04:42 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sat, 05 Apr 2014 08:04:42 +0000 Subject: [issue21116] Failure to create multiprocessing shared arrays larger than 50% of memory size under linux In-Reply-To: <1396594326.06.0.320486688012.issue21116@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: Indeed, I think it would make sense to consider this for 3.4, and even 2.7 if we opt for a simple fix. As for the best way to fix it in the meantime, I'm fine with a buffered zero-filling (the mere fact that noone ever complained until now probably means that the performance isn't a show-stopper for users). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 10:29:16 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 05 Apr 2014 08:29:16 +0000 Subject: [issue21136] fractions.Fraction.__pow__ does unneeded renormalization In-Reply-To: <1396482750.35.0.873465877702.issue21136@psf.upfronthosting.co.za> Message-ID: <3g1B4q4bx6z7Ljf@mail.python.org> Roundup Robot added the comment: New changeset 91d7fadac271 by Mark Dickinson in branch 'default': Issue #21136: Avoid unnecessary normalization in Fractions resulting from power and other operations. http://hg.python.org/cpython/rev/91d7fadac271 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 10:30:50 2014 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 05 Apr 2014 08:30:50 +0000 Subject: [issue21136] fractions.Fraction.__pow__ does unneeded renormalization In-Reply-To: <1396482750.35.0.873465877702.issue21136@psf.upfronthosting.co.za> Message-ID: <1396686650.82.0.77446022278.issue21136@psf.upfronthosting.co.za> Mark Dickinson added the comment: Applied. I added an extra test for the `Fraction(0, 1) ** 2` case. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 10:30:58 2014 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 05 Apr 2014 08:30:58 +0000 Subject: [issue21136] fractions.Fraction.__pow__ does unneeded renormalization In-Reply-To: <1396482750.35.0.873465877702.issue21136@psf.upfronthosting.co.za> Message-ID: <1396686658.24.0.400993986957.issue21136@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- stage: needs patch -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 11:42:32 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 05 Apr 2014 09:42:32 +0000 Subject: [issue21118] str.translate is absurdly slow in majority of use cases (takes up to 60x longer than similar functions) In-Reply-To: <1396307346.31.0.221715925478.issue21118@psf.upfronthosting.co.za> Message-ID: <3g1CjM4pLjz7Ll8@mail.python.org> Roundup Robot added the comment: New changeset 9acc8196a82c by Victor Stinner in branch 'default': Issue #21118: Remove unused variable http://hg.python.org/cpython/rev/9acc8196a82c New changeset bd594dd71d46 by Victor Stinner in branch 'default': Issue #21118: Add more unit tests on str.translate() http://hg.python.org/cpython/rev/bd594dd71d46 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 11:56:51 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 05 Apr 2014 09:56:51 +0000 Subject: [issue21118] str.translate is absurdly slow in majority of use cases (takes up to 60x longer than similar functions) In-Reply-To: <1396307346.31.0.221715925478.issue21118@psf.upfronthosting.co.za> Message-ID: <3g1D1t5Jvlz7LjM@mail.python.org> Roundup Robot added the comment: New changeset cca6b056236a by Victor Stinner in branch 'default': Issue #21118: Optimize str.translate() for ASCII => ASCII translation http://hg.python.org/cpython/rev/cca6b056236a New changeset 6a347c0ffbfc by Victor Stinner in branch 'default': Issue #21118: Add unit test for invalid character replacement (code point higher than U+10ffff) http://hg.python.org/cpython/rev/6a347c0ffbfc ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 11:58:40 2014 From: report at bugs.python.org (Divyanshu Sharma) Date: Sat, 05 Apr 2014 09:58:40 +0000 Subject: [issue14576] IDLE: "IDLE's subprocess didn't make connection.Either IDLE can't start a subprocess or personal firewall software is blocking the connection." In-Reply-To: <1334400065.92.0.605072928338.issue14576@psf.upfronthosting.co.za> Message-ID: <1396691920.95.0.637236474483.issue14576@psf.upfronthosting.co.za> Divyanshu Sharma added the comment: I found the root cause for the error regarding python in my pc that shows the error message "IDLE's subprocess didn't make connection.Either IDLE can't start a subprocess or personal firewall software is blocking the connection." It was caused due to a software known as proxifier which provides fast and somewhat unrestricted network access on proxy networks. It redirected my connection request from pythonw.exe to the port and IP on which the proxy network is established. The problem hence can be easily sorted by creating new proxification rules in such softwares, if the cause of the problem can be traced to some similar mechanisms used that may intercept and modify the network requests for other programs. ---------- title: IDLE: resolving home directory for configuration uses HOMEDRIVE, HOMEPATH, and USERPROFILE inconsistently on Windows. -> IDLE: "IDLE's subprocess didn't make connection.Either IDLE can't start a subprocess or personal firewall software is blocking the connection." _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 12:35:12 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Sat, 05 Apr 2014 10:35:12 +0000 Subject: [issue21159] configparser.InterpolationMissingOptionError is not very intuitive Message-ID: <1396694112.28.0.289974893208.issue21159@psf.upfronthosting.co.za> New submission from Claudiu.Popa: The error message from the title is not very intuitive from a user point of view. For instance, in the following traceback, only the first one gives a meaning to this error, through the leaked KeyError, thus the user knows that home_dir1 is invalid and missing. But the second message with "Bad value substitution" doesn't emphasize the actual problem and you have to stare at it for a couple of moments to figure out what's happening and why. Maybe changing the "Bad value substitution" with a "Missing value" would suffice. This came up in issue19546. Traceback (most recent call last): File "C:\Python34\lib\configparser.py", line 410, in _interpolate_some v = map[var] File "C:\Python34\lib\collections\__init__.py", line 789, in __getitem__ return self.__missing__(key) # support subclasses that define __missing__ File "C:\Python34\lib\collections\__init__.py", line 781, in __missing__ raise KeyError(key) KeyError: 'home_dir1' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "", line 1, in File "C:\Python34\lib\configparser.py", line 1204, in __getitem__ return self._parser.get(self._name, key) File "C:\Python34\lib\configparser.py", line 773, in get d) File "C:\Python34\lib\configparser.py", line 374, in before_get self._interpolate_some(parser, option, L, value, section, defaults, 1) File "C:\Python34\lib\configparser.py", line 413, in _interpolate_some option, section, rest, var) configparser.InterpolationMissingOptionError: Bad value substitution: section: [Paths] option : my_dir key : home_dir1 rawval : /lumberjack ---------- components: Library (Lib) messages: 215589 nosy: Claudiu.Popa priority: normal severity: normal status: open title: configparser.InterpolationMissingOptionError is not very intuitive type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 12:36:22 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Sat, 05 Apr 2014 10:36:22 +0000 Subject: [issue19546] configparser leaks implementation detail In-Reply-To: <1384103812.47.0.904880324738.issue19546@psf.upfronthosting.co.za> Message-ID: <1396694182.29.0.687826068184.issue19546@psf.upfronthosting.co.za> Claudiu.Popa added the comment: I've created a new issue for the InterpolationMissingOptionError message, issue21159. This issue can be closed. ---------- resolution: -> 3rd party _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 12:36:51 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Sat, 05 Apr 2014 10:36:51 +0000 Subject: [issue19546] configparser leaks implementation detail In-Reply-To: <1384103812.47.0.904880324738.issue19546@psf.upfronthosting.co.za> Message-ID: <1396694211.35.0.659747966887.issue19546@psf.upfronthosting.co.za> Claudiu.Popa added the comment: Ups, sorry for the change of resolution. ---------- resolution: 3rd party -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 12:45:36 2014 From: report at bugs.python.org (=?utf-8?q?Jurko_Gospodneti=C4=87?=) Date: Sat, 05 Apr 2014 10:45:36 +0000 Subject: [issue21160] incorrect comments in nturl2path.py Message-ID: <1396694736.78.0.949476383561.issue21160@psf.upfronthosting.co.za> New submission from Jurko Gospodneti?: nturl2path.py module contains comments implying that it converts local paths to URLs with ':' characters replaced with '|'. This has not been true since Python 2.6. Commit at: http://bitbucket.org/jurko/cpython/commits/8fe56380b09e238f104ba4a4d7a67df73182bc21 updates those comments - prepared against the CPython development repo. ---------- components: Library (Lib), Windows hgrepos: 230 messages: 215592 nosy: Jurko.Gospodneti? priority: normal severity: normal status: open title: incorrect comments in nturl2path.py versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 12:48:04 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Sat, 05 Apr 2014 10:48:04 +0000 Subject: [issue15582] Enhance inspect.getdoc to follow inheritance chains In-Reply-To: <1344394334.01.0.280520797106.issue15582@psf.upfronthosting.co.za> Message-ID: <1396694884.98.0.65356912911.issue15582@psf.upfronthosting.co.za> Claudiu.Popa added the comment: Yury, Nick, how is my latest patch? ---------- Added file: http://bugs.python.org/file34733/issue15582_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 13:47:43 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 05 Apr 2014 11:47:43 +0000 Subject: [issue21118] str.translate is absurdly slow in majority of use cases (takes up to 60x longer than similar functions) In-Reply-To: <1396307346.31.0.221715925478.issue21118@psf.upfronthosting.co.za> Message-ID: <1396698463.65.0.734385875942.issue21118@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: fast_translate.patch works only with ASCII input string and ASCII 1:1 mapping. Is this actually typical case? Here is a patch which uses different approach. It caches values for ASCII keys. It works with all types of input strings and mappings and can speed up more use cases, including non-ASCII data, deletion and enlarging. translate_timing.py results: unpatched patched Testing 1-1 translation str.translate 4.55125927699919 0.7898181750006188 str.translate from bytes trans 1.8910855210015143 0.779950579000797 Testing deletion str.translate 4.481863372000589 0.7718261509999138 Testing enlarging translations str.translate 4.421521270000085 0.9290620680003485 translate_script_ascii.py results: ---------------------------+---------------------------+------------------------------- Tests????????????????????? | translate_script_ascii.34 | translate_script_ascii.cached3 ---------------------------+---------------------------+------------------------------- replace none, length=10??? | ??????????6.12 us (+176%) | ???????????????????2.22 us (*) replace none, length=10**3 | ??????????448 us (+1293%) | ???????????????????32.2 us (*) replace none, length=10**6 | ??????????474 ms (+1435%) | ???????????????????30.9 ms (*) replace 10%, length=10???? | ??????????5.73 us (+133%) | ???????????????????2.46 us (*) replace 10%, length=10**3? | ??????????412 us (+1060%) | ???????????????????35.5 us (*) replace 10%, length=10**6? | ??????????442 ms (+1204%) | ???????????????????33.9 ms (*) replace 50%, length=10???? | ???????????4.75 us (+85%) | ???????????????????2.57 us (*) replace 50%, length=10**3? | ???????????311 us (+552%) | ???????????????????47.7 us (*) replace 50%, length=10**6? | ???????????331 ms (+617%) | ???????????????????46.2 ms (*) replace 90%, length=10???? | ???????????3.36 us (+29%) | ???????????????????2.59 us (*) replace 90%, length=10**3? | ???????????178 us (+250%) | ???????????????????50.8 us (*) replace 90%, length=10**6? | ???????????192 ms (+291%) | ???????????????????49.2 ms (*) replace all, length=10???? | ???????????2.64 us (+28%) | ???????????????????2.06 us (*) replace all, length=10**3? | ???????????146 us (+189%) | ???????????????????50.3 us (*) replace all, length=10**6? | ???????????152 ms (+194%) | ???????????????????51.7 ms (*) ---------------------------+---------------------------+------------------------------- Total????????????????????? | ?????????1.59 sec (+651%) | ????????????????????212 ms (*) ---------------------------+---------------------------+------------------------------- ---------- Added file: http://bugs.python.org/file34734/translate_cached.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 13:55:43 2014 From: report at bugs.python.org (Kay) Date: Sat, 05 Apr 2014 11:55:43 +0000 Subject: [issue21161] list comprehensions don't see local variables in pdb in python3 Message-ID: <1396698943.39.0.489151150852.issue21161@psf.upfronthosting.co.za> New submission from Kay: Using generators in pdb are very handy but since Python3 they don't work properly. For example: import pdb def foo(): items = [1, 2, 3] limit = 5 pdb.set_trace() foo() in pdb prompt the following fails: (pdf) all(x < limit for x in items) *** NameError: global name 'items' is not defined I can express that in a lambda expression (i.e. pass items as an argument) but this seems unnecessary and very inelegant. ---------- components: Interpreter Core messages: 215595 nosy: kay priority: normal severity: normal status: open title: list comprehensions don't see local variables in pdb in python3 versions: Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 14:04:34 2014 From: report at bugs.python.org (Jason R. Coombs) Date: Sat, 05 Apr 2014 12:04:34 +0000 Subject: [issue21153] bdist_rpm fails if project contains files with spaces in the names In-Reply-To: <1396607616.44.0.695495728794.issue21153@psf.upfronthosting.co.za> Message-ID: <1396699474.02.0.262113584238.issue21153@psf.upfronthosting.co.za> Jason R. Coombs added the comment: My last version of the repo script would have worked had I coded it correctly. The line-by-line substitution was broken, not taking into account the newline character. This new script demonstrates that quoting each file works - simply run the script with "--install-script install.txt". ---------- Added file: http://bugs.python.org/file34735/issue21153.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 14:08:36 2014 From: report at bugs.python.org (Kay) Date: Sat, 05 Apr 2014 12:08:36 +0000 Subject: [issue21161] list comprehensions don't see local variables in pdb in python3 In-Reply-To: <1396698943.39.0.489151150852.issue21161@psf.upfronthosting.co.za> Message-ID: <1396699716.63.0.507344886588.issue21161@psf.upfronthosting.co.za> Changes by Kay : ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 14:22:16 2014 From: report at bugs.python.org (Jason R. Coombs) Date: Sat, 05 Apr 2014 12:22:16 +0000 Subject: [issue809163] Can't add files with spaces under bdist_rpm Message-ID: <1396700536.12.0.793514553139.issue809163@psf.upfronthosting.co.za> Jason R. Coombs added the comment: In issue21153, I explored this problem as well, before being aware of this issue. I had searched for bdist_rpm. I've since confirmed that the sed approach is viable. For example, the following works around the issue by overriding the install_script with the sed technique: $ cat > install.txt python setup.py install -O1 --root=$RPM_BUILD_ROOT --record=INSTALLED_FILES sed -i -e 's/.*/"\0"/' INSTALLED_FILES $ python setup.py bdist_rpm --install-script install.txt I agree that sed can probably be assumed to be present, though it would be nicer not to depend on it. It may also be possible not to have to list the files explicitly. In reading the rpm docs (http://www.rpm.org/max-rpm/s1-rpm-inside-files-list-directives.html), I discovered that rpm will traverse a directory, adding it and its contents. Perhaps the whole routine of recording installed files and then listing them explicitly can be replaced by simply referencing the build root. ---------- nosy: +jason.coombs title: Can't add files with spaces -> Can't add files with spaces under bdist_rpm _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 14:27:29 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 05 Apr 2014 12:27:29 +0000 Subject: [issue21118] str.translate is absurdly slow in majority of use cases (takes up to 60x longer than similar functions) In-Reply-To: <1396307346.31.0.221715925478.issue21118@psf.upfronthosting.co.za> Message-ID: <3g1HMh5J2nz7Ljp@mail.python.org> Roundup Robot added the comment: New changeset 47b0c076e17d by Victor Stinner in branch 'default': Issue #21118: Optimize also str.translate() for ASCII => ASCII deletion http://hg.python.org/cpython/rev/47b0c076e17d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 14:49:22 2014 From: report at bugs.python.org (STINNER Victor) Date: Sat, 05 Apr 2014 12:49:22 +0000 Subject: [issue21118] str.translate is absurdly slow in majority of use cases (takes up to 60x longer than similar functions) In-Reply-To: <3g1HMh5J2nz7Ljp@mail.python.org> Message-ID: STINNER Victor added the comment: Serhiy wrote: > fast_translate.patch works only with ASCII input string and ASCII 1:1 mapping. Is this actually typical case? I just checked the Python stdlib: as expected, all usages of str.translate() except of email.quoprimime use ASCII 1:1. My optimization is only used if the input string is ASCII, but I expect that most strings are just ASCI. ** distutils: ASCII => ASCII (1:1) longopt_xlate = str.maketrans('-', '_') and WS_TRANS = {ord(_wschar) : ' ' for _wschar in string.whitespace}; .. text = text.translate(WS_TRANS) ** email.quoprimes: encoded = header_bytes.decode('latin1').translate(_QUOPRI_HEADER_MAP) and body = body.translate(_QUOPRI_BODY_ENCODE_MAP) => my optimization is used if the input string contains "safe header characters" (a-z, A-Z, 0-9, space and "-!*+/"). It should be the common case for emails. ** rot13 encoding: ASCII 1:1 ** idlelib.PyParse: ASCII 1:1 str = str.translate(_tran) ** textwrap: ASCII 1:1 text = text.translate(self.unicode_whitespace_trans) ** zipfile: ASCII 1:1 arcname = arcname.translate(table) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 14:51:09 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 05 Apr 2014 12:51:09 +0000 Subject: [issue21118] str.translate is absurdly slow in majority of use cases (takes up to 60x longer than similar functions) In-Reply-To: <1396307346.31.0.221715925478.issue21118@psf.upfronthosting.co.za> Message-ID: <1396702269.31.0.231556218242.issue21118@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Previous patch and results were against source code before committing fast_translate.patch. Here is a patch synchronized with current code. translate_timing.py results: unpatched patched Testing 1-1 translation str.translate 0.5265426559999469 0.6120695240006171 str.translate from bytes trans 0.2608634099997289 0.32327288200031035 Testing deletion str.translate 4.331346814999051 0.7960810519998631 Testing enlarging translations str.translate 4.392650978999882 0.9280614529998275 translate_script_ascii.py results: ---------------------------+------------------------------+------------------------------- Tests????????????????????? | translate_script_ascii.fastA | translate_script_ascii.cached2 ---------------------------+------------------------------+------------------------------- replace none, length=10??? | ?????????????????1.54 us (*) | ????????????????2.07 us (+34%) replace none, length=10**3 | ?????????????????10.5 us (*) | ???????????????????????10.6 us replace none, length=10**6 | ?????????????????????12.6 ms | ???????????????????12.3 ms (*) replace 10%, length=10???? | ?????????????????1.69 us (*) | ????????????????2.31 us (+37%) replace 10%, length=10**3? | ?????????????????10.6 us (*) | ???????????????????????10.7 us replace 10%, length=10**6? | ?????????????????????12.6 ms | ???????????????????12.1 ms (*) replace 50%, length=10???? | ?????????????????1.69 us (*) | ????????????????2.31 us (+36%) replace 50%, length=10**3? | ?????????????????10.6 us (*) | ???????????????????????10.9 us replace 50%, length=10**6? | ?????????????????????12.6 ms | ???????????????????12.3 ms (*) replace 90%, length=10???? | ?????????????????1.69 us (*) | ????????????????2.26 us (+34%) replace 90%, length=10**3? | ?????????????????10.6 us (*) | ???????????????????????10.7 us replace 90%, length=10**6? | ?????????????????????12.6 ms | ???????????????????12.2 ms (*) replace all, length=10???? | ?????????????????1.07 us (*) | ????????????????1.68 us (+56%) replace all, length=10**3? | ?????????????????9.28 us (*) | ???????????????????????9.46 us replace all, length=10**6? | ?????????????????????12.6 ms | ?????????????????????12 ms (*) ---------------------------+------------------------------+------------------------------- Total????????????????????? | ???????????????????????63 ms | ???????????????????60.9 ms (*) ---------------------------+------------------------------+------------------------------- translate_cached_2.patch little slows down translation of short ASCII strings (due to cache initialization and freeing), but speeds up deletion and enlarging and works with non-ASCII data. ---------- Added file: http://bugs.python.org/file34736/translate_cached_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 14:52:14 2014 From: report at bugs.python.org (Jason R. Coombs) Date: Sat, 05 Apr 2014 12:52:14 +0000 Subject: [issue809163] Can't add files with spaces under bdist_rpm Message-ID: <1396702334.45.0.791347691546.issue809163@psf.upfronthosting.co.za> Jason R. Coombs added the comment: I decided to test my proposition. It seems that simply specifying / for %files leads to the RPM including parent directories. Here's the output I get when running my test with the sed workaround: $ rpm -q -filesbypkg -p dist/issue21153-package-0.0.0-1.noarch.rpm issue21153-package /usr/local/lib/python2.7/dist-packages/issue21153_package-0.0.0.egg-info issue21153-package /usr/local/lib/python2.7/dist-packages/pkg/__init__.py issue21153-package /usr/local/lib/python2.7/dist-packages/pkg/__init__.pyc issue21153-package /usr/local/lib/python2.7/dist-packages/pkg/__init__.pyo issue21153-package /usr/local/lib/python2.7/dist-packages/pkg/file with spaces.py issue21153-package /usr/local/lib/python2.7/dist-packages/pkg/file with spaces.pyc issue21153-package /usr/local/lib/python2.7/dist-packages/pkg/file with spaces.pyo If instead I apply the no-record patch (attached), I can run bdist_rpm (not using sed workaround) without errors, but the resulting RPM has more directories specified: $ rpm -q -filesbypkg -p dist/issue21153-package-0.0.0-1.noarch.rpm issue21153-package / issue21153-package /usr issue21153-package /usr/local issue21153-package /usr/local/lib issue21153-package /usr/local/lib/python2.7 issue21153-package /usr/local/lib/python2.7/dist-packages issue21153-package /usr/local/lib/python2.7/dist-packages/issue21153_package-0.0.0.egg-info issue21153-package /usr/local/lib/python2.7/dist-packages/pkg issue21153-package /usr/local/lib/python2.7/dist-packages/pkg/__init__.py issue21153-package /usr/local/lib/python2.7/dist-packages/pkg/__init__.pyc issue21153-package /usr/local/lib/python2.7/dist-packages/pkg/__init__.pyo issue21153-package /usr/local/lib/python2.7/dist-packages/pkg/file with spaces.py issue21153-package /usr/local/lib/python2.7/dist-packages/pkg/file with spaces.pyc issue21153-package /usr/local/lib/python2.7/dist-packages/pkg/file with spaces.pyo Perhaps that's acceptable. If it is, it makes the code simpler and cleaner. Can someone comment on the impact of the presence of those parent directories in the RPM? ---------- Added file: http://bugs.python.org/file34737/issue809163-no-record.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 15:03:50 2014 From: report at bugs.python.org (STINNER Victor) Date: Sat, 05 Apr 2014 13:03:50 +0000 Subject: [issue21118] str.translate is absurdly slow in majority of use cases (takes up to 60x longer than similar functions) In-Reply-To: <1396307346.31.0.221715925478.issue21118@psf.upfronthosting.co.za> Message-ID: <1396703030.95.0.633790951252.issue21118@psf.upfronthosting.co.za> STINNER Victor added the comment: bench_translate.py: benchmark ASCII 1:1 but also ASCII 1:1 with deletion. Results of the benchmark comparing tip (47b0c076e17d which includes my latest optimization on deletion) and 6a347c0ffbfc + translate_cached_2.patch. Common platform: Python unicode implementation: PEP 393 CFLAGS: -Wno-unused-result -Werror=declaration-after-statement -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes Platform: Linux-3.12.8-300.fc20.x86_64-x86_64-with-fedora-20-Heisenbug Bits: int=32, long=64, long long=64, size_t=64, void*=64 CPU model: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz Timer: time.perf_counter Timer precision: 45 ns Timer info: namespace(adjustable=False, implementation='clock_gettime(CLOCK_MONOTONIC)', monotonic=True, resolution=1e-09) Platform of campaign remove: SCM: hg revision=47b0c076e17d tag=tip branch=default date="2014-04-05 14:27 +0200" Python version: 3.5.0a0 (default:47b0c076e17d, Apr 5 2014, 14:50:53) [GCC 4.8.2 20131212 (Red Hat 4.8.2-7)] Date: 2014-04-05 14:51:55 Platform of campaign cache: SCM: hg revision=6a347c0ffbfc+ branch=default date="2014-04-05 11:56 +0200" Python version: 3.5.0a0 (default:6a347c0ffbfc+, Apr 5 2014, 14:53:02) [GCC 4.8.2 20131212 (Red Hat 4.8.2-7)] Date: 2014-04-05 14:53:12 ---------------------------+-------------+---------------- Tests | remove | cache ---------------------------+-------------+---------------- replace none, length=10 | 184 ns (*) | 275 ns (+50%) replace none, length=10**3 | 1.06 us (*) | 1.1 us replace none, length=10**6 | 827 us (*) | 792 us replace 10%, length=10 | 207 ns (*) | 298 ns (+44%) replace 10%, length=10**3 | 1.08 us (*) | 1.12 us replace 10%, length=10**6 | 828 us (*) | 793 us replace 50%, length=10 | 205 ns (*) | 298 ns (+46%) replace 50%, length=10**3 | 1.08 us (*) | 1.17 us (+7%) replace 50%, length=10**6 | 827 us (*) | 793 us replace 90%, length=10 | 208 ns (*) | 298 ns (+44%) replace 90%, length=10**3 | 1.09 us (*) | 1.13 us replace 90%, length=10**6 | 850 us (*) | 793 us (-7%) replace all, length=10 | 145 ns (*) | 226 ns (+56%) replace all, length=10**3 | 1.03 us (*) | 1.04 us replace all, length=10**6 | 827 us (*) | 792 us remove none, length=10 | 184 ns (*) | 274 ns (+49%) remove none, length=10**3 | 1.07 us (*) | 1.09 us remove none, length=10**6 | 836 us (*) | 793 us (-5%) remove 10%, length=10 | 223 ns (*) | 408 ns (+83%) remove 10%, length=10**3 | 1.45 us (*) | 9.13 us (+531%) remove 10%, length=10**6 | 1.08 ms (*) | 8.73 ms (+706%) remove 50%, length=10 | 221 ns (*) | 407 ns (+84%) remove 50%, length=10**3 | 1.23 us (*) | 8.28 us (+575%) remove 50%, length=10**6 | 948 us (*) | 7.9 ms (+734%) remove 90%, length=10 | 230 ns (*) | 375 ns (+63%) remove 90%, length=10**3 | 1.57 us (*) | 3.86 us (+145%) remove 90%, length=10**6 | 1.28 ms (*) | 3.49 ms (+173%) remove all, length=10 | 139 ns (*) | 266 ns (+92%) remove all, length=10**3 | 1.24 us (*) | 2.46 us (+99%) remove all, length=10**6 | 1.07 ms (*) | 2.13 ms (+100%) ---------------------------+-------------+---------------- Total | 9.38 ms (*) | 27 ms (+188%) ---------------------------+-------------+---------------- You patch is always slower for the common case (ASCII => ASCII translation). I implemented the most obvious optimization for the most common case (ASCII 1:1 and ASCII 1:1 with deletion). I consider that the current code is enough to close this issue. @Josh Rosenberg: Thanks for the report. The current implementation should be almost as fast as bytes.translate() (the "60x" factor you mentionned in the title) for ASCII 1:1 mapping. -- Serhiy: If you are interested to optimize str.translate() for the general case (larger charset), please open a new issue. It will probably require more complex "cache". You may take a look at charmap codec which has such more complex cache (cache with 3 levels), see my message msg215301. IMO it's not interesting to invest time on optimizing str.translate(), it's not a common function. It took some years before an user run a benchmark on it :-) ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 15:15:57 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 05 Apr 2014 13:15:57 +0000 Subject: [issue21159] configparser.InterpolationMissingOptionError is not very intuitive In-Reply-To: <1396694112.28.0.289974893208.issue21159@psf.upfronthosting.co.za> Message-ID: <1396703757.62.0.999926148745.issue21159@psf.upfronthosting.co.za> R. David Murray added the comment: Another problem with that error message is that it seems confusing as to where the bad value *reference* came from, given that rawval doesn't seem to include any interpolation point. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 15:19:58 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 05 Apr 2014 13:19:58 +0000 Subject: [issue19546] configparser leaks implementation detail In-Reply-To: <1384103812.47.0.904880324738.issue19546@psf.upfronthosting.co.za> Message-ID: <1396703998.89.0.526144112407.issue19546@psf.upfronthosting.co.za> R. David Murray added the comment: I've been thinking about this more, and I think I will revise my opinion. I haven't been able to think of a place where knowing that the key is missing in self._sections would in fact be helpful to a programmer using the module. So I'm OK with this being an example of a place where the new error fully encapsulates the information from the context and therefore the context can be suppressed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 15:22:51 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 05 Apr 2014 13:22:51 +0000 Subject: [issue21161] list comprehensions don't see local variables in pdb in python3 In-Reply-To: <1396698943.39.0.489151150852.issue21161@psf.upfronthosting.co.za> Message-ID: <1396704171.75.0.74846800162.issue21161@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 15:29:13 2014 From: report at bugs.python.org (Hristo Venev) Date: Sat, 05 Apr 2014 13:29:13 +0000 Subject: [issue21111] PyLong_AsUnsignedLongAndOverflow does not exist In-Reply-To: <1396272396.7.0.644063349125.issue21111@psf.upfronthosting.co.za> Message-ID: <1396704553.37.0.308380621096.issue21111@psf.upfronthosting.co.za> Hristo Venev added the comment: Please apply in 3.4.1. I need this ASAP. ---------- versions: +Python 3.4 -Python 3.5 Added file: http://bugs.python.org/file34738/a _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 15:35:19 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 05 Apr 2014 13:35:19 +0000 Subject: [issue21118] str.translate is absurdly slow in majority of use cases (takes up to 60x longer than similar functions) In-Reply-To: <1396307346.31.0.221715925478.issue21118@psf.upfronthosting.co.za> Message-ID: <3g1Jsy2gzYz7Lk2@mail.python.org> Roundup Robot added the comment: New changeset e56c71c6b45e by Victor Stinner in branch 'default': Issue #21118: str.translate() now raises a ValueError, not a TypeError, if the http://hg.python.org/cpython/rev/e56c71c6b45e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 15:36:51 2014 From: report at bugs.python.org (STINNER Victor) Date: Sat, 05 Apr 2014 13:36:51 +0000 Subject: [issue21111] PyLong_AsUnsignedLongAndOverflow does not exist In-Reply-To: <1396272396.7.0.644063349125.issue21111@psf.upfronthosting.co.za> Message-ID: <1396705011.44.0.719027452152.issue21111@psf.upfronthosting.co.za> STINNER Victor added the comment: > Please apply in 3.4.1. I need this ASAP. New functions are new features, and new features are no more added after a release (ex: 3.4.0). If something is changed, it will done in Python 3.5. You can add PyLong_AsUnsigned*AndOverflow() functions to your project so you will support older versions too, like Python 3.3. ---------- versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 15:46:20 2014 From: report at bugs.python.org (Nitika Agarwal) Date: Sat, 05 Apr 2014 13:46:20 +0000 Subject: [issue18478] Class bodies: when does a name become local? In-Reply-To: <1374017954.45.0.193690883208.issue18478@psf.upfronthosting.co.za> Message-ID: <1396705580.41.0.436245342648.issue18478@psf.upfronthosting.co.za> Nitika Agarwal added the comment: Hi, I have attached the patch for the issue.Please someone review my patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 15:51:22 2014 From: report at bugs.python.org (Nitika Agarwal) Date: Sat, 05 Apr 2014 13:51: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: <1396705882.17.0.127948865264.issue4744@psf.upfronthosting.co.za> Nitika Agarwal added the comment: Hi, I hvae attached the patch for review.I am waiting for reviewal.Please review the attached patch as soon as possible. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 15:57:16 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 05 Apr 2014 13:57:16 +0000 Subject: [issue21118] str.translate is absurdly slow in majority of use cases (takes up to 60x longer than similar functions) In-Reply-To: Message-ID: <6916527.b9FPbGfPdm@raxxla> Serhiy Storchaka added the comment: ??????, 05-???-2014 12:49:22 ?? ????????: > STINNER Victor added the comment: > > Serhiy wrote: > > fast_translate.patch works only with ASCII input string and ASCII 1:1 > > mapping. Is this actually typical case? > I just checked the Python stdlib: as expected, all usages of > str.translate() except of email.quoprimime use ASCII 1:1. Because str.translate() is much slower than a series of str.replace() (which already is optimized), some usages of str.translate() was rewritten to use str.replace(). See for example html.escape(). This is about what this issue. > My > optimization is only used if the input string is ASCII, but I expect > that most strings are just ASCI. In most (if not all) these cases input string can be non-ASCII. > bench_translate.py: benchmark ASCII 1:1 but also ASCII 1:1 with deletion. Could you please provide bench_translate.py? > It will probably require more complex "cache". You may take a look at > charmap codec which has such more complex cache (cache with 3 levels), see > my message msg215301. I were going to do this on next step. Full cache can grow up to 1114112 characters, so I planned to cache only BMP characters (cache with 2 levels). You commit too fast, I am late for you. ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 15:58:17 2014 From: report at bugs.python.org (Nitika Agarwal) Date: Sat, 05 Apr 2014 13:58:17 +0000 Subject: [issue16927] Separate built-in types from functions and group similar functions in functions.rst In-Reply-To: <1357883404.71.0.215467038207.issue16927@psf.upfronthosting.co.za> Message-ID: <1396706297.31.0.891697309561.issue16927@psf.upfronthosting.co.za> Nitika Agarwal added the comment: @Ezio Melotti Please see if this is what you wanted. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 16:00:00 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 05 Apr 2014 14:00:00 +0000 Subject: [issue21118] str.translate is absurdly slow in majority of use cases (takes up to 60x longer than similar functions) In-Reply-To: <1396307346.31.0.221715925478.issue21118@psf.upfronthosting.co.za> Message-ID: <1396706400.36.0.332515936355.issue21118@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Do you plan to backport bug fixes to 3.3 and 2.7? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 16:05:11 2014 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 05 Apr 2014 14:05:11 +0000 Subject: [issue19655] Replace the ASDL parser carried with CPython In-Reply-To: <1384869696.09.0.547082157855.issue19655@psf.upfronthosting.co.za> Message-ID: <1396706711.64.0.937219750771.issue19655@psf.upfronthosting.co.za> Eli Bendersky added the comment: Nick, it shouldn't be hard to drop to 3.3, but I'm curious why would the 3.4 requirement break Fedora, or anything for that matter? Does Fedora regenerate the C implementation of the AST for some reason on every build? AFAIU, building Python from source with "make" should not do that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 16:06:21 2014 From: report at bugs.python.org (Hristo Venev) Date: Sat, 05 Apr 2014 14:06:21 +0000 Subject: [issue21111] PyLong_AsUnsignedLongAndOverflow does not exist In-Reply-To: <1396272396.7.0.644063349125.issue21111@psf.upfronthosting.co.za> Message-ID: <1396706781.67.0.501472396756.issue21111@psf.upfronthosting.co.za> Hristo Venev added the comment: Will you release 3.5 in the next few weeks? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 16:11:27 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 05 Apr 2014 14:11:27 +0000 Subject: [issue19655] Replace the ASDL parser carried with CPython In-Reply-To: <1396706711.64.0.937219750771.issue19655@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: It won't break the build, but requiring 3.4 to be installed (rather than 3.3) makes it more annoying for me (and other Fedora users) to work on the compiler before F21 is released :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 16:15:50 2014 From: report at bugs.python.org (Larry Hastings) Date: Sat, 05 Apr 2014 14:15:50 +0000 Subject: [issue19655] Replace the ASDL parser carried with CPython In-Reply-To: <1384869696.09.0.547082157855.issue19655@psf.upfronthosting.co.za> Message-ID: <1396707350.48.0.708214414651.issue19655@psf.upfronthosting.co.za> Larry Hastings added the comment: I was told to keep Argument Clinic compatible with 3.3. I think it's a good idea for the tools to not require absolutely current Python. Would it be a big deal to support 3.3? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 16:16:39 2014 From: report at bugs.python.org (Nitika Agarwal) Date: Sat, 05 Apr 2014 14:16:39 +0000 Subject: [issue19316] devguide: compiler - wording In-Reply-To: <1382272126.03.0.859419260116.issue19316@psf.upfronthosting.co.za> Message-ID: <1396707399.17.0.692937809489.issue19316@psf.upfronthosting.co.za> Nitika Agarwal added the comment: Hi, I have attached the patch.Please review the patch attached. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 16:24:16 2014 From: report at bugs.python.org (Nitika Agarwal) Date: Sat, 05 Apr 2014 14:24:16 +0000 Subject: [issue18566] In unittest.TestCase docs for setUp() and tearDown() don't mention AssertionError In-Reply-To: <1374901937.1.0.747872580847.issue18566@psf.upfronthosting.co.za> Message-ID: <1396707856.41.0.597598330857.issue18566@psf.upfronthosting.co.za> Nitika Agarwal added the comment: Hi, Please review the patch attached. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 17:15:14 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 05 Apr 2014 15:15:14 +0000 Subject: [issue21111] PyLong_AsUnsignedLongAndOverflow does not exist In-Reply-To: <1396272396.7.0.644063349125.issue21111@psf.upfronthosting.co.za> Message-ID: <1396710914.21.0.994655379435.issue21111@psf.upfronthosting.co.za> Benjamin Peterson added the comment: No ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 18:41:00 2014 From: report at bugs.python.org (Ivan K) Date: Sat, 05 Apr 2014 16:41:00 +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 Message-ID: <1396716060.12.0.828109902525.issue21162@psf.upfronthosting.co.za> New submission from Ivan K: Here is a code. https://gist.github.com/anonymous/9994217 When I run it in freeze and never end. If I run it without pool with loop or joblib - it works fine. Also there is a question on stackoverflow: http://stackoverflow.com/q/22881850/1888017 Python 2.7.6/2.7.3, cpu core i7 if it's important ---------- components: Library (Lib) messages: 215620 nosy: Ivan.K priority: normal severity: normal status: open title: code in multiprocessing.pool freeze if inside some code from scikit-learn (and probably liblinear) executed on ubuntu 12.04 64 Bit versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 18:52:57 2014 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Sat, 05 Apr 2014 16:52:57 +0000 Subject: [issue19546] configparser leaks implementation detail In-Reply-To: <1384103812.47.0.904880324738.issue19546@psf.upfronthosting.co.za> Message-ID: <1396716777.69.0.337202641457.issue19546@psf.upfronthosting.co.za> ?ukasz Langa added the comment: FWIW I agree with Claudiu that the internal exceptions are an implementation detail. If we ever made, say, a SQLite-based or memcache-based configparser, those would be different, but the external API would stay the same. Will fix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 18:55:00 2014 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Sat, 05 Apr 2014 16:55:00 +0000 Subject: [issue21159] configparser.InterpolationMissingOptionError is not very intuitive In-Reply-To: <1396694112.28.0.289974893208.issue21159@psf.upfronthosting.co.za> Message-ID: <1396716900.45.0.566836230762.issue21159@psf.upfronthosting.co.za> ?ukasz Langa added the comment: Those exception messages are really old. I agree we should fix them, we have to think about possible compatibility breakage though. I'll look into it. ---------- assignee: -> lukasz.langa nosy: +lukasz.langa stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 20:16:55 2014 From: report at bugs.python.org (Ned Deily) Date: Sat, 05 Apr 2014 18:16:55 +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: <1396721815.49.0.855456777208.issue21162@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 20:18:06 2014 From: report at bugs.python.org (Ethan Furman) Date: Sat, 05 Apr 2014 18:18:06 +0000 Subject: [issue10769] ast: provide more useful range information In-Reply-To: <1293199668.93.0.710632978584.issue10769@psf.upfronthosting.co.za> Message-ID: <1396721886.41.0.8640128969.issue10769@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 21:16:13 2014 From: report at bugs.python.org (Kay) Date: Sat, 05 Apr 2014 19:16:13 +0000 Subject: [issue21161] list comprehensions don't see local variables in pdb in python3 In-Reply-To: <1396698943.39.0.489151150852.issue21161@psf.upfronthosting.co.za> Message-ID: <1396725373.93.0.468641881546.issue21161@psf.upfronthosting.co.za> Changes by Kay : ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 21:19:54 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 05 Apr 2014 19:19:54 +0000 Subject: [issue16927] Separate built-in types from functions and group similar functions in functions.rst In-Reply-To: <1357883404.71.0.215467038207.issue16927@psf.upfronthosting.co.za> Message-ID: <1396725594.25.0.89536273628.issue16927@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I think 'Builtin-in Types' should probably be 'Built-in Classes' as there is no longer any difference between types and classes. Note that after the unification, we added 'issubclass', not 'issubtype'. type should at least be listed under types/classes. The one-parameter introspection use returns an existing instance of type rather than a new instance. In this, it is similar to bool, which returns an existing rather than new bool instance, and which is also used for introspection. I think both should be listed as classes, which they are, and then the intro to Introspection should mention that bool(ob) and type(ob) both return information about ob by returning existing instances of bool and type respectively. I thought about whether we should merely add a categorized index or also re-arrange the entire page. It it the possibly of adding section paragraphs, including cross-references like the above, that pushes me in the latter direction. The math section intro could mention that functions of collections of numbers are in the Iterables section section. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 21:25:05 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 05 Apr 2014 19:25:05 +0000 Subject: [issue18478] Class bodies: when does a name become local? In-Reply-To: <1374017954.45.0.193690883208.issue18478@psf.upfronthosting.co.za> Message-ID: <1396725905.36.0.45595628631.issue18478@psf.upfronthosting.co.za> Terry J. Reedy added the comment: After seeing my suggestion applied, I decided I don't like it. Sorry. A 'function code block' is a 'function suite'. A deeper problem is that the revision now omits the rules for classes. The base problem is that I don't know what the rules are when classes and functions are nested within each other (does anybody, without reading the code?). A puzzling example was posted on python-list yesterday, which I will try to find. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 21:33:03 2014 From: report at bugs.python.org (Georg Brandl) Date: Sat, 05 Apr 2014 19:33:03 +0000 Subject: [issue21161] list comprehensions don't see local variables in pdb in python3 In-Reply-To: <1396698943.39.0.489151150852.issue21161@psf.upfronthosting.co.za> Message-ID: <1396726383.61.0.749038574104.issue21161@psf.upfronthosting.co.za> Georg Brandl added the comment: Your failure appears to be not pasted from an interpreter session; the actual failure is: (Pdb) all(x < limit for x in items) *** NameError: global name 'limit' is not defined (i.e. "limit" is not found, not "items"). This actually does not work in Python 2 either. What did work in Python 2 and doesn't work in 3, is using a list comprehension like all([x < limit for x in items]) This is because list comprehensions are now implemented with their own function object like generator expressions have always been. To make the code in pdb compile "as if" it was put in the debugged function will be as good as impossible, so I'm closing this as won't fix. ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 22:26:05 2014 From: report at bugs.python.org (Antoine Pietri) Date: Sat, 05 Apr 2014 20:26:05 +0000 Subject: [issue21044] tarfile does not handle file .name being an int In-Reply-To: <1395624777.51.0.277506799413.issue21044@psf.upfronthosting.co.za> Message-ID: <1396729565.3.0.037487586771.issue21044@psf.upfronthosting.co.za> Antoine Pietri added the comment: Well, that seems complicated: you can't overwrite a io.FileIO().name attribute, and doing so would be nonsensical for tarfile, which would try to perform IO operations on a random file descriptor... Also, I can't think of any case where a .name attribute could actually be bytes (I was just mirroring the code in msg214670). Here's a patch that tries all combinations of encoding for writing, but I can't see a way to enforce manually the name attribute being an int, even for this test purposes. ---------- Added file: http://bugs.python.org/file34739/test_tarfile_all_modes.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 22:43:34 2014 From: report at bugs.python.org (Antoine Pietri) Date: Sat, 05 Apr 2014 20:43:34 +0000 Subject: [issue13781] gzip module does the wrong thing with an os.fdopen()'ed fileobj In-Reply-To: <1326493916.44.0.574522946696.issue13781@psf.upfronthosting.co.za> Message-ID: <1396730614.49.0.92964519367.issue13781@psf.upfronthosting.co.za> Antoine Pietri added the comment: Actually, thinking about it, it seems safer to use os.open() + os.fdopen() than TemporaryFile(), like in the equivalent test for 'gzip'. This new patch replaces last one. ---------- nosy: +seirl Added file: http://bugs.python.org/file34740/test_tarfile_fdopen.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 22:45:58 2014 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 05 Apr 2014 20:45:58 +0000 Subject: [issue13781] gzip module does the wrong thing with an os.fdopen()'ed fileobj In-Reply-To: <1326493916.44.0.574522946696.issue13781@psf.upfronthosting.co.za> Message-ID: <1396730758.31.0.0748697018915.issue13781@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- Removed message: http://bugs.python.org/msg215627 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 22:46:24 2014 From: report at bugs.python.org (Eric Snow) Date: Sat, 05 Apr 2014 20:46:24 +0000 Subject: [issue21156] Consider moving importlib.abc.InspectLoader.source_to_code() to importlib.abc.Loader In-Reply-To: <1396634360.22.0.98257221553.issue21156@psf.upfronthosting.co.za> Message-ID: Eric Snow added the comment: source_to_code() seems like a good fit on InspectLoader to me. Is there something in particular that motivated the idea of moving it up to Loader? ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 22:47:41 2014 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 05 Apr 2014 20:47:41 +0000 Subject: [issue21044] tarfile does not handle file .name being an int In-Reply-To: <1395624777.51.0.277506799413.issue21044@psf.upfronthosting.co.za> Message-ID: <1396730614.49.0.92964519367.issue13781@psf.upfronthosting.co.za> Ezio Melotti added the comment: Actually, thinking about it, it seems safer to use os.open() + os.fdopen() than TemporaryFile(), like in the equivalent test for 'gzip'. This new patch replaces last one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 22:48:34 2014 From: report at bugs.python.org (Eric Snow) Date: Sat, 05 Apr 2014 20:48:34 +0000 Subject: [issue20383] Add a keyword-only spec argument to types.ModuleType In-Reply-To: <1390583507.98.0.199737689187.issue20383@psf.upfronthosting.co.za> Message-ID: Eric Snow added the comment: Sounds good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 22:49:17 2014 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 05 Apr 2014 20:49:17 +0000 Subject: [issue13781] gzip module does the wrong thing with an os.fdopen()'ed fileobj In-Reply-To: <1326493916.44.0.574522946696.issue13781@psf.upfronthosting.co.za> Message-ID: <1396730957.5.0.0401153012374.issue13781@psf.upfronthosting.co.za> Changes by Ezio Melotti : Removed file: http://bugs.python.org/file34740/test_tarfile_fdopen.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 22:49:54 2014 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 05 Apr 2014 20:49:54 +0000 Subject: [issue21044] tarfile does not handle file .name being an int In-Reply-To: <1395624777.51.0.277506799413.issue21044@psf.upfronthosting.co.za> Message-ID: <1396730994.14.0.194249171005.issue21044@psf.upfronthosting.co.za> Changes by Ezio Melotti : Added file: http://bugs.python.org/file34740/test_tarfile_fdopen.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 22:52:09 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 05 Apr 2014 20:52:09 +0000 Subject: [issue16927] Separate built-in types from functions and group similar functions in functions.rst In-Reply-To: <1357883404.71.0.215467038207.issue16927@psf.upfronthosting.co.za> Message-ID: <1396731129.61.0.586729795705.issue16927@psf.upfronthosting.co.za> Raymond Hettinger added the comment: FWIW, I don't think we should separate built-in types from built-in functions. Tools like str(x) and int(x) are frequently used as if there were functions. Tools like iter(x) and open(x) could be viewed as constructors. Tools like type(x) are both a function (the one-variable form) and a class constructor (the three variable form). For the most part, I don't think the distinction is meaningful or helpful. As a reference point, authors of Python books have avoided making a distinction and have favored the alphabetical ordering we have now (which has the virtue of making functions easy to find). If you feel a need to provide groups of related functions, please do so in an addenda to the core function reference. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 22:52:25 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 05 Apr 2014 20:52:25 +0000 Subject: [issue16927] Separate built-in types from functions and group similar functions in functions.rst In-Reply-To: <1357883404.71.0.215467038207.issue16927@psf.upfronthosting.co.za> Message-ID: <1396731145.71.0.80489100718.issue16927@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- versions: -Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 22:54:42 2014 From: report at bugs.python.org (Brett Cannon) Date: Sat, 05 Apr 2014 20:54:42 +0000 Subject: [issue21156] Consider moving importlib.abc.InspectLoader.source_to_code() to importlib.abc.Loader In-Reply-To: <1396634360.22.0.98257221553.issue21156@psf.upfronthosting.co.za> Message-ID: <1396731282.96.0.572654595046.issue21156@psf.upfronthosting.co.za> Brett Cannon added the comment: The inspiration was that I realized there was no technical reason to have it on InspectLoader. Past that there was my thinking of trying to come up with a source_to_module() method on importlib.abc.Loader which would do the right thing with create_module() and init_module_attrs() such that replicating imp.load_module() would be something like:: loader = importlib.machinery.SourceLoader # or something with open('file.py') as file: module = loader.source_to_module(file.read(), location='file.py') ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 23:01:20 2014 From: report at bugs.python.org (eryksun) Date: Sat, 05 Apr 2014 21:01:20 +0000 Subject: [issue21044] tarfile does not handle file .name being an int In-Reply-To: <1395624777.51.0.277506799413.issue21044@psf.upfronthosting.co.za> Message-ID: <1396731680.15.0.805259066719.issue21044@psf.upfronthosting.co.za> eryksun added the comment: > you can't overwrite a io.FileIO().name attribute A FileIO instance uses a dict for 'name' (msg214670): >>> vars(sys.stdin.buffer.raw) {'name': ''} >>> f = tempfile.TemporaryFile() >>> vars(f.raw) {'name': 3} The name is optional meta-information. If it gets deleted, the repr falls back on using the file descriptor: >>> f.raw <_io.FileIO name=3 mode='rb+'> >>> del f.raw.name >>> f.raw <_io.FileIO fd=3 mode='rb+'> ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 23:10:31 2014 From: report at bugs.python.org (Richard Kiss) Date: Sat, 05 Apr 2014 21:10:31 +0000 Subject: [issue21163] asyncio Task Possibly Incorrectly Garbage Collected Message-ID: <1396732231.93.0.182409018223.issue21163@psf.upfronthosting.co.za> New submission from Richard Kiss: Some tasks created via asyncio are vanishing because there is no reference to their resultant futures. This behaviour does not occur in Python 3.3.3 with asyncio-0.4.1. Also, doing a gc.collect() immediately after creating the tasks seems to fix the problem. Attachment also available at https://gist.github.com/richardkiss/9988156 ---------- components: Library (Lib) files: asyncio-gc-issue.py hgrepos: 231 messages: 215633 nosy: richard.kiss priority: normal severity: normal status: open title: asyncio Task Possibly Incorrectly Garbage Collected type: behavior versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file34741/asyncio-gc-issue.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 23:10:51 2014 From: report at bugs.python.org (Richard Kiss) Date: Sat, 05 Apr 2014 21:10:51 +0000 Subject: [issue21163] asyncio Task Possibly Incorrectly Garbage Collected In-Reply-To: <1396732231.93.0.182409018223.issue21163@psf.upfronthosting.co.za> Message-ID: <1396732251.33.0.716036994493.issue21163@psf.upfronthosting.co.za> Changes by Richard Kiss : ---------- hgrepos: -231 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 23:42:29 2014 From: report at bugs.python.org (Richard Kiss) Date: Sat, 05 Apr 2014 21:42:29 +0000 Subject: [issue21163] asyncio task possibly incorrectly garbage collected In-Reply-To: <1396732231.93.0.182409018223.issue21163@psf.upfronthosting.co.za> Message-ID: <1396734149.4.0.10400241712.issue21163@psf.upfronthosting.co.za> Changes by Richard Kiss : ---------- title: asyncio Task Possibly Incorrectly Garbage Collected -> asyncio task possibly incorrectly garbage collected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 23:48:16 2014 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 05 Apr 2014 21:48:16 +0000 Subject: [issue16927] Separate built-in types from functions and group similar functions in functions.rst In-Reply-To: <1357883404.71.0.215467038207.issue16927@psf.upfronthosting.co.za> Message-ID: <1396734496.3.0.818689346178.issue16927@psf.upfronthosting.co.za> Ezio Melotti added the comment: > Tools like str(x) and int(x) are frequently used as if there were functions. The description of each object already mentions the function/type duality, and links to https://docs.python.org/3/library/stdtypes.html. If they are grouped together, a paragraph like "the objects in this section can be used both as constructors or as functions" can be added at the beginning of the section Similarly a paragraph pointing to itertools can be used in the section that describes map/zip/filter/all/any/etc. > For the most part, I don't think the distinction is meaningful or helpful. There are two distinctions I want to make: 1) grouping the built-in types; 2) grouping related functions; 1 should be especially useful to people that are new to the language. Here they can know quickly what are the Python equivalents of the objects they use in other languages (e.g. a structure similar to a C char*, or a JS object, or a PHP array...) and discover objects that might not exist in their language (e.g. sets, bytes, memoryviews). 2 is useful to find related functions. For example, if I'm looking at map(), I might be interested at zip() and filter() too, or if I'm looking at getattr(), having hasattr(), setattr() and delattr() nearby will make it easy to discover them and consult their docs. > As a reference point, authors of Python books have avoided making a > distinction and have favored the alphabetical ordering we have now > (which has the virtue of making functions easy to find). The table at the beginning and ctrl+f makes the alphabetic order almost useless, so more meaningful orderings can be used instead. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 23:49:28 2014 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 05 Apr 2014 21:49:28 +0000 Subject: [issue19655] Replace the ASDL parser carried with CPython In-Reply-To: <1384869696.09.0.547082157855.issue19655@psf.upfronthosting.co.za> Message-ID: <1396734568.96.0.381558457836.issue19655@psf.upfronthosting.co.za> Eli Bendersky added the comment: Updated patch attached: 1. Python 3.3+ supported (I suspect 3.2 will work too) 2. Incorporated Serhiy's suggestions (thanks for the review!) ---------- Added file: http://bugs.python.org/file34742/new-asdl-parser.issue19655.2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 23:56:49 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 05 Apr 2014 21:56:49 +0000 Subject: [issue16927] Separate built-in types from functions and group similar functions in functions.rst In-Reply-To: <1357883404.71.0.215467038207.issue16927@psf.upfronthosting.co.za> Message-ID: <1396735009.45.0.132373413407.issue16927@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > This include two main groups that should be separated in > two different sections: built-in types and functions. I forgot to mention that the docs have already been organized to cover the two groups. Section 3.2 has the built-in functions and Section 3.4 has the built-in types. Where they overlap (str and list, for example), section section addresses their use as a function (i.e. list(iterable) acts like a function that loops over an iterable to create a list, and str(x) like a function to lookup the string representation of an object). The current organization has been somewhat successful and I don't want to damage it by regrouping. > This will make it easier to find similar functions, This isn't the primary role of a library reference. That said, I would not object to either 1) an extra section that shows a high level grouping of functions or 2) adding to each function a list of see also links (the Microsoft Excel documentation takes that approach). > and will allow us to factor out some documentation that is repeated[0]. This should not be done either. For example, we really to want min() and max() to be completely documented in isolation from one another (this is a reference document, repeating definitions as dictionaries do is proper). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 5 23:57:25 2014 From: report at bugs.python.org (Brett Cannon) Date: Sat, 05 Apr 2014 21:57:25 +0000 Subject: [issue21163] asyncio task possibly incorrectly garbage collected In-Reply-To: <1396732231.93.0.182409018223.issue21163@psf.upfronthosting.co.za> Message-ID: <1396735045.92.0.863936162233.issue21163@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: +giampaolo.rodola, gvanrossum, haypo, pitrou, yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 6 00:39:03 2014 From: report at bugs.python.org (Eric Snow) Date: Sat, 05 Apr 2014 22:39:03 +0000 Subject: [issue21156] Consider moving importlib.abc.InspectLoader.source_to_code() to importlib.abc.Loader In-Reply-To: <1396634360.22.0.98257221553.issue21156@psf.upfronthosting.co.za> Message-ID: <1396737543.62.0.329703965741.issue21156@psf.upfronthosting.co.za> Eric Snow added the comment: Now that I've thought about it a little more, I'm more open to the idea. Source is definitely a universal concept in Python, as is code. So source_to_code() makes some sense on a most-base type like Loader. On the other hand, source isn't necessarily associated with all loaders. I guess my initial gut reaction was that it seemed out of place API-wise. On InspectLoader it's presence is tied to get_code(), so it makes more sense. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 6 01:05:26 2014 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 05 Apr 2014 23:05:26 +0000 Subject: [issue21163] asyncio task possibly incorrectly garbage collected In-Reply-To: <1396732231.93.0.182409018223.issue21163@psf.upfronthosting.co.za> Message-ID: <1396739126.9.0.65229283833.issue21163@psf.upfronthosting.co.za> Guido van Rossum added the comment: Ouch. That example is very obfuscated -- I fail to understand what it is trying to accomplish. Running it I see that it always prints 100 for the count with 3.3 or DO_CG on; for me it prints 87 with 3.4 an DO_GC off. But I wouldn't be surprised if the reason calling do.collect() "fixes" whatever issue you have is that it causes there not to be any further collections until the next cycle through that main loop, and everything simply runs before being collected. But that's just a theory based on minimal understanding of the example. I'm not sure that tasks are *supposed* to stay alive when there are no references to them. It seems that once they make it past a certain point they keep themselves alive. One more thing: using a try/except I see that the "lost" consumers all get a GeneratorExit on their first iteration. You might want to look into this. (Sorry, gotta run, wanted to dump this.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 6 01:06:56 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 05 Apr 2014 23:06:56 +0000 Subject: [issue16927] Separate built-in types from functions and group similar functions in functions.rst In-Reply-To: <1357883404.71.0.215467038207.issue16927@psf.upfronthosting.co.za> Message-ID: <1396739216.0.0.5179000364.issue16927@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: ezio.melotti -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 6 01:24:07 2014 From: report at bugs.python.org (Richard Kiss) Date: Sat, 05 Apr 2014 23:24:07 +0000 Subject: [issue21163] asyncio task possibly incorrectly garbage collected In-Reply-To: <1396732231.93.0.182409018223.issue21163@psf.upfronthosting.co.za> Message-ID: <1396740247.08.0.589643949913.issue21163@psf.upfronthosting.co.za> Richard Kiss added the comment: I agree it's confusing and I apologize for that. Background: This multiplexing pattern is used in pycoinnet, a bitcoin client I'm developing at . The BitcoinPeerProtocol class multiplexes protocol messages into multiple asyncio.Queue objects so each interested listener can react. An example listener is in pycoinnet.helpers.standards.install_pong_manager, which looks for "ping" messages and sends "pong" responses. When the peer disconnects, the pong manager sees a None (to indicate EOF), and it exits. The return value is uninteresting, so no reference to the Task is kept. My client is in late alpha, and mostly works, but when I tried it on Python 3.4.0, it stopped working and I narrowed it down to this. I'm not certain this behaviour is incorrect, but it's definitely different from 3.3.3, and it seems odd that a GC cycle BEFORE additional references can be made would allow it to work. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 6 01:30:44 2014 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 05 Apr 2014 23:30:44 +0000 Subject: [issue21163] asyncio task possibly incorrectly garbage collected In-Reply-To: <1396732231.93.0.182409018223.issue21163@psf.upfronthosting.co.za> Message-ID: <1396740644.19.0.209875906731.issue21163@psf.upfronthosting.co.za> Guido van Rossum added the comment: Most likely your program is simply relying on undefined behavior and the right way to fix it is to keep strong references to all tasks until they self-destruct. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 6 01:35:39 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 05 Apr 2014 23:35:39 +0000 Subject: [issue16927] Separate built-in types from functions and group similar functions in functions.rst In-Reply-To: <1357883404.71.0.215467038207.issue16927@psf.upfronthosting.co.za> Message-ID: <1396740939.78.0.967237508518.issue16927@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Nikita, your additional dispatch table looks like a reasonable addition. I'll wait on additional commentary before pushing it forward >1 should be especially useful to people that are new to the language Ezio, please take care not to conflate the role of reference material (where people lookup what a function does) and tutorials (which introduce, synthesize, and organize). Also take consider that the proposed groupings have some downsides as well (for example str and repr don't appear in the same grouping, likewise, int and round aren't in the same grouping). And, I *really* don't want to separate-out types (that is what section 3.4 is for). You're fighting a long-standing decision to use 3.2 to talk about the tools as functions and again in 3.4 as types. For example, it is not helpful at all to classify range() as a type. Its usage is better grouped with looping idioms like range, zip, enumerate, sorted, and reversed. A possible solution is to list words in more than one category so that int() would be listed as a type conversion (so it wouldn't get separated from str(), and listed math related (so it won't be separated from round() which is another way to convert a float to an integer). This documentation page has proven useful in its current form to a great many users. We should take care not to muck-up one of the better pages in the docs. In particular, we REALLY don't want to factor-out redundant text -- as reference material, each function's description needs to stand-alone. This is not a page that people typically read start to finish in a book like form -- it is much closer to a dictionary or encyclopedia where topics are looked up directly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 6 01:37:36 2014 From: report at bugs.python.org (Richard Kiss) Date: Sat, 05 Apr 2014 23:37:36 +0000 Subject: [issue21163] asyncio task possibly incorrectly garbage collected In-Reply-To: <1396732231.93.0.182409018223.issue21163@psf.upfronthosting.co.za> Message-ID: <1396741056.69.0.881061532205.issue21163@psf.upfronthosting.co.za> Richard Kiss added the comment: I'll investigate further. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 6 01:42:38 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 05 Apr 2014 23:42:38 +0000 Subject: [issue16927] Separate built-in types from functions and group similar functions in functions.rst In-Reply-To: <1357883404.71.0.215467038207.issue16927@psf.upfronthosting.co.za> Message-ID: <1396741358.13.0.601883968156.issue16927@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I would be happy enough to just add a second index section, with short annotations or commentaries about the categories -- nitika's patch with sentences added. I would put it after the current table, and not box the links. Short example: The following functions convert an integer to a binary, octal, or hexadecimal string: :func:`bin`, :func:`oct`, :func:`hex`. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 6 02:24:33 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 06 Apr 2014 00:24:33 +0000 Subject: [issue16927] Separate built-in types from functions and group similar functions in functions.rst In-Reply-To: <1357883404.71.0.215467038207.issue16927@psf.upfronthosting.co.za> Message-ID: <1396743873.2.0.109056545795.issue16927@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Terry, I concur. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 6 04:04:49 2014 From: report at bugs.python.org (Ned Deily) Date: Sun, 06 Apr 2014 02:04:49 +0000 Subject: [issue21015] support SSL_CTX_set_ecdh_auto on newer OpenSSLs In-Reply-To: <1395455671.92.0.144736574461.issue21015@psf.upfronthosting.co.za> Message-ID: <1396749889.62.0.0213335491875.issue21015@psf.upfronthosting.co.za> Ned Deily added the comment: test_default_ecdh_curve is failing on current OS X systems (10.9 Mavericks and 10.8 Mountain Lion, at least) using the system-supplied OpenSSL libraries: ====================================================================== ERROR: test_default_ecdh_curve (test.test_ssl.ThreadedTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/py/3x/unix/source/Lib/test/test_ssl.py", line 2596, in test_default_ecdh_curve context.set_ciphers("ECDH") ssl.SSLError: ('No cipher can be selected.',) ---------------------------------------------------------------------- The OpenSSL command advertise itself as 0.9.8y but it doesn't include any ECDH ciphers. It appears from the OpenSSL source that it's possible to specify at build configure time which ciphers are included so I guess the version test in _ssl.c for ECDH isn't sufficient. $ sw_vers ProductName: Mac OS X ProductVersion: 10.9.2 BuildVersion: 13C64 $ /usr/bin/openssl version OpenSSL 0.9.8y 5 Feb 2013 $ /usr/bin/openssl ciphers -v 'ALL:eNULL' ADH-SEED-SHA SSLv3 Kx=DH Au=None Enc=SEED(128) Mac=SHA1 DHE-RSA-SEED-SHA SSLv3 Kx=DH Au=RSA Enc=SEED(128) Mac=SHA1 DHE-DSS-SEED-SHA SSLv3 Kx=DH Au=DSS Enc=SEED(128) Mac=SHA1 SEED-SHA SSLv3 Kx=RSA Au=RSA Enc=SEED(128) Mac=SHA1 ADH-AES256-SHA SSLv3 Kx=DH Au=None Enc=AES(256) Mac=SHA1 DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1 AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 ADH-AES128-SHA SSLv3 Kx=DH Au=None Enc=AES(128) Mac=SHA1 DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1 DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1 AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 ADH-DES-CBC3-SHA SSLv3 Kx=DH Au=None Enc=3DES(168) Mac=SHA1 ADH-DES-CBC-SHA SSLv3 Kx=DH Au=None Enc=DES(56) Mac=SHA1 EXP-ADH-DES-CBC-SHA SSLv3 Kx=DH(512) Au=None Enc=DES(40) Mac=SHA1 export ADH-RC4-MD5 SSLv3 Kx=DH Au=None Enc=RC4(128) Mac=MD5 EXP-ADH-RC4-MD5 SSLv3 Kx=DH(512) Au=None Enc=RC4(40) Mac=MD5 export EDH-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1 EDH-RSA-DES-CBC-SHA SSLv3 Kx=DH Au=RSA Enc=DES(56) Mac=SHA1 EXP-EDH-RSA-DES-CBC-SHA SSLv3 Kx=DH(512) Au=RSA Enc=DES(40) Mac=SHA1 export EDH-DSS-DES-CBC3-SHA SSLv3 Kx=DH Au=DSS Enc=3DES(168) Mac=SHA1 EDH-DSS-DES-CBC-SHA SSLv3 Kx=DH Au=DSS Enc=DES(56) Mac=SHA1 EXP-EDH-DSS-DES-CBC-SHA SSLv3 Kx=DH(512) Au=DSS Enc=DES(40) Mac=SHA1 export DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1 DES-CBC-SHA SSLv3 Kx=RSA Au=RSA Enc=DES(56) Mac=SHA1 EXP-DES-CBC-SHA SSLv3 Kx=RSA(512) Au=RSA Enc=DES(40) Mac=SHA1 export EXP-RC2-CBC-MD5 SSLv3 Kx=RSA(512) Au=RSA Enc=RC2(40) Mac=MD5 export RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 EXP-RC4-MD5 SSLv3 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export DES-CBC3-MD5 SSLv2 Kx=RSA Au=RSA Enc=3DES(168) Mac=MD5 DES-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=DES(56) Mac=MD5 EXP-RC2-CBC-MD5 SSLv2 Kx=RSA(512) Au=RSA Enc=RC2(40) Mac=MD5 export RC2-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC2(128) Mac=MD5 EXP-RC4-MD5 SSLv2 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export RC4-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 NULL-SHA SSLv3 Kx=RSA Au=RSA Enc=None Mac=SHA1 NULL-MD5 SSLv3 Kx=RSA Au=RSA Enc=None Mac=MD5 ---------- nosy: +ned.deily resolution: fixed -> stage: committed/rejected -> needs patch status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 6 04:12:43 2014 From: report at bugs.python.org (Richard Kiss) Date: Sun, 06 Apr 2014 02:12:43 +0000 Subject: [issue21163] asyncio task possibly incorrectly garbage collected In-Reply-To: <1396732231.93.0.182409018223.issue21163@psf.upfronthosting.co.za> Message-ID: <1396750363.78.0.331918449081.issue21163@psf.upfronthosting.co.za> Richard Kiss added the comment: You were right: adding a strong reference to each Task seems to have solved the original problem in pycoinnet. I see that the reference to the global lists of asyncio.tasks is a weakset, so it's necessary to keep a strong reference myself. This does seem a little surprising. It can make it trickier to create a task that is only important in its side effect. Compare to threaded programming: unreferenced threads are never collected. For example: f = asyncio.Task(some_coroutine()) f.add_callback(some_completion_callback) f = None In theory, the "some_coroutine" task can be collected, preventing "some_completion_callback" from ever being called. While technically correct, it does seem surprising. (I couldn't get this to work in a simple example, although I did get it to work in a complicated example.) Some change between 3.3 and 3.4 means garbage collection is much more aggressive at collecting up unreferenced tasks, which means broken code, like mine, that worked in 3.3 fails in 3.4. This may trip up other early adopters of tulip. Maybe adding a "do_not_collect=True" flag to asyncio.async or asyncio.Task, which would keep a strong reference by throwing it into a singleton set (removing it as a future callback) would bring attention to this subtle issue. Or displaying a warning in debug mode when a Task is garbage-collected before finishing. Thanks for your help. ---------- resolution: -> invalid _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 6 05:35:09 2014 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 06 Apr 2014 03:35:09 +0000 Subject: [issue21163] asyncio task possibly incorrectly garbage collected In-Reply-To: <1396732231.93.0.182409018223.issue21163@psf.upfronthosting.co.za> Message-ID: <1396755309.02.0.635062663595.issue21163@psf.upfronthosting.co.za> Guido van Rossum added the comment: Thanks for understanding. It's definitely subtle: there is also some code in asyncio that logs an error when a Future holding an exception becomes unreachable before anyone has asked for it; this has been a valuable debugging tool, and it depends on *not* holding references to Futures. Regarding the difference between Python 3.3 and 3.4, I don't know the exact reason, but GC definitely gets more precise with each new revision, and there are also some differences in how exactly the debug feature I just mentioned is implemented (look for _tb_logger in asyncio/futures.py). OTOH it does seem a little odd to just GC a coroutine that hasn't exited yet, and I'm not 100% convinced there *isn't* a bug here. The more I think about it, the more I think that it's suspicious that it's always the *first* iteration that gets GC'ed. So I'd like to keep this open as a reminder. Finally, I'm not sure the analogy with threads holds -- a thread manages OS resources that really do have to be destroyed explicitly, but that's not so for tasks, and any cleanup you do need can be handled using try/finally. (In general drawing analogies between threads and asyncio tasks/coroutines is probably one of the less fruitful lines of thinking about the latter; there are more differences than similarities.) ---------- resolution: invalid -> remind _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 6 07:06:34 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 06 Apr 2014 05:06:34 +0000 Subject: [issue20383] Add a keyword-only spec argument to types.ModuleType In-Reply-To: <1390583507.98.0.199737689187.issue20383@psf.upfronthosting.co.za> Message-ID: <1396760794.6.0.286107095575.issue20383@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > Would allow for the name attribute to be optional ... > with the idea that sometime in the future we can > deprecate pulling attributes from a module directly Is there any chance that this would ever happen? The __name__ attribute has been around almost forever is widely relied on. Deprecating it would be a very disruptive event for nearly zero benefit. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 6 07:20:33 2014 From: report at bugs.python.org (Eric Snow) Date: Sun, 06 Apr 2014 05:20:33 +0000 Subject: [issue20383] Add a keyword-only spec argument to types.ModuleType In-Reply-To: <1390583507.98.0.199737689187.issue20383@psf.upfronthosting.co.za> Message-ID: <1396761633.88.0.990041374001.issue20383@psf.upfronthosting.co.za> Eric Snow added the comment: I made roughly the same point in the current import-sig thread that relates here: https://mail.python.org/pipermail/import-sig/2014-April/000805.html Basically, I agree we should be careful with both __name__ and __file__. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 6 08:48:08 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 06 Apr 2014 06:48:08 +0000 Subject: [issue21130] equivalent functools.partial instances should compare equal In-Reply-To: <1396425472.15.0.80240218298.issue21130@psf.upfronthosting.co.za> Message-ID: <1396766888.94.0.138032701345.issue21130@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > I guess a partial is a binding, not a function. Viewed in that light, it makes sense to implement same logic as used for bound methods in method_richcompare. ---------- keywords: +easy stage: test needed -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 6 09:20:17 2014 From: report at bugs.python.org (Hristo Venev) Date: Sun, 06 Apr 2014 07:20:17 +0000 Subject: [issue21111] PyLong_AsUnsignedLongAndOverflow does not exist In-Reply-To: <1396272396.7.0.644063349125.issue21111@psf.upfronthosting.co.za> Message-ID: <1396768817.38.0.104837794199.issue21111@psf.upfronthosting.co.za> Hristo Venev added the comment: I will not add PyLong_AsUnsigned*AndOverflow in my code because I don't want my code to depend on the exact implementation of PyLong. Are you seriously calling a 50-line function "feature"? Anyway... I propose splitting the patch in two parts: - "cleanup": the changes to Objects/longobject.c - "feature": the changes to Include/longobject.h "cleanup" can be applied to 3.4.1 because it adds no new features and helps maintainability. Backwards compatibility will not be broken. "feature" can then be added in 3.5. Backwards compatibility should not be broken. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 6 11:33:38 2014 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 06 Apr 2014 09:33:38 +0000 Subject: [issue21111] PyLong_AsUnsignedLongAndOverflow does not exist In-Reply-To: <1396272396.7.0.644063349125.issue21111@psf.upfronthosting.co.za> Message-ID: <1396776818.98.0.503491434094.issue21111@psf.upfronthosting.co.za> Mark Dickinson added the comment: Thanks for the patch! I left a couple of comments on Rietveld. The patch will also need docs and tests before it's ready to go in. There's a behaviour change in the patch which needs looking into: before the patch, PyLong_AsUnsignedLong will not call the target object's __int__ method (so it should raise a TypeError for a float or Decimal instance, for example). It looks to me as though the patch changes that; was that change intentional? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 6 12:10:21 2014 From: report at bugs.python.org (Samuel John) Date: Sun, 06 Apr 2014 10:10:21 +0000 Subject: [issue21144] ensurepip "AssertionError: Multiple .dist-info directories" In-Reply-To: <1396520627.59.0.769231802002.issue21144@psf.upfronthosting.co.za> Message-ID: <1396779021.41.0.812163513065.issue21144@psf.upfronthosting.co.za> Changes by Samuel John : ---------- nosy: +samueljohn _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 6 12:26:53 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 06 Apr 2014 10:26:53 +0000 Subject: [issue20383] Add a keyword-only spec argument to types.ModuleType In-Reply-To: <1390583507.98.0.199737689187.issue20383@psf.upfronthosting.co.za> Message-ID: <1396780013.17.0.514882877474.issue20383@psf.upfronthosting.co.za> Nick Coghlan added the comment: No, the attribute level arguments won't go away - __name__ deliberately differs from __spec__.name in some cases (notably in __main__), __path__ may be manipulated after the module is loaded, and __name and __file__ are both used too heavily within module code for it to be worth the hassle of deprecating them in favour of something else. I think Brett's push to simplify things as much as possible is good though - that's the main brake on creeping API complexity in the overall import system as we try to make the internals easier to comprehend and manipulate. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 6 12:31:33 2014 From: report at bugs.python.org (Omer Katz) Date: Sun, 06 Apr 2014 10:31:33 +0000 Subject: [issue21145] Add the @cached_property decorator In-Reply-To: <1396645885.63.0.378117225518.issue21145@psf.upfronthosting.co.za> Message-ID: Omer Katz added the comment: The default implementation should simple: Once the property is accessed for the first time calculate the result and never calculate again. It's what both Django & pip uses. You can add an optional TTL. There aren't any other features I can come up with that are common enough. If needed, one can inherit from cached_property and do whatever is needed. Eric, Why don't you think a C implementation is needed? It's a simple operation for sure but it is meant to increase runtime efficiency. 2014-04-05 1:11 GMT+04:00 ?ric Araujo : > > ?ric Araujo added the comment: > > It could make sense to add clean, working recipes to e.g. the functools > documentation. The cached_property in the wiki uses a TTL, other like > Pyramid's reify decorator make properties that ensure the fget function is > called only once per instance, and there may be subtly different variants > out there. I don't know if there's a universally useful variant that > should be added to the sdlib right now. (I don't think a C implementation > is needed.) > > On a related note, the Python docs about desciptors may be missing > entry-level explanations, as described here: > http://me.veekun.com/blog/2012/05/23/python-faq-descriptors/ > > ---------- > nosy: +eric.araujo, rhettinger > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 6 12:49:45 2014 From: report at bugs.python.org (Omer Katz) Date: Sun, 06 Apr 2014 10:49:45 +0000 Subject: [issue21145] Add the @cached_property decorator In-Reply-To: Message-ID: Omer Katz added the comment: I just checked and werkzeug uses the same implementation as Django & pip. 2014-04-06 14:31 GMT+04:00 Omer Katz : > > Omer Katz added the comment: > > The default implementation should simple: > Once the property is accessed for the first time calculate the result and > never calculate again. > It's what both Django & pip uses. > You can add an optional TTL. > There aren't any other features I can come up with that are common enough. > If needed, one can inherit from cached_property and do whatever is needed. > Eric, Why don't you think a C implementation is needed? It's a simple > operation for sure but it is meant to increase runtime efficiency. > > 2014-04-05 1:11 GMT+04:00 ?ric Araujo : > > > > > ?ric Araujo added the comment: > > > > It could make sense to add clean, working recipes to e.g. the functools > > documentation. The cached_property in the wiki uses a TTL, other like > > Pyramid's reify decorator make properties that ensure the fget function > is > > called only once per instance, and there may be subtly different variants > > out there. I don't know if there's a universally useful variant that > > should be added to the sdlib right now. (I don't think a C > implementation > > is needed.) > > > > On a related note, the Python docs about desciptors may be missing > > entry-level explanations, as described here: > > http://me.veekun.com/blog/2012/05/23/python-faq-descriptors/ > > > > ---------- > > nosy: +eric.araujo, rhettinger > > > > _______________________________________ > > Python tracker > > > > _______________________________________ > > > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 6 14:14:36 2014 From: report at bugs.python.org (koobs) Date: Sun, 06 Apr 2014 12:14:36 +0000 Subject: [issue20397] distutils --record option does not validate existance of byte-compiled files In-Reply-To: <1390746014.88.0.900467086198.issue20397@psf.upfronthosting.co.za> Message-ID: <1396786476.01.0.224913823548.issue20397@psf.upfronthosting.co.za> Changes by koobs : ---------- nosy: +koobs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 6 15:24:25 2014 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Sun, 06 Apr 2014 13:24:25 +0000 Subject: [issue21109] tarfile: Traversal attack vulnerability In-Reply-To: <1396253659.12.0.842636239516.issue21109@psf.upfronthosting.co.za> Message-ID: <1396790665.52.0.303901486831.issue21109@psf.upfronthosting.co.za> Lars Gust?bel added the comment: In the past, our answer to these kinds of bug reports has always been that you must not extract an archive from an untrusted source without making sure that it has no malicious contents. And that tarfile conforms to the posix specifications with respect to extraction of files and pathname resolution. That's why we put this prominent warning in the documentation, and I think its advice still holds. I don't think that this issue should be marked as a release blocker, because the way tarfile currently works was a conscious decision, not an accident. tarfile does what it is designed to do: it processes a sequence of instructions to store a number of files in the filesystem. So the attack that is described by Daniel Garcia exploits neither a bug in tarfile nor a loophole in the tar archive format. A necessary condition for this attack to work is that the attacker has to trick the user into extracting the malicious archive first. After that, tarfile interprets the contained instructions word-for-word but still only within the boundaries defined by the user's privileges. I think it is obvious that it is potentially dangerous to extract tar archives we didn't create ourselves, because we actually give another person direct access to our filesystem. tarfile could mitigate some of the adverse effects, but this will not change the fact that it remains unsafe to use tarfile to a certain degree unless you use it with your own data or take reasonable precautions. Anyway, if we come to the conclusion that we want to eliminate this kind of attack, we must be aware that there is a lot more to do than that. tarfile as it is today is vulnerable to all known attacks against tar programs, and maybe even a few more that rely on its specific implementation. 1. Path traversal: The archive contains files names e.g. /etc/passwd or ../etc/passwd. 2. Symlink file attack: foo links to /etc/passwd. Another member named foo follows, its data overwrites the target file's data. 3. Symlink directory attack: foo links to /etc. The following member foo/passwd overwrites /etc/passwd. 4. Hardlink attack: Hardlink member foo links to /etc/passwd. tarfile creates the hardlink to /etc/passwd because it cannot find it inside the archive and falls back to the one in the filesystem. Another file named foo follows, its data overwrites /etc/passwd's data. 5. Permission manipulation: The archive contains an executable that is placed somewhere in PATH with its setuid flag set, so that an unprivileged user is able to gain root privileges. 6. Device file attacks: The archive contains a device node foo with the same major and minor numbers as an attached device. Another member named foo follows, its data is written to the device. 7. Huge zero file attacks: Bzip2 and lzma allow it to store huge blobs of repetetive data in tiny archives. When unpacked this data may fill up an entire filesystem. 8. Excessive memory usage: tarfile saves one TarInfo object per member it finds in an archive. If the archive contains several millions of members, this may fill up the memory. 9. Saving a huge sparse file: tarfile is unable to detect holes in sparse files and thus cannot store them efficiently. Archiving a huge sparse file can take very long and may lead to a very big archive that fills up the filesystem. Additionally, there are more issues mentioned in the GNU tar manual: https://www.gnu.org/software/tar/manual/html_node/Security.html In conclusion, I like to emphasize that tarfile is a library, it is no replacement for GNU tar. And as a library it has a different focus, it is merely a building block for an application, and has to be used with a little bit of responsibility. And even if we start to implement all possible checks, I'm afraid we never can do without a warning in the documentation that reminds everyone to keep an eye on what they're doing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 6 16:10:57 2014 From: report at bugs.python.org (Nadeem Vawda) Date: Sun, 06 Apr 2014 14:10:57 +0000 Subject: [issue15955] gzip, bz2, lzma: add option to limit output size In-Reply-To: <1347884562.79.0.801674791772.issue15955@psf.upfronthosting.co.za> Message-ID: <1396793457.29.0.427939233083.issue15955@psf.upfronthosting.co.za> Nadeem Vawda added the comment: I've posted a review at http://bugs.python.org/review/15955/. (For some reason, it looks like Rietveld didn't send out email notifications. But maybe it never sends a notification to the sender? Hmm.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 6 16:51:56 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 06 Apr 2014 14:51:56 +0000 Subject: [issue21109] tarfile: Traversal attack vulnerability In-Reply-To: <1396253659.12.0.842636239516.issue21109@psf.upfronthosting.co.za> Message-ID: <1396795916.82.0.218573630706.issue21109@psf.upfronthosting.co.za> Larry Hastings added the comment: Thank you Lars for your thorough reply. While I agree that this isn't a release blocker, as it was clearly designed to behave this way... it seems to me that it wouldn't take much to make the tarfile module a lot safer. Specifically: * Don't allow creating files whose absolute path is not under the destination. * Don't allow creating links (hard or soft) which link to a path outside of the destination. * Don't create device nodes. This would fix your listed attacks 1-6. The remaining attacks you cite are denial-of-service attacks; while they're undesirable, they shouldn't compromise the security of the machine. (I suppose we could even address those, adding "reasonable" quotas for disk space and number of files.) I doubt that would make tarfile secure. But maybe "practicality beats purity"? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 6 17:16:57 2014 From: report at bugs.python.org (Hristo Venev) Date: Sun, 06 Apr 2014 15:16:57 +0000 Subject: [issue21111] PyLong_AsUnsignedLongAndOverflow does not exist In-Reply-To: <1396272396.7.0.644063349125.issue21111@psf.upfronthosting.co.za> Message-ID: <1396797417.26.0.4848461453.issue21111@psf.upfronthosting.co.za> Hristo Venev added the comment: I did not intend to make it so that PyLong_AsUnsignedLong* to call __int__ but it looks like a good idea because PyLong_AsLong* does that and the patch is exactly about that - removing differences between converting to signed and unsigned. Should I upload the patch with docs and with the warning fixed? Will it be applied in 3.4.1? It will be a lot easier to check the value of an int than to create a new PyLong = 2^64 and compare the number with that. P.S.: is there a very fast way to check if a PyLong fits in unsigned long long with the limited API? P.P.S.: Just a random idea: would it be a to rewrite PyLong to use GMP instead as a PyVarObject of mp_limb_t's? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 6 17:33:56 2014 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 06 Apr 2014 15:33:56 +0000 Subject: [issue21111] PyLong_AsUnsignedLongAndOverflow does not exist In-Reply-To: <1396272396.7.0.644063349125.issue21111@psf.upfronthosting.co.za> Message-ID: <1396798436.54.0.573416817615.issue21111@psf.upfronthosting.co.za> Mark Dickinson added the comment: > it looks like a good idea It's not a good idea, though: you risk breaking existing third-party extension modules in surprising ways, which isn't a friendly thing to do. In any case, if anything the PyLong methods should be moving *away* from use of the nb_int slot. This has been discussed multiple times previously; one reason that we haven't made that change yet is the problem of breaking backwards compatibility. > Should I upload the patch with docs and with the warning fixed? Sure, that would be great if you have the time. Tests would be useful too, but one of us can fill those in (eventually). It all depends how much of a hurry you're in. :-) > Will it be applied in 3.4.1? No: as already explained by others, it's a enhancement, not a bugfix, so it can't be applied until 3.5. > P.S.: is there a very fast way to check if a PyLong fits in unsigned long long with the limited API? Depends on your definition of 'very fast'. There should be no need to compare with a constant: just try the conversion with PyLong_AsUnsignedLong and see if you get an OverflowError back. My guess is that that's not going to be much slower than a custom PyLong_AsUnsignedLongAndOverflow, but the only way you'll find out is by timing your particular use-case. > P.P.S.: Just a random idea: would it be a to rewrite PyLong to use GMP instead as a PyVarObject of mp_limb_t's? I'll let Victor answer that one. :-) In the mean time, see issue 1814. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 6 17:39:55 2014 From: report at bugs.python.org (Saimadhav Heblikar) Date: Sun, 06 Apr 2014 15:39:55 +0000 Subject: [issue21139] Idle: change default reformat width from 70 to 72 In-Reply-To: <1396492163.57.0.51526901235.issue21139@psf.upfronthosting.co.za> Message-ID: <1396798795.91.0.785338732634.issue21139@psf.upfronthosting.co.za> Changes by Saimadhav Heblikar : ---------- nosy: +sahutd _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 6 17:59:13 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 06 Apr 2014 15:59:13 +0000 Subject: [issue15955] gzip, bz2, lzma: add option to limit output size In-Reply-To: <1396793457.29.0.427939233083.issue15955@psf.upfronthosting.co.za> Message-ID: <3384221.eVQffJ0sIk@raxxla> Serhiy Storchaka added the comment: Yes, Rietveld never sends a notification to the sender. I've received a notification. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 6 18:22:30 2014 From: report at bugs.python.org (R. David Murray) Date: Sun, 06 Apr 2014 16:22:30 +0000 Subject: [issue21145] Add the @cached_property decorator In-Reply-To: <1396520932.53.0.707047361064.issue21145@psf.upfronthosting.co.za> Message-ID: <1396801350.7.0.179939172031.issue21145@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 6 18:49:17 2014 From: report at bugs.python.org (Brett Cannon) Date: Sun, 06 Apr 2014 16:49:17 +0000 Subject: [issue20383] Add a keyword-only spec argument to types.ModuleType In-Reply-To: <1390583507.98.0.199737689187.issue20383@psf.upfronthosting.co.za> Message-ID: <1396802957.9.0.143820617471.issue20383@psf.upfronthosting.co.za> Brett Cannon added the comment: I can dream about getting rid of the attributes, but I doubt it would happen any time soon, if at all. But we do need to make it easier to set __spec__ on a new module than it currently is to help promote its use. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 6 20:55:27 2014 From: report at bugs.python.org (Richard Oudkerk) Date: Sun, 06 Apr 2014 18:55:27 +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: <1396810527.56.0.276519939385.issue21162@psf.upfronthosting.co.za> Richard Oudkerk added the comment: I would guess that the problem is simply that LogisticRegression objects are not picklable. Does the problem still occur if you do not use freeze? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 6 21:11:42 2014 From: report at bugs.python.org (Ivan K) Date: Sun, 06 Apr 2014 19:11:42 +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: <1396811502.3.0.457034732087.issue21162@psf.upfronthosting.co.za> Ivan K added the comment: Sorry, I'm not sure I describe it correct. Freeze that means = goes fozen, so stop progress. It's do no do anything, but computations still load single core of my cpu for 100% untill I do not kill the python process. But the same code work's fine if executed outside pool, or on the different platforms (like Mac for example), my friend run it successfully, but for me it not works. So it's look like pretty unpredictable issue with conflicting OS, CPU, and Python I'm afraid. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 6 21:12:03 2014 From: report at bugs.python.org (Richard Oudkerk) Date: Sun, 06 Apr 2014 19:12:03 +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: <1396811523.86.0.287051639147.issue21162@psf.upfronthosting.co.za> Richard Oudkerk added the comment: Ah, I misunderstood: you meant that it freezes/hangs, not that you used a freeze tool. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 6 21:13:15 2014 From: report at bugs.python.org (Ivan K) Date: Sun, 06 Apr 2014 19:13:15 +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: <1396811595.39.0.98328534934.issue21162@psf.upfronthosting.co.za> Ivan K added the comment: Yes, I'm not using any tool. Code just not working. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 6 22:32:44 2014 From: report at bugs.python.org (Gareth Gouldstone) Date: Sun, 06 Apr 2014 20:32:44 +0000 Subject: [issue20998] fullmatch isn't matching correctly under re.IGNORECASE In-Reply-To: <1395340840.43.0.0546340493094.issue20998@psf.upfronthosting.co.za> Message-ID: <1396816364.08.0.227579027.issue20998@psf.upfronthosting.co.za> Gareth Gouldstone added the comment: fullmatch() is not yet implemented on the regex scanner object SRE_Scanner (issue 21002). Is it possible to adapt this patch to fix this omission? ---------- nosy: +Gareth.Gouldstone _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 6 22:41:33 2014 From: report at bugs.python.org (Josiah Carlson) Date: Sun, 06 Apr 2014 20:41:33 +0000 Subject: [issue1191964] asynchronous Subprocess Message-ID: <1396816893.03.0.582436551934.issue1191964@psf.upfronthosting.co.za> Josiah Carlson added the comment: Should have uploaded this yesterday, but I got caught up with typical weekend activities. The docs probably need more, and I hear that select.select() is disliked, so that will probably need to be changed too. ---------- Added file: http://bugs.python.org/file34743/subprocess.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 00:44:48 2014 From: report at bugs.python.org (Richard Oudkerk) Date: Sun, 06 Apr 2014 22:44:48 +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: <1396824288.06.0.279866886804.issue21162@psf.upfronthosting.co.za> Richard Oudkerk added the comment: Could you try pickling and unpickling the result of func(): import cPickle data = cPickle.dumps(func([1,2,3]), -1) print cPickle.loads(data) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 00:55:34 2014 From: report at bugs.python.org (Ivan K) Date: Sun, 06 Apr 2014 22:55:34 +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: <1396824934.27.0.556670626964.issue21162@psf.upfronthosting.co.za> Ivan K added the comment: Sorry, could you specify what is 'func' ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 00:56:49 2014 From: report at bugs.python.org (Ivan K) Date: Sun, 06 Apr 2014 22:56:49 +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: <1396825009.93.0.74899143475.issue21162@psf.upfronthosting.co.za> Ivan K added the comment: Sorry, stupdi question. Forget that this is from my gist ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 00:59:18 2014 From: report at bugs.python.org (Ivan K) Date: Sun, 06 Apr 2014 22:59:18 +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: <1396825158.39.0.520495206558.issue21162@psf.upfronthosting.co.za> Ivan K added the comment: Yes, it work fine and output was LogisticRegression(C=1.0, class_weight=None, dual=False, fit_intercept=True, intercept_scaling=1, penalty=l2, random_state=None, tol=0.0001) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 01:17:50 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 06 Apr 2014 23:17:50 +0000 Subject: [issue12014] str.format parses replacement field incorrectly In-Reply-To: <1304646359.82.0.599761597998.issue12014@psf.upfronthosting.co.za> Message-ID: <1396826270.98.0.815180870726.issue12014@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 02:39:14 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Mon, 07 Apr 2014 00:39:14 +0000 Subject: [issue21118] str.translate is absurdly slow in majority of use cases (takes up to 60x longer than similar functions) In-Reply-To: <1396307346.31.0.221715925478.issue21118@psf.upfronthosting.co.za> Message-ID: <1396831154.05.0.306480746704.issue21118@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Thanks for addressing this so fast. Annoyingly, I suspect it will not help the original case that led me to finding the slowdown (I had some code that was translating from 56 latin-1 Romance characters with diacritics to the equivalent ASCII characters, so it was 1-1, but it was always mapping from non-ASCII to ASCII, and therefore won't benefit from a change that only caches code points 0-127). That said, every *other* time I've used str.translate has been in an ASCII->ASCII scenario, where this *will* help. So again, thank you. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 02:52:04 2014 From: report at bugs.python.org (Lars Andersson) Date: Mon, 07 Apr 2014 00:52:04 +0000 Subject: [issue21119] asyncio create_connection resource warning In-Reply-To: <1396321484.68.0.174945090803.issue21119@psf.upfronthosting.co.za> Message-ID: <1396831924.31.0.0242465250344.issue21119@psf.upfronthosting.co.za> Lars Andersson added the comment: Thanks Victor, that fixes my problem. I've started using tulip/master as part of my project as that also solves other issues I have with the default asyncio of python 3.4.0, but hopefully this fix will into tulip/master as well as python 3.4.1 / 3.5. ---------- resolution: -> works for me _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 04:57:52 2014 From: report at bugs.python.org (Leslie Klein) Date: Mon, 07 Apr 2014 02:57:52 +0000 Subject: [issue21164] print unicode in Windows console Message-ID: <1396839472.79.0.493888101601.issue21164@psf.upfronthosting.co.za> New submission from Leslie Klein: The console behaves by encoding a str (using the sys.getdefaultencoding()) and then decodes the bytes to a glyph for rendering. The decoder used is 'cp437'. Apparently, there is no way to override that! See ipython notebook for summary and example of the issue. nbviewer.ipython.org/gist/LeslieK/10013426 ---------- components: Windows messages: 215675 nosy: LeslieK priority: normal severity: normal status: open title: print unicode in Windows console type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 10:34:41 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 07 Apr 2014 08:34:41 +0000 Subject: [issue21118] str.translate is absurdly slow in majority of use cases (takes up to 60x longer than similar functions) In-Reply-To: <1396307346.31.0.221715925478.issue21118@psf.upfronthosting.co.za> Message-ID: <1396859681.46.0.149743326606.issue21118@psf.upfronthosting.co.za> STINNER Victor added the comment: > Could you please provide bench_translate.py? Oh, I forgot to add it :-( ---------- Added file: http://bugs.python.org/file34744/bench_translate.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 11:10:44 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 07 Apr 2014 09:10:44 +0000 Subject: [issue21165] Optimize str.translate() for replacement with substrings and non-ASCII strings Message-ID: <1396861844.88.0.0543379452839.issue21165@psf.upfronthosting.co.za> New submission from STINNER Victor: In issue #21118, I optimized str.translate() in Python 3.5 for ASCII 1:1 mapping and ASCII deletion. My optimization is not used if a character is replaced with a string (ex: "abc".translate({ord('a'): "xxx"})) and for non-ASCII strings. translate_script.py is a simple benchmark for 1:1 mapping. It should be enhanced to benchmark also replacement strings. ---------- files: translate_script.py messages: 215677 nosy: haypo, serhiy.storchaka priority: normal severity: normal status: open title: Optimize str.translate() for replacement with substrings and non-ASCII strings type: performance versions: Python 3.5 Added file: http://bugs.python.org/file34745/translate_script.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 11:12:51 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 07 Apr 2014 09:12:51 +0000 Subject: [issue21118] str.translate is absurdly slow in majority of use cases (takes up to 60x longer than similar functions) In-Reply-To: <1396307346.31.0.221715925478.issue21118@psf.upfronthosting.co.za> Message-ID: <1396861971.59.0.900511043624.issue21118@psf.upfronthosting.co.za> STINNER Victor added the comment: > Do you plan to backport bug fixes to 3.3 and 2.7? Which commit? 3.3 is no more open to bug fixes, only to security fixes. > New changeset 95d4e8124c6a by Victor Stinner in branch 'default': > Issue #21118: Fix _PyUnicodeTranslateError_Create(), add missing format > http://hg.python.org/cpython/rev/95d4e8124c6a Python 2.7 is not affected by this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 11:22:28 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 07 Apr 2014 09:22:28 +0000 Subject: [issue21155] asyncio: calling _UnixSelectorEventLoop.create_unix_server(sock=..., path=...) must fail In-Reply-To: <1396630651.69.0.156271009949.issue21155@psf.upfronthosting.co.za> Message-ID: <3g2R9J0T10z7LjN@mail.python.org> Roundup Robot added the comment: New changeset a6b764848b20 by Victor Stinner in branch '3.4': Issue #21155: asyncio.EventLoop.create_unix_server() now raises a ValueError if http://hg.python.org/cpython/rev/a6b764848b20 New changeset 34ace7eb67e9 by Victor Stinner in branch 'default': (Merge 3.4) Issue #21155: asyncio.EventLoop.create_unix_server() now raises a http://hg.python.org/cpython/rev/34ace7eb67e9 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 11:23:26 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 07 Apr 2014 09:23:26 +0000 Subject: [issue21155] asyncio: calling _UnixSelectorEventLoop.create_unix_server(sock=..., path=...) must fail In-Reply-To: <1396630651.69.0.156271009949.issue21155@psf.upfronthosting.co.za> Message-ID: <1396862606.46.0.236924907881.issue21155@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 11:24:13 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 07 Apr 2014 09:24:13 +0000 Subject: [issue21118] str.translate is absurdly slow in majority of use cases (takes up to 60x longer than similar functions) In-Reply-To: <1396307346.31.0.221715925478.issue21118@psf.upfronthosting.co.za> Message-ID: <1396862653.31.0.358659939899.issue21118@psf.upfronthosting.co.za> STINNER Victor added the comment: I opened the issue #21165 to discuss a more generic optimization of str.translate(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 11:24:43 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 07 Apr 2014 09:24:43 +0000 Subject: [issue21165] Optimize str.translate() for replacement with substrings and non-ASCII strings In-Reply-To: <1396861844.88.0.0543379452839.issue21165@psf.upfronthosting.co.za> Message-ID: <1396862683.87.0.665168688656.issue21165@psf.upfronthosting.co.za> STINNER Victor added the comment: codecs.charmap_build() (PyUnicode_BuildEncodingMap()) creates a C array ("a three-level trie") for fast lookup. It is used with codecs.charmap_encode() for 8-bit encodings. We may reuse it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 11:29:23 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 07 Apr 2014 09:29:23 +0000 Subject: [issue21111] PyLong_AsUnsignedLongAndOverflow does not exist In-Reply-To: <1396272396.7.0.644063349125.issue21111@psf.upfronthosting.co.za> Message-ID: <1396862963.79.0.219585208938.issue21111@psf.upfronthosting.co.za> STINNER Victor added the comment: > > P.P.S.: Just a random idea: would it be a to rewrite PyLong to use GMP instead as a PyVarObject of mp_limb_t's? > I'll let Victor answer that one. :-) In the mean time, see issue 1814. During the development of Python 3.0, I wrote a large patch to reuse directly GMP for Python int. My conclusion is here: http://bugs.python.org/issue1814#msg77018 (hint: "it's not a good idea") IMO the first problem is the memory allocation. GMP type doesn't fit well with Python type. GMP type for "int" has a fixed size, and then GMP allocates a second structure for digits. It's inefficient for small integers, and almost all Python int are small (smaller than 32 or 64 bits). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 11:32:57 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 07 Apr 2014 09:32:57 +0000 Subject: [issue21166] Bus error on "AMD64 FreeBSD 9.x 3.4" buildbot Message-ID: <1396863177.29.0.753462829204.issue21166@psf.upfronthosting.co.za> New submission from STINNER Victor: http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.x%203.4/builds/44/steps/compile/logs/stdio ./python -E -S -m sysconfig --generate-posix-vars Bus error (core dumped) http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.x%203.4 ---------- messages: 215683 nosy: haypo priority: normal severity: normal status: open title: Bus error on "AMD64 FreeBSD 9.x 3.4" buildbot versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 11:39:29 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 07 Apr 2014 09:39:29 +0000 Subject: [issue21015] support SSL_CTX_set_ecdh_auto on newer OpenSSLs In-Reply-To: <1395455671.92.0.144736574461.issue21015@psf.upfronthosting.co.za> Message-ID: <1396863569.02.0.709684420183.issue21015@psf.upfronthosting.co.za> STINNER Victor added the comment: test_default_ecdh_curve() is still failing on "x86 Ubuntu Shared 3.x": http://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.x/builds/9964/steps/test/logs/stdio ====================================================================== ERROR: test_default_ecdh_curve (test.test_ssl.ThreadedTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_ssl.py", line 2596, in test_default_ecdh_curve context.set_ciphers("ECDH") ssl.SSLError: ('No cipher can be selected.',) ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 11:51:52 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 07 Apr 2014 09:51:52 +0000 Subject: [issue21118] str.translate is absurdly slow in majority of use cases (takes up to 60x longer than similar functions) In-Reply-To: <1396861971.59.0.900511043624.issue21118@psf.upfronthosting.co.za> Message-ID: <1762023.U63M1LbC54@raxxla> Serhiy Storchaka added the comment: > > Do you plan to backport bug fixes to 3.3 and 2.7? > Which commit? A fix of _PyUnicode_TranslateCharmap(). > 3.3 is no more open to bug fixes, only to security fixes. Oh, I meant 3.4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 11:56:38 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 07 Apr 2014 09:56:38 +0000 Subject: [issue21118] str.translate is absurdly slow in majority of use cases (takes up to 60x longer than similar functions) In-Reply-To: <1396307346.31.0.221715925478.issue21118@psf.upfronthosting.co.za> Message-ID: <1396864598.77.0.363561265334.issue21118@psf.upfronthosting.co.za> STINNER Victor added the comment: > A fix of _PyUnicode_TranslateCharmap(). Sorry, I don't see which commit is a bugfix and is not backported to Python 3.4 yet. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 12:02:32 2014 From: report at bugs.python.org (=?utf-8?b?SHJ2b2plIE5pa8WhacSH?=) Date: Mon, 07 Apr 2014 10:02:32 +0000 Subject: [issue21167] float('nan') returns 0.0 on Python compiled with icc Message-ID: <1396864952.24.0.891595123462.issue21167@psf.upfronthosting.co.za> New submission from Hrvoje Nik?i?: On a Python compiled with Intel C compiler, float('nan') returns 0.0. This behavior can be reproduced with icc versions 11 and 12. The definition of Py_NAN in include/pymath.h expects `HUGE_VAL * 0.0` to compile to a NaN value on IEEE754 platforms: /* Py_NAN * A value that evaluates to a NaN. On IEEE 754 platforms INF*0 or * INF/INF works. Define Py_NO_NAN in pyconfig.h if your platform * doesn't support NaNs. */ #if !defined(Py_NAN) && !defined(Py_NO_NAN) #define Py_NAN (Py_HUGE_VAL * 0.) #endif I don't have a copy of the standard, but a simple test shows that the above does not hold for icc. When compiled with icc without any flags, the following program outputs "inf 0.000000" instead of the expected "inf nan": #include #include int main() { double inf = HUGE_VAL; double nan = HUGE_VAL * 0; printf("%f %f\n", inf, nan); return 0; } Compiling the same program with gcc yields the expected output of "inf nan". This issue can be fixed (or worked around, if it's an icc bug) by using a different definition of Py_NAN. On icc, defining Py_NAN as `Py_HUGE_VAL / Py_HUGE_VAL` produces the intended effect. If this is considered suboptimal on other compilers, the definition can be conditionally compiled for icc only. The attached patch fixes the issue, taking the conservative approach of only modifying the icc definition of Py_NAN. ---------- components: Interpreter Core files: intel-nan.diff keywords: patch messages: 215687 nosy: hniksic priority: normal severity: normal status: open title: float('nan') returns 0.0 on Python compiled with icc type: behavior versions: Python 2.7, Python 3.5 Added file: http://bugs.python.org/file34746/intel-nan.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 12:03:36 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 07 Apr 2014 10:03:36 +0000 Subject: [issue21167] float('nan') returns 0.0 on Python compiled with icc In-Reply-To: <1396864952.24.0.891595123462.issue21167@psf.upfronthosting.co.za> Message-ID: <1396865016.75.0.00596035816447.issue21167@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 12:06:05 2014 From: report at bugs.python.org (Stefan Krah) Date: Mon, 07 Apr 2014 10:06:05 +0000 Subject: [issue21015] support SSL_CTX_set_ecdh_auto on newer OpenSSLs In-Reply-To: <1395455671.92.0.144736574461.issue21015@psf.upfronthosting.co.za> Message-ID: <1396865165.9.0.308693163433.issue21015@psf.upfronthosting.co.za> Stefan Krah added the comment: FreeBSD 9 is failing as well: http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.0%203.x/builds/6583/steps/test/logs/stdio ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 12:11:05 2014 From: report at bugs.python.org (Stefan Krah) Date: Mon, 07 Apr 2014 10:11:05 +0000 Subject: [issue21167] float('nan') returns 0.0 on Python compiled with icc In-Reply-To: <1396864952.24.0.891595123462.issue21167@psf.upfronthosting.co.za> Message-ID: <1396865465.09.0.633479684546.issue21167@psf.upfronthosting.co.za> Stefan Krah added the comment: Did you compile with "-fp-model strict"? IIRC icc is not IEEE-754 compliant by default. ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 12:40:35 2014 From: report at bugs.python.org (=?utf-8?q?Jurica_Bradari=C4=87?=) Date: Mon, 07 Apr 2014 10:40:35 +0000 Subject: [issue21167] float('nan') returns 0.0 on Python compiled with icc In-Reply-To: <1396864952.24.0.891595123462.issue21167@psf.upfronthosting.co.za> Message-ID: <1396867235.61.0.83341222864.issue21167@psf.upfronthosting.co.za> Changes by Jurica Bradari? : ---------- nosy: +jbradaric _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 12:45:27 2014 From: report at bugs.python.org (Hristo Venev) Date: Mon, 07 Apr 2014 10:45:27 +0000 Subject: [issue1814] Victor Stinner's GMP patch for longs In-Reply-To: <1200157933.02.0.312333297821.issue1814@psf.upfronthosting.co.za> Message-ID: <1396867527.68.0.161435634848.issue1814@psf.upfronthosting.co.za> Hristo Venev added the comment: What about using PyVarObject of mp_limb_t and mpn instead of mpz_t? Addition: - Check signs and allocate. - Possibly compare absolute values. - Call mpn_(add|sub)_n and possibly mpn_(add|sub)_1 if the integers have different sizes. - Overhead for small integers: 1 Python->GMP, 1 if. Subtraction: - Same as addition Multiplication: - Check signs and allocate. - Call mpn_mul. - Overhead for small integers: 1 Python->GMP, 2 GMP->GMP, 3 if. Division: - Check signs and allocate. - Call mpn_div_q. - Overhead for small integers: 1 Python->GMP, 1 GMP->GMP, 1 if, maybe a 3 more ifs in mpn_divrem_1. Pow: - Create mpz_t values using MPZ_ROINIT_N(limbs, size) and call mpz_pow(m?). Copy from mpz_limbs_read(result). * The overhead is after checking if both arguments are integers until going to the right function (mpn_mul -> mpn_mul_n -> mpn_mul_basecase). Checks for adding integers < 1<<(GMP_NUMB_BITS-1), multiplying < 1<<(GMP_NUMB_BITS/2) and dividing < 1< _______________________________________ From report at bugs.python.org Mon Apr 7 12:59:13 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 07 Apr 2014 10:59:13 +0000 Subject: [issue1814] Victor Stinner's GMP patch for longs In-Reply-To: <1200157933.02.0.312333297821.issue1814@psf.upfronthosting.co.za> Message-ID: <1396868353.15.0.979588152349.issue1814@psf.upfronthosting.co.za> STINNER Victor added the comment: > What about using PyVarObject of mp_limb_t and mpn instead of mpz_t? FYI this issue is closed, it's not a good practice to comment closed issue (for example, the issue is hidden in the list of recent issues). If you want to learn more about my old patch, you should also read python-dev archives. Another major blocking point was the license: GMP is released under the GNU GPL license, which is incompatible with the Python License. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 13:04:39 2014 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 07 Apr 2014 11:04:39 +0000 Subject: [issue21167] float('nan') returns 0.0 on Python compiled with icc In-Reply-To: <1396864952.24.0.891595123462.issue21167@psf.upfronthosting.co.za> Message-ID: <1396868679.23.0.143551706966.issue21167@psf.upfronthosting.co.za> Mark Dickinson added the comment: What's `sys.float_repr_style` for this build? For Python 3.5 and short float repr, `float('nan')` shouldn't even be using Py_NAN. It should land in _Py_parse_inf_or_nan in pystrtod.c, which uses `_Py_dg_stdnan` to get the NaN value directly from a suitable bitpattern. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 13:08:40 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 07 Apr 2014 11:08:40 +0000 Subject: [issue21164] print unicode in Windows console In-Reply-To: <1396839472.79.0.493888101601.issue21164@psf.upfronthosting.co.za> Message-ID: <1396868920.46.0.884837755106.issue21164@psf.upfronthosting.co.za> STINNER Victor added the comment: Hi, when you say "The console" is the the old MS-DOS command ("Windows console") opened when you run the "cmd.exe" program? Or IDLE or another console? For the Windows console, see the old issue #1602 which is not fixed yet. On Windows, sys.stdout.encoding is your OEM code page, which is usually different than the ANSI code page (locale.getpreferredencoding()). ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 13:09:24 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 07 Apr 2014 11:09:24 +0000 Subject: [issue21168] unicodeobject.c: likely type-punning may break strict-aliasing rules Message-ID: <1396868964.72.0.411392590222.issue21168@psf.upfronthosting.co.za> New submission from STINNER Victor: http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.x%203.4/builds/48/steps/compile/logs/stdio Objects/unicodeobject.c: In function '_PyUnicode_Init': Objects/unicodeobject.c:582: warning: likely type-punning may break strict-aliasing rules: object '*data' of main type 'unsigned int' is referenced at or around Objects/unicodeobject.c:582 and may be aliased to object 'linebreak' of main type 'short unsigned int' which is referenced at or around Objects/unicodeobject.c:14933. According to koobs, it's gcc 4.2.1 on this buildbot. ---------- messages: 215694 nosy: haypo priority: normal severity: normal status: open title: unicodeobject.c: likely type-punning may break strict-aliasing rules versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 13:10:37 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 07 Apr 2014 11:10:37 +0000 Subject: [issue20035] Clean up Tcl library discovery in Tkinter on Windows In-Reply-To: <1387557050.08.0.350325342144.issue20035@psf.upfronthosting.co.za> Message-ID: <1396869037.23.0.949291283736.issue20035@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: TCL_VERSION should be set before call of Tcl_FindExecutable() (for correct Tcl encodings initialization). Tcl_FindExecutable() is called in PyInit__tkinter(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 13:11:56 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 07 Apr 2014 11:11:56 +0000 Subject: [issue21168] unicodeobject.c: likely type-punning may break strict-aliasing rules In-Reply-To: <1396868964.72.0.411392590222.issue21168@psf.upfronthosting.co.za> Message-ID: <1396869116.02.0.418404218387.issue21168@psf.upfronthosting.co.za> STINNER Victor added the comment: The warning comes from the make_bloom_mask() call below. make_bloom_mask() is called with kind=PyUnicode_2BYTE_KIND (Py_UCS2), whereas the gcc waring is about Py_UCS4. It looks like a false positive. static BLOOM_MASK bloom_linebreak = ~(BLOOM_MASK)0; ... Py_UCS2 linebreak[] = { ... }; /* initialize the linebreak bloom filter */ bloom_linebreak = make_bloom_mask( PyUnicode_2BYTE_KIND, linebreak, Py_ARRAY_LENGTH(linebreak)); ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 13:23:55 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 07 Apr 2014 11:23:55 +0000 Subject: [issue21169] getpass.getpass() fails with non-ASCII characters in prompt Message-ID: <1396869835.69.0.462900859226.issue21169@psf.upfronthosting.co.za> New submission from Arfrever Frehtes Taifersar Arahesis: getpass.getpass() fails with non-ASCII characters in prompt. The attached example scripts (for Python 2 and 3) contain non-ASCII unicode prompt (Polish "has?o" == English "password") written in UTF-8. Python-2 version fails always. Python-3 version fails in non-UTF-8 locale. $ ./getpass_test_python2 Traceback (most recent call last): File "./getpass_test_python2", line 5, in getpass.getpass(u"Has?o: ") File "/usr/lib64/python2.7/getpass.py", line 71, in unix_getpass passwd = _raw_input(prompt, stream, input=input) File "/usr/lib64/python2.7/getpass.py", line 128, in _raw_input prompt = str(prompt) UnicodeEncodeError: 'ascii' codec can't encode character u'\u0142' in position 3: ordinal not in range(128) $ LC_ALL="en_US.UTF-8" ./getpass_test_python3 Has?o: $ LC_ALL="C" ./getpass_test_python3 Traceback (most recent call last): File "./getpass_test_python3", line 5, in getpass.getpass("Has\u0142o: ") File "/usr/lib64/python3.4/getpass.py", line 78, in unix_getpass passwd = _raw_input(prompt, stream, input=input) File "/usr/lib64/python3.4/getpass.py", line 138, in _raw_input stream.write(prompt) UnicodeEncodeError: 'ascii' codec can't encode character '\u0142' in position 3: ordinal not in range(128) $ ---------- components: Library (Lib) keywords: easy messages: 215697 nosy: Arfrever priority: normal severity: normal stage: needs patch status: open title: getpass.getpass() fails with non-ASCII characters in prompt versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 13:24:09 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 07 Apr 2014 11:24:09 +0000 Subject: [issue21169] getpass.getpass() fails with non-ASCII characters in prompt In-Reply-To: <1396869835.69.0.462900859226.issue21169@psf.upfronthosting.co.za> Message-ID: <1396869849.13.0.868416527758.issue21169@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : Added file: http://bugs.python.org/file34747/getpass_test_python2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 13:24:18 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 07 Apr 2014 11:24:18 +0000 Subject: [issue21169] getpass.getpass() fails with non-ASCII characters in prompt In-Reply-To: <1396869835.69.0.462900859226.issue21169@psf.upfronthosting.co.za> Message-ID: <1396869858.48.0.29330049368.issue21169@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : Added file: http://bugs.python.org/file34748/getpass_test_python3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 13:25:31 2014 From: report at bugs.python.org (=?utf-8?b?SHJ2b2plIE5pa8WhacSH?=) Date: Mon, 07 Apr 2014 11:25:31 +0000 Subject: [issue21167] float('nan') returns 0.0 on Python compiled with icc In-Reply-To: <1396864952.24.0.891595123462.issue21167@psf.upfronthosting.co.za> Message-ID: <1396869931.98.0.400534563002.issue21167@psf.upfronthosting.co.za> Hrvoje Nik?i? added the comment: sys.float_repr_style is 'short'. I haven't actually tried this in Python 3.5, but I did note the same definition of Py_NAN (which is used elsewhere in the code), so I tagged the issue as likely also present in 3.x. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 13:27:08 2014 From: report at bugs.python.org (koobs) Date: Mon, 07 Apr 2014 11:27:08 +0000 Subject: [issue21166] Bus error on "AMD64 FreeBSD 9.x 3.4" buildbot In-Reply-To: <1396863177.29.0.753462829204.issue21166@psf.upfronthosting.co.za> Message-ID: <1396870028.65.0.682941630875.issue21166@psf.upfronthosting.co.za> koobs added the comment: Uploading gdb output at Victors request ---------- nosy: +koobs Added file: http://bugs.python.org/file34749/gdb.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 13:27:50 2014 From: report at bugs.python.org (=?utf-8?b?SHJ2b2plIE5pa8WhacSH?=) Date: Mon, 07 Apr 2014 11:27:50 +0000 Subject: [issue21167] float('nan') returns 0.0 on Python compiled with icc In-Reply-To: <1396864952.24.0.891595123462.issue21167@psf.upfronthosting.co.za> Message-ID: <1396870070.8.0.959402129026.issue21167@psf.upfronthosting.co.za> Hrvoje Nik?i? added the comment: The compilation was performed with the default flags, i.e. without -fp-model strict or similar. If Python requires strict IEEE 754 floating-point, it should probably be mentioned at a prominent place in the documentation. Administrators building Python with alternative compilers or on non-gcc Unix systems might not be aware of the issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 13:30:51 2014 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 07 Apr 2014 11:30:51 +0000 Subject: [issue21167] float('nan') returns 0.0 on Python compiled with icc In-Reply-To: <1396864952.24.0.891595123462.issue21167@psf.upfronthosting.co.za> Message-ID: <1396870251.03.0.64422722552.issue21167@psf.upfronthosting.co.za> Mark Dickinson added the comment: > I tagged the issue as likely also present in 3.x. So I believe that this particular issue (float('nan') giving zero) should not be present on Python 3.4 or above. The bogus definition of Py_NAN will still cause problems in some math and cmath return values, though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 13:31:01 2014 From: report at bugs.python.org (koobs) Date: Mon, 07 Apr 2014 11:31:01 +0000 Subject: [issue21166] Bus error on "AMD64 FreeBSD 9.x 3.4" buildbot In-Reply-To: <1396863177.29.0.753462829204.issue21166@psf.upfronthosting.co.za> Message-ID: <1396870261.68.0.853750593113.issue21166@psf.upfronthosting.co.za> koobs added the comment: Interestingly, I note the following lines from the gdb log: #5 0x0000000801ae1e99 in PyModule_Create2 () from /usr/local/lib/libpython3.4m.so.1 #6 0x0000000801840de8 in PyInit__heapq () from /usr/local/lib/python3.4/lib-dynload/_heapq.so I had installed Python 3.4 just prior to Victor reporting the issue. If its at all relevant, Python 3.4 was built using clang (not gcc, which the buildbots use) Removing Python 3.4 from the system and rebuilding makes the issue go away. The question is, what is ./python from the buildbot build directory doing using, loading or otherwise interacting with the python installation on the system in the first place? Is a lack of isolation the root cause? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 13:31:40 2014 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 07 Apr 2014 11:31:40 +0000 Subject: [issue21167] float('nan') returns 0.0 on Python compiled with icc In-Reply-To: <1396864952.24.0.891595123462.issue21167@psf.upfronthosting.co.za> Message-ID: <1396870300.39.0.418470152533.issue21167@psf.upfronthosting.co.za> Mark Dickinson added the comment: > If Python requires strict IEEE 754 floating-point, It doesn't (at the moment). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 13:33:03 2014 From: report at bugs.python.org (koobs) Date: Mon, 07 Apr 2014 11:33:03 +0000 Subject: [issue21166] Bus error on "AMD64 FreeBSD 9.x 3.4" buildbot In-Reply-To: <1396863177.29.0.753462829204.issue21166@psf.upfronthosting.co.za> Message-ID: <1396870383.55.0.382194318753.issue21166@psf.upfronthosting.co.za> koobs added the comment: Clarification: a) I had just installed Python 3.4 (at the system level, via ports) a) Removing Python 3.4 from the system and (forcing a rebuild of the buildbot) makes the issue go away. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 13:35:05 2014 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 07 Apr 2014 11:35:05 +0000 Subject: [issue21167] float('nan') returns 0.0 on Python compiled with icc In-Reply-To: <1396864952.24.0.891595123462.issue21167@psf.upfronthosting.co.za> Message-ID: <1396870505.38.0.947888273458.issue21167@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 13:40:31 2014 From: report at bugs.python.org (=?utf-8?b?SHJ2b2plIE5pa8WhacSH?=) Date: Mon, 07 Apr 2014 11:40:31 +0000 Subject: [issue21167] float('nan') returns 0.0 on Python compiled with icc In-Reply-To: <1396864952.24.0.891595123462.issue21167@psf.upfronthosting.co.za> Message-ID: <1396870831.17.0.534945654481.issue21167@psf.upfronthosting.co.za> Hrvoje Nik?i? added the comment: Mark: > > If Python requires strict IEEE 754 floating-point, > > It doesn't (at the moment). Does this imply that my patch is a better fix than requiring the builder to specify -fp-model strict to icc? For our use case either solution is valid. For administrators and users testing or using Python with icc, it might be more convenient for Py_NAN to do the right thing with the default icc flags. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 13:47:48 2014 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 07 Apr 2014 11:47:48 +0000 Subject: [issue21167] float('nan') returns 0.0 on Python compiled with icc In-Reply-To: <1396864952.24.0.891595123462.issue21167@psf.upfronthosting.co.za> Message-ID: <1396871268.3.0.830455523772.issue21167@psf.upfronthosting.co.za> Mark Dickinson added the comment: > It doesn't (at the moment). Sorry; that was an unhelpful kneejerk reply. There are two aspects to this. (1) Currently, at least in theory, CPython doesn't require IEEE 754 *at all*: in theory, it should work with whatever floating-point format the platform's "double" type happens to provide. In practice I suspect there's a lot more IEEE 754 dependence in the codebase than we realize, and I'd expect to see a fair amount of test breaking if Python were ever to meet a non-IEEE 754 platform. (Reports of any *recent* occurrences of Python in the wild meeting non-IEEE 754 platforms would be welcomed.) (2) If CPython *does* figure out that it's running on an IEEE 754 platform then yes, care should be taken with compiler flags to ensure that we're not using compiler optimisations that have the potential to break IEEE semantics. Without this there's a significant danger of float to string conversions getting messed up; there are also a few odds and ends in the math and cmath libraries that depend on careful IEEE semantics. (The implementations of fsum and log1p, for example.) I think the right fix here is to add the relevant compiler flag to the build. That said, I'd *also* love to see remaining uses of Py_NAN fixed to use _Py_dg_stdnan where available. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 14:24:29 2014 From: report at bugs.python.org (Stefan Krah) Date: Mon, 07 Apr 2014 12:24:29 +0000 Subject: [issue21167] float('nan') returns 0.0 on Python compiled with icc In-Reply-To: <1396871268.3.0.830455523772.issue21167@psf.upfronthosting.co.za> Message-ID: <20140407122428.GA15466@sleipnir.bytereef.org> Stefan Krah added the comment: I agree we should add "-fp-model strict" to the icc build flags, provided that there is a way that it does not show up in the distutils flags. Apparently icc users want unsafe fast math by default, so this flag should probably not be enforced in extension module builds. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 14:27:24 2014 From: report at bugs.python.org (Giampaolo Rodola') Date: Mon, 07 Apr 2014 12:27:24 +0000 Subject: [issue1191964] asynchronous Subprocess Message-ID: <1396873644.49.0.355178342837.issue1191964@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: Some initial comments here: http://bugs.python.org/review/1191964/#msg1. Also, if I think about integrating this into an IO loop it seems natural to me to think about timeouts. How complicated would it be to do this? data = proc.read_nonblocking(timeout=0) data = proc.read_stderr_nonblocking(timeout=0) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 16:33:13 2014 From: report at bugs.python.org (akira) Date: Mon, 07 Apr 2014 14:33:13 +0000 Subject: [issue1191964] asynchronous Subprocess Message-ID: <1396881193.11.0.31112538042.issue1191964@psf.upfronthosting.co.za> akira added the comment: > Also, Richard Oudkerk's claims above about not needing to use fcntl to swap flags is not correct. It's necessary to not block on reading, even if select is used. Select just guarantees that there is at least 1 byte or a closed handle, not that your full read will complete. On Linux, `fcntl` is not necessary if you use `os.read(pipe, bufsize)` after `select` instead of `pipe.read(bufsize)`. `os.read` may just return less than `bufsize` bytes if they are not available. ---------- nosy: +akira _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 16:39:19 2014 From: report at bugs.python.org (Volodymyr Sapsai) Date: Mon, 07 Apr 2014 14:39:19 +0000 Subject: [issue21170] Incorrect signature for unittest.TestResult.startTestRun(), .stopTestRun() Message-ID: <1396881559.52.0.157201741461.issue21170@psf.upfronthosting.co.za> New submission from Volodymyr Sapsai: Steps to reproduce: 1. Open docs for unittest.TestResult class. 2. Look at startTestRun() and stopTestRun() methods signatures (https://docs.python.org/3.4/library/unittest.html#unittest.TestResult.startTestRun) Actual result: It is stated that aforementioned methods accept 1 argument 'test'. Expected result: These methods don't accept any arguments, it should be stated so in the docs. ---------- assignee: docs at python components: Documentation messages: 215710 nosy: Volodymyr.Sapsai, docs at python priority: normal severity: normal status: open title: Incorrect signature for unittest.TestResult.startTestRun(), .stopTestRun() versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 16:55:56 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 07 Apr 2014 14:55:56 +0000 Subject: [issue21168] unicodeobject.c: likely type-punning may break strict-aliasing rules In-Reply-To: <1396868964.72.0.411392590222.issue21168@psf.upfronthosting.co.za> Message-ID: <1396882556.13.0.114096555234.issue21168@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 18:14:56 2014 From: report at bugs.python.org (Patrick Westerhoff) Date: Mon, 07 Apr 2014 16:14:56 +0000 Subject: [issue14373] C implementation of functools.lru_cache In-Reply-To: <1332250846.11.0.753199667334.issue14373@psf.upfronthosting.co.za> Message-ID: <1396887296.44.0.968340607823.issue14373@psf.upfronthosting.co.za> Changes by Patrick Westerhoff : ---------- nosy: +poke _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 18:15:01 2014 From: report at bugs.python.org (akira) Date: Mon, 07 Apr 2014 16:15:01 +0000 Subject: [issue1191964] asynchronous Subprocess Message-ID: <1396887301.73.0.311454308693.issue1191964@psf.upfronthosting.co.za> akira added the comment: Could `read_nonblocking()`, `write_nonblocking()` raise OSError(EAGAIN) (it could be named `ResourceTemporarilyUnavailableError`) if read/write would block? It would allow to distinguish EOF (permanent condition) from "read/write would block" (temporarily condition) without additional API calls. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 18:25:51 2014 From: report at bugs.python.org (=?utf-8?b?0JzQuNGF0LDQuNC7INCc0LjRiNCw0LrQuNC9?=) Date: Mon, 07 Apr 2014 16:25:51 +0000 Subject: [issue21171] Outdated usage str.encode('rot-13') in rot13 codec Message-ID: <1396887951.87.0.0918755245814.issue21171@psf.upfronthosting.co.za> New submission from ?????? ???????: Function rot13 in file "encodings/rot_13.py" throws exception: LookupError: 'rot-13' is not a text encoding; use codecs.encode() to handle arbitrary codecs ---------- messages: 215712 nosy: Pix priority: normal severity: normal status: open title: Outdated usage str.encode('rot-13') in rot13 codec type: enhancement versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 18:27:14 2014 From: report at bugs.python.org (=?utf-8?b?0JzQuNGF0LDQuNC7INCc0LjRiNCw0LrQuNC9?=) Date: Mon, 07 Apr 2014 16:27:14 +0000 Subject: [issue21171] Outdated usage str.encode('rot-13') in rot13 codec In-Reply-To: <1396887951.87.0.0918755245814.issue21171@psf.upfronthosting.co.za> Message-ID: <1396888034.27.0.370973071381.issue21171@psf.upfronthosting.co.za> Changes by ?????? ??????? : ---------- components: +Library (Lib) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 19:04:37 2014 From: report at bugs.python.org (Alan Briolat) Date: Mon, 07 Apr 2014 17:04:37 +0000 Subject: [issue21172] Unexpected behaviour with logging.LogRecord "first arg is dict" case Message-ID: <1396890277.61.0.522199976389.issue21172@psf.upfronthosting.co.za> New submission from Alan Briolat: The logging.LogRecord class is more restrictive with its "first arg is dict" case than the formatting operator it uses requires. As far as I can tell, for "%(foo)s" % bar, the minimum contract is that bar.__getitem__("foo") succeeds, not that bar is an instance of dict. However, fulfilling only this minimum contract results in LogRecord raising an exception at the point of applying the string format, which is confusing considering the "same" expression succeeds outside of logging. See the attached file for how 2 "equivalent" expressions behave completely differently. For resolution, I wonder if checking for "hasattr(..., '__getitem__')" instead of "isinstance(..., dict)" would be sufficient? ---------- components: Library (Lib) files: logging_format_bug.py messages: 215713 nosy: alan.briolat priority: normal severity: normal status: open title: Unexpected behaviour with logging.LogRecord "first arg is dict" case type: behavior versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file34750/logging_format_bug.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 19:25:31 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 07 Apr 2014 17:25:31 +0000 Subject: [issue21172] Unexpected behaviour with logging.LogRecord "first arg is dict" case In-Reply-To: <1396890277.61.0.522199976389.issue21172@psf.upfronthosting.co.za> Message-ID: <1396891531.84.0.601276055642.issue21172@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- assignee: -> vinay.sajip nosy: +vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 20:14:27 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 07 Apr 2014 18:14:27 +0000 Subject: [issue21139] Idle: change default reformat width from 70 to 72 In-Reply-To: <1396492163.57.0.51526901235.issue21139@psf.upfronthosting.co.za> Message-ID: <1396894467.08.0.0574658079801.issue21139@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Changing the default in the default configuration file is trivial. In test_formatparagraph.FormatEventTest, test_comment_block and test_long_line currently fail if the reformat width is changed on the General tab of the configuration dialog. These tests will need to be altered when the default is changed. Also, the tests should temporarily change the reformat width to the presumed default in the class setup and teardown methods. If this is not possible, the tests should be skipped if it is not what the test requires. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 21:07:21 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 07 Apr 2014 19:07:21 +0000 Subject: [issue15968] Incorporate Tcl/Tk/Tix into the Windows build process In-Reply-To: <1347996983.92.0.069726969781.issue15968@psf.upfronthosting.co.za> Message-ID: <1396897641.44.0.825909143035.issue15968@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I reran external.bat in all three versions and compile runs better. Test_idle with -ugui fails to find _tkinter after another test that runs tk (including itself) *in the same process*. Adding -j2 to run in separate process eliminates the problem. F:\Python\dev\5\py35>pcbuild\python_d -m test -j2 -ugui test_tcl test_idle So does not using test.test_support to run the tests. The following runs fine either at a command line or within Idle. (Does unittest run tests in a subprocess?) from test import support; support.use_resources = ['gui'] import unittest unittest.main('test.test_tcl', exit=False) unittest.main('test.test_idle', exit=False) ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 22:17:27 2014 From: report at bugs.python.org (Philip Jenvey) Date: Mon, 07 Apr 2014 20:17:27 +0000 Subject: [issue21173] WeakKeyDictionary.__len__ fragile w/ _IterationGuards Message-ID: <1396901847.85.0.817641964544.issue21173@psf.upfronthosting.co.za> New submission from Philip Jenvey: len() on WeakKeyDictionarys can fail with ValueErrors when _IterationGuards are kept alive Attached is a test showing this: ====================================================================== ERROR: test_weak_keys_len_destroy_while_iterating (__main__.MappingTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_weakref.py", line 1336, in test_weak_keys_len_destroy_while_iterating self.assertEqual(len(dict), 0) ValueError: __len__() should return >= 0 One probably shouldn't keep them alive like this, but __len__ shouldn't be blowing up either. On non ref counting GC platforms this situation is easier to trigger unintentionally ---------- components: Library (Lib) messages: 215716 nosy: pitrou, pjenvey priority: normal severity: normal status: open title: WeakKeyDictionary.__len__ fragile w/ _IterationGuards type: behavior versions: Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 22:18:22 2014 From: report at bugs.python.org (Philip Jenvey) Date: Mon, 07 Apr 2014 20:18:22 +0000 Subject: [issue21173] WeakKeyDictionary.__len__ fragile w/ _IterationGuards In-Reply-To: <1396901847.85.0.817641964544.issue21173@psf.upfronthosting.co.za> Message-ID: <1396901902.41.0.943478012235.issue21173@psf.upfronthosting.co.za> Changes by Philip Jenvey : ---------- keywords: +patch Added file: http://bugs.python.org/file34751/issue21173-test.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 23:00:01 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Mon, 07 Apr 2014 21:00:01 +0000 Subject: [issue21165] Optimize str.translate() for replacement with substrings and non-ASCII strings In-Reply-To: <1396861844.88.0.0543379452839.issue21165@psf.upfronthosting.co.za> Message-ID: <1396904401.53.0.787564165818.issue21165@psf.upfronthosting.co.za> Changes by Josh Rosenberg : ---------- nosy: +josh.rosenberg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 7 23:10:31 2014 From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=) Date: Mon, 07 Apr 2014 21:10:31 +0000 Subject: [issue21174] A typo in the docs for "exception GeneratorExit" Message-ID: <1396905031.09.0.19522982785.issue21174@psf.upfronthosting.co.za> New submission from Bo?tjan Mejak: The docs for the exception GeneratorExit starts like this: Raise when a generator?s close() method is called. The sentece should start with the first word "Raise" to say "Raised". You can find this particular doc sentence on this link: https://docs.python.org/2/library/exceptions.html#exceptions.GeneratorExit This is a small fix. Just add the letter "d". ---------- assignee: docs at python components: Documentation messages: 215717 nosy: Zvezdoslovec, docs at python priority: normal severity: normal status: open title: A typo in the docs for "exception GeneratorExit" type: enhancement versions: Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 01:10:56 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Mon, 07 Apr 2014 23:10:56 +0000 Subject: [issue21175] Refcounting error in str.translate fastpath Message-ID: <1396912256.62.0.455754100462.issue21175@psf.upfronthosting.co.za> New submission from Josh Rosenberg: Py_None is not being properly decref-ed in the str.translate fast path. I've attached a simple patch that fixes this (also corrects some comments and types in the same function). No idea is Py_None ref leaks are considered a serious problem, but I figure it's better to be safe than sorry. ---------- files: fix_translate_none.patch keywords: patch messages: 215718 nosy: haypo, josh.rosenberg priority: normal severity: normal status: open title: Refcounting error in str.translate fastpath type: behavior versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file34752/fix_translate_none.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 01:11:43 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Mon, 07 Apr 2014 23:11:43 +0000 Subject: [issue21175] Refcounting error in str.translate fastpath In-Reply-To: <1396912256.62.0.455754100462.issue21175@psf.upfronthosting.co.za> Message-ID: <1396912303.94.0.191036283679.issue21175@psf.upfronthosting.co.za> Josh Rosenberg added the comment: For reference, bug introduced by fix for #21118. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 01:13:25 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Mon, 07 Apr 2014 23:13:25 +0000 Subject: [issue21175] Refcounting error in str.translate fastpath In-Reply-To: <1396912256.62.0.455754100462.issue21175@psf.upfronthosting.co.za> Message-ID: <1396912405.22.0.35728095725.issue21175@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Also, just to be clear, I submitted the contributor form earlier this evening (using the online submission tool), so as soon as that propagates, it should be possible to accept my code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 01:35:44 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 07 Apr 2014 23:35:44 +0000 Subject: [issue21174] A typo in the docs for "exception GeneratorExit" In-Reply-To: <1396905031.09.0.19522982785.issue21174@psf.upfronthosting.co.za> Message-ID: <3g2p5q0XlWz7LjR@mail.python.org> Roundup Robot added the comment: New changeset aff368b58a98 by Benjamin Peterson in branch '2.7': fix verb (closes #21174) http://hg.python.org/cpython/rev/aff368b58a98 New changeset 33528b9520e6 by Benjamin Peterson in branch '3.4': fix verb (closes #21174) http://hg.python.org/cpython/rev/33528b9520e6 New changeset c48164710ed5 by Benjamin Peterson in branch 'default': merge 3.4 (#21174) http://hg.python.org/cpython/rev/c48164710ed5 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 02:16:20 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 08 Apr 2014 00:16:20 +0000 Subject: [issue21175] Refcounting error in str.translate fastpath In-Reply-To: <1396912256.62.0.455754100462.issue21175@psf.upfronthosting.co.za> Message-ID: <3g2q0c2B5mz7LkJ@mail.python.org> Roundup Robot added the comment: New changeset fa6debebfe8b by Benjamin Peterson in branch 'default': fix reference leaks in the translate fast path (closes #21175) http://hg.python.org/cpython/rev/fa6debebfe8b ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 04:31:55 2014 From: report at bugs.python.org (Alba Magallanes) Date: Tue, 08 Apr 2014 02:31:55 +0000 Subject: [issue1887] Document that distutils doesn't support out-of-source builds In-Reply-To: <1200961919.23.0.699852435444.issue1887@psf.upfronthosting.co.za> Message-ID: <1396924315.81.0.859095537343.issue1887@psf.upfronthosting.co.za> Alba Magallanes added the comment: hi, here is a second version of the patch. Please review it. ---------- keywords: +patch Added file: http://bugs.python.org/file34753/bug1887_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 04:51:35 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 08 Apr 2014 02:51:35 +0000 Subject: [issue21176] Implement matrix multiplication operator (PEP 465) Message-ID: <1396925495.01.0.281917881542.issue21176@psf.upfronthosting.co.za> New submission from Alexander Belopolsky: [Nathaniel Smith at numpy-discussion] Guido just formally accepted PEP 465: https://mail.python.org/pipermail/python-dev/2014-April/133819.html http://legacy.python.org/dev/peps/pep-0465/#implementation-details Yay. The next step is to implement it, in CPython and in numpy. I have time to advise on this, but not to do it myself, so, any volunteers? Ever wanted to hack on the interpreter itself, with BDFL guarantee your patch will be accepted (if correct)? The todo list for CPython is here: http://legacy.python.org/dev/peps/pep-0465/#implementation-details There's one open question which is where the type slots should be added. I'd just add them to PyNumberMethods and then if someone objects during patch review it can be changed. ---------- assignee: belopolsky components: Interpreter Core messages: 215724 nosy: belopolsky priority: normal severity: normal stage: needs patch status: open title: Implement matrix multiplication operator (PEP 465) type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 06:18:39 2014 From: report at bugs.python.org (Zachary Ware) Date: Tue, 08 Apr 2014 04:18:39 +0000 Subject: [issue20035] Clean up Tcl library discovery in Tkinter on Windows In-Reply-To: <1387557050.08.0.350325342144.issue20035@psf.upfronthosting.co.za> Message-ID: <1396930719.74.0.94594743717.issue20035@psf.upfronthosting.co.za> Zachary Ware added the comment: Serhiy Storchaka wrote: > TCL_VERSION should be set before call of Tcl_FindExecutable() (for correct Tcl > encodings initialization). Tcl_FindExecutable() is called in PyInit__tkinter(). I assume you mean TCL_LIBRARY (since TCL_VERSION is #defined in Tcl.h)? You are correct though, I missed that part of the comment at the top of tkinter._fix. However, I don't know what issues arise from not having TCL_LIBRARY set before Tcl_FindExecutable() (I haven't seen any problems, but I live in an ASCII world). Also, I have tried stepping through the Tcl_FindExecutable() call in PyInit__tkinter() with the VS debugger, and didn't see anything that looked like it was trying to read TCL_LIBRARY or hit the filesystem at all, which makes me suspect that it may not actually need TCL_LIBRARY prior to Tcl_FindExecutable(). Can you give me steps to reproduce problems with not having TCL_LIBRARY set that early? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 06:32:03 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 08 Apr 2014 04:32:03 +0000 Subject: [issue21176] Implement matrix multiplication operator (PEP 465) In-Reply-To: <1396925495.01.0.281917881542.issue21176@psf.upfronthosting.co.za> Message-ID: <1396931523.73.0.13243060275.issue21176@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Here's a first patch. It works, but needs more tests (associativity, precedence, __rmatmul__, etc...) and also docs. I can work on that tomorrow. ---------- keywords: +patch nosy: +benjamin.peterson Added file: http://bugs.python.org/file34754/mat-mult1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 06:33:42 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 08 Apr 2014 04:33:42 +0000 Subject: [issue21059] idle_test.test_warning failure In-Reply-To: <1395735174.52.0.231038807129.issue21059@psf.upfronthosting.co.za> Message-ID: <3g2wjf13B3z7LkR@mail.python.org> Roundup Robot added the comment: New changeset c507da0b573f by Zachary Ware in branch 'default': Issue #21059: Temporary measure to make the Windows buildbots useful again. http://hg.python.org/cpython/rev/c507da0b573f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 06:38:22 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Tue, 08 Apr 2014 04:38:22 +0000 Subject: [issue16395] Documentation claims that PySequence_Fast returns a tuple, when it actually returns a list. In-Reply-To: <1351955901.81.0.627286470446.issue16395@psf.upfronthosting.co.za> Message-ID: <1396931902.43.0.965270021363.issue16395@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Any news on this? I was about to open a bug of my own for this, since the docs and code are still out of sync. ---------- nosy: +josh.rosenberg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 06:40:19 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Tue, 08 Apr 2014 04:40:19 +0000 Subject: [issue16395] Documentation claims that PySequence_Fast returns a tuple, when it actually returns a list. In-Reply-To: <1351955901.81.0.627286470446.issue16395@psf.upfronthosting.co.za> Message-ID: <1396932019.23.0.538813881643.issue16395@psf.upfronthosting.co.za> Josh Rosenberg added the comment: As far as performance goes, presumably the length hinting API reduces the number of cases in which we're working with completely unsized iterables, right? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 06:41:21 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 08 Apr 2014 04:41:21 +0000 Subject: [issue21176] Implement matrix multiplication operator (PEP 465) In-Reply-To: <1396925495.01.0.281917881542.issue21176@psf.upfronthosting.co.za> Message-ID: <1396932081.04.0.615518052301.issue21176@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Here are changes to the operator module... ---------- Added file: http://bugs.python.org/file34755/mat-mult2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 06:57:24 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 08 Apr 2014 04:57:24 +0000 Subject: [issue21176] Implement matrix multiplication operator (PEP 465) In-Reply-To: <1396925495.01.0.281917881542.issue21176@psf.upfronthosting.co.za> Message-ID: <1396933044.11.0.741636744529.issue21176@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I've got to the point where I can do >>> import ast >>> ast.dump(ast.parse('a @ b')) "Module(body=[Expr(value=BinOp(left=Name(id='a', ctx=Load()), op=MatMult(), right=Name(id='b', ctx=Load())))])" I'll post a link to my bitbucket clone shortly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 07:00:03 2014 From: report at bugs.python.org (Berker Peksag) Date: Tue, 08 Apr 2014 05:00:03 +0000 Subject: [issue21171] Outdated usage str.encode('rot-13') in rot13 codec In-Reply-To: <1396887951.87.0.0918755245814.issue21171@psf.upfronthosting.co.za> Message-ID: <1396933203.58.0.293246265016.issue21171@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 07:01:24 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 08 Apr 2014 05:01:24 +0000 Subject: [issue21176] Implement matrix multiplication operator (PEP 465) In-Reply-To: <1396925495.01.0.281917881542.issue21176@psf.upfronthosting.co.za> Message-ID: <1396933284.89.0.789010233381.issue21176@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Here is a nearly complete patch... ---------- Added file: http://bugs.python.org/file34756/mat-mult3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 07:07:29 2014 From: report at bugs.python.org (Berker Peksag) Date: Tue, 08 Apr 2014 05:07:29 +0000 Subject: [issue21171] Outdated usage str.encode('rot-13') in rot13 codec In-Reply-To: <1396887951.87.0.0918755245814.issue21171@psf.upfronthosting.co.za> Message-ID: <1396933649.26.0.203444971314.issue21171@psf.upfronthosting.co.za> Berker Peksag added the comment: Here's a patch. I tested it with the following command: $ cat LICENSE | ./python -m encodings.rot_13 ---------- keywords: +patch nosy: +berker.peksag stage: -> patch review type: enhancement -> behavior Added file: http://bugs.python.org/file34757/issue21171.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 07:09:26 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 08 Apr 2014 05:09:26 +0000 Subject: [issue21176] Implement matrix multiplication operator (PEP 465) In-Reply-To: <1396925495.01.0.281917881542.issue21176@psf.upfronthosting.co.za> Message-ID: <1396933766.58.0.287017116117.issue21176@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Wow! That was quick. And I am still fighting with bitbucket. Maybe I should stop duplicating the effort at this point. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 07:14:42 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 08 Apr 2014 05:14:42 +0000 Subject: [issue21176] Implement matrix multiplication operator (PEP 465) In-Reply-To: <1396933766.58.0.287017116117.issue21176@psf.upfronthosting.co.za> Message-ID: <1396934078.20593.103956453.4C3C9C97@webmail.messagingengine.com> Benjamin Peterson added the comment: On Mon, Apr 7, 2014, at 22:09, Alexander Belopolsky wrote: > > Alexander Belopolsky added the comment: > > Wow! That was quick. And I am still fighting with bitbucket. Maybe I > should stop duplicating the effort at this point. Sorry about that. I only saw the first message, where Nathaniel invites an implementation. I didn't realize that was a direct quote from the mailing list (not by you) and didn't notice you also assigned it to yourself. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 07:23:04 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 08 Apr 2014 05:23:04 +0000 Subject: [issue21176] Implement matrix multiplication operator (PEP 465) In-Reply-To: <1396925495.01.0.281917881542.issue21176@psf.upfronthosting.co.za> Message-ID: <1396934584.67.0.508886905643.issue21176@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Thanks for stepping in. From a quick look at your patch I don't see anything that I would do much differently. I noticed some whitespace issues in Include/token.h: -#define AT 49 -#define RARROW 50 -#define ELLIPSIS 51 +#define AT 49 +#define ATEQUAL 50 +#define RARROW 51 +#define ELLIPSIS 52 (Are you sure you want to re-enumerate RARROW and ELLIPSIS? Why not just give ATEQUAL the value of 52?) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 07:25:30 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 08 Apr 2014 05:25:30 +0000 Subject: [issue21176] Implement matrix multiplication operator (PEP 465) In-Reply-To: <1396925495.01.0.281917881542.issue21176@psf.upfronthosting.co.za> Message-ID: <1396934730.44.0.585018643733.issue21176@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: + .. versionadded:: 3.4 Are you planning to use the time machine? :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 07:25:32 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 08 Apr 2014 05:25:32 +0000 Subject: [issue21176] Implement matrix multiplication operator (PEP 465) In-Reply-To: <1396934584.67.0.508886905643.issue21176@psf.upfronthosting.co.za> Message-ID: <1396934730.24089.103958857.793986B7@webmail.messagingengine.com> Benjamin Peterson added the comment: On Mon, Apr 7, 2014, at 22:23, Alexander Belopolsky wrote: > > Alexander Belopolsky added the comment: > > Thanks for stepping in. From a quick look at your patch I don't see > anything that I would do much differently. > > I noticed some whitespace issues in Include/token.h: > > -#define AT 49 > -#define RARROW 50 > -#define ELLIPSIS 51 > +#define AT 49 > +#define ATEQUAL 50 > +#define RARROW 51 > +#define ELLIPSIS 52 > > (Are you sure you want to re-enumerate RARROW and ELLIPSIS? Why not just > give ATEQUAL the value of 52?) I thought it would be nicer if ATEQUAL was right after AT. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 07:25:52 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 08 Apr 2014 05:25:52 +0000 Subject: [issue21176] Implement matrix multiplication operator (PEP 465) In-Reply-To: <1396934730.44.0.585018643733.issue21176@psf.upfronthosting.co.za> Message-ID: <1396934750.24567.103958913.07DFE012@webmail.messagingengine.com> Benjamin Peterson added the comment: On Mon, Apr 7, 2014, at 22:25, Alexander Belopolsky wrote: > > Alexander Belopolsky added the comment: > > + .. versionadded:: 3.4 > > Are you planning to use the time machine? :-) Good catch. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 07:26:55 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 08 Apr 2014 05:26:55 +0000 Subject: [issue21176] Implement matrix multiplication operator (PEP 465) In-Reply-To: <1396925495.01.0.281917881542.issue21176@psf.upfronthosting.co.za> Message-ID: <1396934815.08.0.969282282697.issue21176@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Here's my latest and greatest version. I'll finish up after some sleep. ---------- Added file: http://bugs.python.org/file34758/mat-mult4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 08:21:17 2014 From: report at bugs.python.org (Antony Lee) Date: Tue, 08 Apr 2014 06:21:17 +0000 Subject: [issue21127] Path objects cannot be constructed from str subclasses In-Reply-To: <1396390108.81.0.285327356985.issue21127@psf.upfronthosting.co.za> Message-ID: <1396938077.57.0.637977728509.issue21127@psf.upfronthosting.co.za> Antony Lee added the comment: The attached patch should fix the issue. ---------- keywords: +patch Added file: http://bugs.python.org/file34759/pathlib.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 09:14:31 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 08 Apr 2014 07:14:31 +0000 Subject: [issue21118] str.translate is absurdly slow in majority of use cases (takes up to 60x longer than similar functions) In-Reply-To: <1396307346.31.0.221715925478.issue21118@psf.upfronthosting.co.za> Message-ID: <3g30HB3cM4z7LjP@mail.python.org> Roundup Robot added the comment: New changeset cb632988bc09 by Victor Stinner in branch 'default': Issue #21118: PyLong_AS_LONG() result type is long http://hg.python.org/cpython/rev/cb632988bc09 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 09:15:34 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 08 Apr 2014 07:15:34 +0000 Subject: [issue21175] Refcounting error in str.translate fastpath In-Reply-To: <3g2q0c2B5mz7LkJ@mail.python.org> Message-ID: STINNER Victor added the comment: > New changeset fa6debebfe8b by Benjamin Peterson in branch 'default': > fix reference leaks in the translate fast path (closes #21175) > http://hg.python.org/cpython/rev/fa6debebfe8b Thanks Benjamin for the quick fix! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 10:33:50 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 08 Apr 2014 08:33:50 +0000 Subject: [issue19746] No introspective way to detect ModuleImportFailure in unittest In-Reply-To: <1385262963.63.0.210713286499.issue19746@psf.upfronthosting.co.za> Message-ID: <1396946030.37.0.471701661578.issue19746@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 10:54:10 2014 From: report at bugs.python.org (Konstantin Zemlyak) Date: Tue, 08 Apr 2014 08:54:10 +0000 Subject: [issue21177] ValueError: byte must be in range(0, 256) Message-ID: <1396947250.75.0.807471111064.issue21177@psf.upfronthosting.co.za> New submission from Konstantin Zemlyak: Python 3.4.0 (v3.4.0:04f714765c13, Mar 16 2014, 19:25:23) [MSC v.1600 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> bytearray([256]) Traceback (most recent call last): File "", line 1, in ValueError: byte must be in range(0, 256) >>> bytes([256]) Traceback (most recent call last): File "", line 1, in ValueError: bytes must be in range(0, 256) >>> Tested on 2.7, 3.2, 3.3, 3.4. Frankly, this looks like an off-by-one error to me. ---------- components: Interpreter Core messages: 215744 nosy: zart priority: normal severity: normal status: open title: ValueError: byte must be in range(0, 256) type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 10:57:00 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 08 Apr 2014 08:57:00 +0000 Subject: [issue21177] ValueError: byte must be in range(0, 256) In-Reply-To: <1396947250.75.0.807471111064.issue21177@psf.upfronthosting.co.za> Message-ID: <1396947420.46.0.418170401011.issue21177@psf.upfronthosting.co.za> STINNER Victor added the comment: 256 is not part of the range(0, 256): 0..255. $ python >>> print(list(range(0,256))) [0, 1, 2, 3, ..., 253, 254, 255] It doesn't make sense to store the number 256 in a byte string. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 11:05:31 2014 From: report at bugs.python.org (akira) Date: Tue, 08 Apr 2014 09:05:31 +0000 Subject: [issue21041] pathlib.PurePath.parents rejects negative indexes In-Reply-To: <1395613011.22.0.29152070109.issue21041@psf.upfronthosting.co.za> Message-ID: <1396947931.09.0.571136039508.issue21041@psf.upfronthosting.co.za> akira added the comment: >From https://docs.python.org/3/glossary.html#term-sequence > An iterable which supports efficient element access using integer indices via the __getitem__() special method and defines a __len__() method that returns the length of the sequence. .parents *is* a sequence. And it *is* confusing that it doesn't accept negative indexes -- that is how I've encountered the bug. Antoine, could you elaborate on what are the negative consequences of negative indexes to justify breaking the expectations? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 11:38:24 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 08 Apr 2014 09:38:24 +0000 Subject: [issue21177] ValueError: byte must be in range(0, 256) In-Reply-To: <1396947250.75.0.807471111064.issue21177@psf.upfronthosting.co.za> Message-ID: <1396949904.54.0.0199128580784.issue21177@psf.upfronthosting.co.za> Stefan Krah added the comment: I think it's possible to misunderstand this error message if the reader does not realize that range(0, 256) is to be taken literally. Perhaps we should just use closed intervals of the form [0, 255] everywhere. ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 11:39:25 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 08 Apr 2014 09:39:25 +0000 Subject: [issue21177] ValueError: byte must be in range(0, 256) In-Reply-To: <1396947250.75.0.807471111064.issue21177@psf.upfronthosting.co.za> Message-ID: <1396949965.28.0.886047487331.issue21177@psf.upfronthosting.co.za> STINNER Victor added the comment: "Perhaps we should just use closed intervals of the form [0, 255] everywhere." I only saw range(0, 256) in Python. At school, I used [0, 255]. I prefer [0, 255] syntax, it's more explicit :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 11:56:58 2014 From: report at bugs.python.org (Peter Otten) Date: Tue, 08 Apr 2014 09:56:58 +0000 Subject: [issue21177] ValueError: byte must be in range(0, 256) In-Reply-To: <1396947250.75.0.807471111064.issue21177@psf.upfronthosting.co.za> Message-ID: <1396951018.8.0.0646144402715.issue21177@psf.upfronthosting.co.za> Peter Otten added the comment: As every beginner will learn about (and probably overuse) range() pretty soon I think it's OK to use that form. The math-inspired notation [0, 255] may be misinterpreted as a list. You also lose the consistency of preferring half-open intervals everywhere. The third alternative I see, 0 <= x < 256 has the problem that it requires a name (the 'x') that may not correspond to a variable in the source code. You'd also need to clarify that x must be an int to make the message bulletproof. I think this should be left as is. ---------- nosy: +peter.otten _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 12:49:06 2014 From: report at bugs.python.org (=?utf-8?q?Ontje_L=C3=BCnsdorf?=) Date: Tue, 08 Apr 2014 10:49:06 +0000 Subject: [issue21178] doctest cause warnings in tests using generators Message-ID: <1396954146.87.0.0393521418681.issue21178@psf.upfronthosting.co.za> New submission from Ontje L?nsdorf: The attached doctest raises a warning since Python 3.4: $ python -m doctest doctest.txt Exception ignored in: Traceback (most recent call last): File "", line 4, in foo NameError: name 'socket' is not defined My guess is that doctest cleans up globals() of the test snippet (thereby deleting socket). Afterwards python cleans up the generator by sending in a GeneratorExit exception. The except block will now fail because socket is not available anymore. ---------- components: Tests files: doctest.txt messages: 215750 nosy: oluensdorf priority: normal severity: normal status: open title: doctest cause warnings in tests using generators type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file34760/doctest.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 12:54:01 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 08 Apr 2014 10:54:01 +0000 Subject: [issue21177] ValueError: byte must be in range(0, 256) In-Reply-To: <1396951018.8.0.0646144402715.issue21177@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > The math-inspired notation [0, 255] may be misinterpreted as a list. You also lose the consistency of preferring half-open intervals everywhere. Not if you write "x must in the range [0; 255]". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 12:56:57 2014 From: report at bugs.python.org (Vinay Sajip) Date: Tue, 08 Apr 2014 10:56:57 +0000 Subject: [issue21172] Unexpected behaviour with logging.LogRecord "first arg is dict" case In-Reply-To: <1396890277.61.0.522199976389.issue21172@psf.upfronthosting.co.za> Message-ID: <1396954617.29.0.755157984085.issue21172@psf.upfronthosting.co.za> Vinay Sajip added the comment: I wouldn't say it is a bug, as it is working as documented - though you might say it is a request for enhancement. The documentation for string formatting at https://docs.python.org/2/library/stdtypes.html#string-formatting-operations says that the argument should be a "single mapping object", and, further down the same page at https://docs.python.org/2/library/stdtypes.html#mapping-types-dict it's clear that the mapping protocol is more than just __getitem__. Although perhaps currently only __getitem__ is used, who's to say that such will always remain the case? Removing Python versions 3.2, 3.3 (security fixes only). ---------- versions: -Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 12:57:19 2014 From: report at bugs.python.org (Vinay Sajip) Date: Tue, 08 Apr 2014 10:57:19 +0000 Subject: [issue21172] Unexpected behaviour with logging.LogRecord "first arg is dict" case In-Reply-To: <1396890277.61.0.522199976389.issue21172@psf.upfronthosting.co.za> Message-ID: <1396954638.99.0.722044072394.issue21172@psf.upfronthosting.co.za> Changes by Vinay Sajip : ---------- type: behavior -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 12:58:58 2014 From: report at bugs.python.org (Clinton Curry) Date: Tue, 08 Apr 2014 10:58:58 +0000 Subject: [issue21179] Rounding half to even Message-ID: <1396954738.37.0.54879370291.issue21179@psf.upfronthosting.co.za> New submission from Clinton Curry: In the current Python 2.7 documentation, Section 5.4 https://docs.python.org/2.7/library/stdtypes.html the result of the round function is described as "x rounded to n digits, rounding half to even. If n is omitted, it defaults to 0." However, my observed behavior (Python 2.7.4 (default, Apr 6 2013, 19:55:15) [MSC v.1500 64 bit (AMD64)] on win32) does not round half to even, but rounds half away from zero. >>> round(1.5) 2.0 >>> round(2.5) 3.0 >>> round(-1.5) -2.0 >>> round(-2.5) -3.0 I observe similar behavior on other platforms. ---------- assignee: docs at python components: Documentation messages: 215753 nosy: Clinton.Curry, docs at python, eric.araujo, ezio.melotti, georg.brandl priority: normal severity: normal status: open title: Rounding half to even versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 13:40:32 2014 From: report at bugs.python.org (Vinay Sajip) Date: Tue, 08 Apr 2014 11:40:32 +0000 Subject: [issue21172] Unexpected behaviour with logging.LogRecord "first arg is dict" case In-Reply-To: <1396890277.61.0.522199976389.issue21172@psf.upfronthosting.co.za> Message-ID: <1396957232.49.0.252434195947.issue21172@psf.upfronthosting.co.za> Vinay Sajip added the comment: Looking into it further, I see no incidence in logging code of the string "format requires a mapping" or of raising a TypeError with such a message. Can you provide more information? Otherwise I will have to close this issue as invalid. ---------- resolution: -> invalid status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 14:11:32 2014 From: report at bugs.python.org (=?utf-8?q?Ontje_L=C3=BCnsdorf?=) Date: Tue, 08 Apr 2014 12:11:32 +0000 Subject: [issue21178] doctest cause warnings in tests using generators In-Reply-To: <1396954146.87.0.0393521418681.issue21178@psf.upfronthosting.co.za> Message-ID: <1396959092.6.0.128704339662.issue21178@psf.upfronthosting.co.za> Ontje L?nsdorf added the comment: Sorry, the test does not really expose the problem with Python 3.4. Here is an updated example. Python 2.7 and 3.3 succeed without warnings, while Python 3.4 warns about an ignored exception. ---------- Added file: http://bugs.python.org/file34761/doctest.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 14:19:49 2014 From: report at bugs.python.org (Alan Briolat) Date: Tue, 08 Apr 2014 12:19:49 +0000 Subject: [issue21172] Unexpected behaviour with logging.LogRecord "first arg is dict" case In-Reply-To: <1396890277.61.0.522199976389.issue21172@psf.upfronthosting.co.za> Message-ID: <1396959589.33.0.585279288772.issue21172@psf.upfronthosting.co.za> Alan Briolat added the comment: Because the object in question is not actually a dict, LogRecord is attempting, in this example, "%(bar)s" % (f,) instead of "%(bar)s" % f. In unicodeobject.c this causes the PyMapping_Check in PyUnicode_Format to fail because it's a tuple (note that PyMapping_Check *only* checks for the __getitem__ attribute), the argument to not be treated as a dict, and consequently ctx.dict = NULL for the format operation. This condition, combined with still attempting to resolve named values in the format string, causes unicode_format_arg_parse to raise the TypeError("format requires a mapping"). Speaking of documentation, the language of https://docs.python.org/2/library/logging.html#logging.Logger.debug strongly suggests that logging.debug(msg, args...) should be considered equivalent to logging.debug(msg % args...), which still means this is still "unexpected" behaviour. The intention is clearly to allow this special case to pass through to the formatting operator unimpeded, however this doesn't happen. Also, even if "the mapping protocol" should remain the key concept (the behaviour of PyMapping_Check being a happy accident), checking for isinstance(..., dict) is still wrong - it should at least be collections.Mapping to give users a chance to emulate the correct interface. ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 15:15:20 2014 From: report at bugs.python.org (Paul Sokolovsky) Date: Tue, 08 Apr 2014 13:15:20 +0000 Subject: [issue17145] memoryview(array.array) In-Reply-To: <1360170754.31.0.614797074916.issue17145@psf.upfronthosting.co.za> Message-ID: <1396962920.48.0.388206590109.issue17145@psf.upfronthosting.co.za> Changes by Paul Sokolovsky : ---------- nosy: +pfalcon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 15:32:06 2014 From: report at bugs.python.org (Paul Sokolovsky) Date: Tue, 08 Apr 2014 13:32:06 +0000 Subject: [issue21180] Cannot efficiently create empty array.array of given size, inconsistency with bytearray Message-ID: <1396963926.18.0.0845457465299.issue21180@psf.upfronthosting.co.za> New submission from Paul Sokolovsky: With bytearray, you can do: >>> bytearray(3) bytearray(b'\x00\x00\x00') However, with arrays: >>> array.array('i', 3) Traceback (most recent call last): File "", line 1, in TypeError: 'int' object is not iterable Given that int passed as seconf argument is not handled specially in array, I'd like to propose to make it an initial size of a zero-filled array to create. This will make it: a) consitent with bytearray; b) efficient for the scenarios where one needs to pre-create array of given length, pass to some (native) function to fill in, then do rest of processing. For the latter case, assuming that both fill-in and further processing is efficient (e.g. done by native function), the initial array creation becomes a bottleneck. ---------- components: Library (Lib) messages: 215757 nosy: pfalcon priority: normal severity: normal status: open title: Cannot efficiently create empty array.array of given size, inconsistency with bytearray type: performance versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 15:35:15 2014 From: report at bugs.python.org (Paul Sokolovsky) Date: Tue, 08 Apr 2014 13:35:15 +0000 Subject: [issue9066] Standard type codes for array.array, same as struct In-Reply-To: <1277355510.37.0.62223618655.issue9066@psf.upfronthosting.co.za> Message-ID: <1396964115.52.0.50953347561.issue9066@psf.upfronthosting.co.za> Paul Sokolovsky added the comment: > It's not clear to me that importing specifier prefixes from the struct module is the best way to go about this, though. What are other alternatives then? Using struct's syntax has obvious benefit of being consistent and not confusing people any further. ---------- nosy: +pfalcon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 15:37:47 2014 From: report at bugs.python.org (Paul Sokolovsky) Date: Tue, 08 Apr 2014 13:37:47 +0000 Subject: [issue17345] Portable and extended type specifiers for array module In-Reply-To: <1362385577.82.0.862277690656.issue17345@psf.upfronthosting.co.za> Message-ID: <1396964267.57.0.238137664488.issue17345@psf.upfronthosting.co.za> Paul Sokolovsky added the comment: See also http://bugs.python.org/issue9066 ---------- nosy: +pfalcon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 15:38:09 2014 From: report at bugs.python.org (Paul Sokolovsky) Date: Tue, 08 Apr 2014 13:38:09 +0000 Subject: [issue9066] Standard type codes for array.array, same as struct In-Reply-To: <1277355510.37.0.62223618655.issue9066@psf.upfronthosting.co.za> Message-ID: <1396964289.34.0.0860376999587.issue9066@psf.upfronthosting.co.za> Paul Sokolovsky added the comment: See also http://bugs.python.org/issue17345 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 16:40:45 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 08 Apr 2014 14:40:45 +0000 Subject: [issue16395] Documentation claims that PySequence_Fast returns a tuple, when it actually returns a list. In-Reply-To: <1351955901.81.0.627286470446.issue16395@psf.upfronthosting.co.za> Message-ID: <1396968045.51.0.977178672021.issue16395@psf.upfronthosting.co.za> Larry Hastings added the comment: I have no objections to someone backporting this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 16:42:13 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 08 Apr 2014 14:42:13 +0000 Subject: [issue21176] Implement matrix multiplication operator (PEP 465) In-Reply-To: <1396925495.01.0.281917881542.issue21176@psf.upfronthosting.co.za> Message-ID: <1396968133.8.0.885362068441.issue21176@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Here's what I consider a complete patch. ---------- assignee: belopolsky -> benjamin.peterson Added file: http://bugs.python.org/file34762/mat-mult5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 16:49:17 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 08 Apr 2014 14:49:17 +0000 Subject: [issue16395] Documentation claims that PySequence_Fast returns a tuple, when it actually returns a list. In-Reply-To: <1351955901.81.0.627286470446.issue16395@psf.upfronthosting.co.za> Message-ID: <3g3BMw58kzz7Ljj@mail.python.org> Roundup Robot added the comment: New changeset b2187b82a658 by Benjamin Peterson in branch '3.4': PySequence_Fast generally returns a list not a tuple (closes #16395) http://hg.python.org/cpython/rev/b2187b82a658 New changeset b235db467cd5 by Benjamin Peterson in branch '2.7': PySequence_Fast generally returns a list not a tuple (closes #16395) http://hg.python.org/cpython/rev/b235db467cd5 New changeset c833c35aa13a by Benjamin Peterson in branch 'default': merge 3.4 (#16395) http://hg.python.org/cpython/rev/c833c35aa13a ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 16:51:02 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 08 Apr 2014 14:51:02 +0000 Subject: [issue16305] possible segfault in math.factorial In-Reply-To: <1351031608.7.0.419151487248.issue16305@psf.upfronthosting.co.za> Message-ID: <3g3BPx66rQz7Lmr@mail.python.org> Roundup Robot added the comment: New changeset 3016a9e8061a by Benjamin Peterson in branch '2.7': PySequence_Fast generally returns a list (#16305) http://hg.python.org/cpython/rev/3016a9e8061a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 16:55:27 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 08 Apr 2014 14:55:27 +0000 Subject: [issue16305] possible segfault in math.factorial In-Reply-To: <1351031608.7.0.419151487248.issue16305@psf.upfronthosting.co.za> Message-ID: <1396968927.0.0.492248247624.issue16305@psf.upfronthosting.co.za> Benjamin Peterson added the comment: (Obviously that last message should have gone to #16395 instead.) ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 17:10:44 2014 From: report at bugs.python.org (Roman O. Vlasov) Date: Tue, 08 Apr 2014 15:10:44 +0000 Subject: [issue20924] openssl init 100% CPU utilization In-Reply-To: <1394807354.77.0.238568366714.issue20924@psf.upfronthosting.co.za> Message-ID: <1396969844.66.0.856597876799.issue20924@psf.upfronthosting.co.za> Roman O. Vlasov added the comment: Antoine, Martin, thank you for your replies. You was right: NT socket was not in blocking mode (in 1st case). I didn't knew how to determine socket mode in NT, so I explicitly set socket mode to blocking in _ssl.c before calling SSL_do_handshake() for test: _ssl.c::PySSL_SSLdo_handshake(): // ------------ Explicitly set blocking mode unsigned long iMode = 0UL; // If iMode = 0, blocking is enabled; int iResult = ioctlsocket( self->Socket->sock_fd, FIONBIO, &iMode ); if (iResult != NO_ERROR) printf("\nioctlsocket failed with error: %ld\n", iResult); // ------------ PySSL_BEGIN_ALLOW_THREADS ret = SSL_do_handshake(self->ssl); ... Test result: SSL_do_handshake() did not return (and no CPU load). But in general, I think that check_socket_and_wait_for_timeout() logic is erroneous: if (s->sock_timeout < 0.0) return SOCKET_IS_BLOCKING; By default (see case #1 in my message above), timeout in Python wrapping object is -1 (self->Socket->sock_timeout==-1). But underlying NT socket is really non-blocking. This leads to 100% CPU load: PySSL_SSLdo_handshake() loop is calling check_socket_and_wait_for_timeout() which immediately returns. NB. I use Python 2.7.6 and openssl-0.9.8y for my build and never tried Python 3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 17:31:10 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 08 Apr 2014 15:31:10 +0000 Subject: [issue21117] inspect.signature: inaccuracies for partial functions In-Reply-To: <1396297836.4.0.601810070188.issue21117@psf.upfronthosting.co.za> Message-ID: <3g3CJF6dqPz7Lns@mail.python.org> Roundup Robot added the comment: New changeset acbdbf2b06e0 by Yury Selivanov in branch '3.4': inspect.signautre: Fix functools.partial support. Issue #21117 http://hg.python.org/cpython/rev/acbdbf2b06e0 New changeset 21709cb4a8f5 by Yury Selivanov in branch 'default': inspect.signautre: Fix functools.partial support. Issue #21117 http://hg.python.org/cpython/rev/21709cb4a8f5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 17:32:44 2014 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 08 Apr 2014 15:32:44 +0000 Subject: [issue21117] inspect.signature: inaccuracies for partial functions In-Reply-To: <1396297836.4.0.601810070188.issue21117@psf.upfronthosting.co.za> Message-ID: <1396971164.07.0.678058092476.issue21117@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 17:47:11 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 08 Apr 2014 15:47:11 +0000 Subject: [issue20334] make inspect Signature hashable In-Reply-To: <1390323024.99.0.45103178025.issue20334@psf.upfronthosting.co.za> Message-ID: <3g3Cfk3cQ8z7LpZ@mail.python.org> Roundup Robot added the comment: New changeset 932d69ef0c63 by Yury Selivanov in branch 'default': inspect: Make Signature and Parameter hashable. Issue #20334. http://hg.python.org/cpython/rev/932d69ef0c63 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 17:47:22 2014 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 08 Apr 2014 15:47:22 +0000 Subject: [issue20334] make inspect Signature hashable In-Reply-To: <1390323024.99.0.45103178025.issue20334@psf.upfronthosting.co.za> Message-ID: <1396972042.8.0.200229848943.issue20334@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 18:06:53 2014 From: report at bugs.python.org (Nikolaus Demmel) Date: Tue, 08 Apr 2014 16:06:53 +0000 Subject: [issue21144] ensurepip "AssertionError: Multiple .dist-info directories" In-Reply-To: <1396520627.59.0.769231802002.issue21144@psf.upfronthosting.co.za> Message-ID: <1396973213.52.0.825652684802.issue21144@psf.upfronthosting.co.za> Nikolaus Demmel added the comment: I could resolve this by removing /usr/local/lib/python3.4/site-packages and then retrying. Now I cannot reproduce this issue any more. Maybe we can close this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 18:07:30 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 08 Apr 2014 16:07:30 +0000 Subject: [issue19281] add __objclass__ to the docs In-Reply-To: <1382082111.84.0.378259232568.issue19281@psf.upfronthosting.co.za> Message-ID: <3g3D696TRlz7Lnt@mail.python.org> Roundup Robot added the comment: New changeset 0973d45197cc by Yury Selivanov in branch '3.4': docs: Document __objclass__. Closes #19281. http://hg.python.org/cpython/rev/0973d45197cc New changeset 2a953cb5642d by Yury Selivanov in branch 'default': docs: Document __objclass__. Closes #19281. http://hg.python.org/cpython/rev/2a953cb5642d ---------- nosy: +python-dev resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 18:12:02 2014 From: report at bugs.python.org (Saimadhav Heblikar) Date: Tue, 08 Apr 2014 16:12:02 +0000 Subject: [issue21139] Idle: change default reformat width from 70 to 72 In-Reply-To: <1396492163.57.0.51526901235.issue21139@psf.upfronthosting.co.za> Message-ID: <1396973522.24.0.115255486654.issue21139@psf.upfronthosting.co.za> Saimadhav Heblikar added the comment: Attaching a patch for 2.7 and 3.4 The comment strings are modified to reflect 70->72 in the tests. ---------- keywords: +patch Added file: http://bugs.python.org/file34763/issue21139-27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 18:12:22 2014 From: report at bugs.python.org (Saimadhav Heblikar) Date: Tue, 08 Apr 2014 16:12:22 +0000 Subject: [issue21139] Idle: change default reformat width from 70 to 72 In-Reply-To: <1396492163.57.0.51526901235.issue21139@psf.upfronthosting.co.za> Message-ID: <1396973542.29.0.471115562698.issue21139@psf.upfronthosting.co.za> Changes by Saimadhav Heblikar : Added file: http://bugs.python.org/file34764/issue21139-34.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 18:35:50 2014 From: report at bugs.python.org (Jim Peterson) Date: Tue, 08 Apr 2014 16:35:50 +0000 Subject: [issue21181] Inconsistent Definition of collections.namedtuple.__dict__ in _source Message-ID: <1396974950.77.0.151698168246.issue21181@psf.upfronthosting.co.za> New submission from Jim Peterson: The result returned by somenamedtuple._source seem inconsistent, in that it defines __dict__ as: __dict__ = property(_asdict) even though it imports property as: from builtins import property as _property and the namedtuple fields are defined using _property, instead. It still compiles and functions properly, but whatever compelled the developer to declare the named fields using _property seems to be ignored in the definition of __dict__. ---------- components: Library (Lib) messages: 215772 nosy: Jim.Peterson priority: normal severity: normal status: open title: Inconsistent Definition of collections.namedtuple.__dict__ in _source type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 18:49:08 2014 From: report at bugs.python.org (Wolfgang Maier) Date: Tue, 08 Apr 2014 16:49:08 +0000 Subject: [issue21146] update gzip usage examples in docs In-Reply-To: <1396521606.53.0.161098821761.issue21146@psf.upfronthosting.co.za> Message-ID: <1396975748.53.0.920546970479.issue21146@psf.upfronthosting.co.za> Wolfgang Maier added the comment: ok, I've prepared the patch using the elegant shutil solution. ---------- keywords: +patch Added file: http://bugs.python.org/file34765/gzip_example_usage_patch.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 19:12:23 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 08 Apr 2014 17:12:23 +0000 Subject: [issue21180] Cannot efficiently create empty array.array of given size, inconsistency with bytearray In-Reply-To: <1396963926.18.0.0845457465299.issue21180@psf.upfronthosting.co.za> Message-ID: <1396977143.45.0.165471586827.issue21180@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: >>> array.array('i', [0]) * 3 array('i', [0, 0, 0]) ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 20:01:19 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 08 Apr 2014 18:01:19 +0000 Subject: [issue19281] add __objclass__ to the docs In-Reply-To: <1382082111.84.0.378259232568.issue19281@psf.upfronthosting.co.za> Message-ID: <3g3GdW00PGz7Lm6@mail.python.org> Roundup Robot added the comment: New changeset 372b19005011 by Yury Selivanov in branch '3.4': docs: Better wording for __objclass__ docs. Issue #19281 http://hg.python.org/cpython/rev/372b19005011 New changeset febd63a7e927 by Yury Selivanov in branch 'default': docs: Better wording for __objclass__ docs. Issue #19281 http://hg.python.org/cpython/rev/febd63a7e927 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 21:26:45 2014 From: report at bugs.python.org (Ned Deily) Date: Tue, 08 Apr 2014 19:26:45 +0000 Subject: [issue21144] ensurepip "AssertionError: Multiple .dist-info directories" In-Reply-To: <1396520627.59.0.769231802002.issue21144@psf.upfronthosting.co.za> Message-ID: <1396985205.03.0.44401069842.issue21144@psf.upfronthosting.co.za> Ned Deily added the comment: That error appears to be coming from wheel.py inside of pip. So, if you do want to pursue it, you should probably be asking on the pip tracker: https://github.com/pypa/pip/issues ---------- nosy: +ned.deily resolution: -> 3rd party stage: -> committed/rejected status: open -> closed type: crash -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 22:53:05 2014 From: report at bugs.python.org (paul j3) Date: Tue, 08 Apr 2014 20:53:05 +0000 Subject: [issue11588] Add "necessarily inclusive" groups to argparse In-Reply-To: <1300377092.03.0.159307937388.issue11588@psf.upfronthosting.co.za> Message-ID: <1396990385.86.0.83132354024.issue11588@psf.upfronthosting.co.za> paul j3 added the comment: http://stackoverflow.com/questions/22929087 A question that could be addressed with this patch(es) In a subparser: I have 4 arguments: -g, -wid, -w1, and -w2. -w1 and -w2 always appear together -wid and (-w1 -w2) are mutually exclusive, but one or the other is required -g is optional; if it is not specified only (-w1 -w2) can appear, but not -wid The `g` case does not fit either the inclusive or exclusive group patterns. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 23:21:16 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Tue, 08 Apr 2014 21:21:16 +0000 Subject: [issue9066] Standard type codes for array.array, same as struct In-Reply-To: <1277355510.37.0.62223618655.issue9066@psf.upfronthosting.co.za> Message-ID: <1396992076.94.0.709523864564.issue9066@psf.upfronthosting.co.za> Changes by Josh Rosenberg : ---------- nosy: +josh.rosenberg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 23:37:56 2014 From: report at bugs.python.org (Eric Snow) Date: Tue, 08 Apr 2014 21:37:56 +0000 Subject: [issue21181] Inconsistent Definition of collections.namedtuple.__dict__ in _source In-Reply-To: <1396974950.77.0.151698168246.issue21181@psf.upfronthosting.co.za> Message-ID: <1396993076.43.0.875485011537.issue21181@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 8 23:45:34 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 08 Apr 2014 21:45:34 +0000 Subject: [issue21181] Inconsistent Definition of collections.namedtuple.__dict__ in _source In-Reply-To: <1396974950.77.0.151698168246.issue21181@psf.upfronthosting.co.za> Message-ID: <1396993534.83.0.803373722402.issue21181@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 00:20:41 2014 From: report at bugs.python.org (Kushal Das) Date: Tue, 08 Apr 2014 22:20:41 +0000 Subject: [issue21169] getpass.getpass() fails with non-ASCII characters in prompt In-Reply-To: <1396869835.69.0.462900859226.issue21169@psf.upfronthosting.co.za> Message-ID: <1396995641.77.0.760683236031.issue21169@psf.upfronthosting.co.za> Kushal Das added the comment: Here is a patch which stops the breakage in getpass for python3. ---------- keywords: +patch nosy: +kushaldas Added file: http://bugs.python.org/file34766/issue21169.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 00:46:53 2014 From: report at bugs.python.org (Kushal Das) Date: Tue, 08 Apr 2014 22:46:53 +0000 Subject: [issue21169] getpass.getpass() fails with non-ASCII characters in prompt In-Reply-To: <1396869835.69.0.462900859226.issue21169@psf.upfronthosting.co.za> Message-ID: <1396997213.43.0.204865463139.issue21169@psf.upfronthosting.co.za> Kushal Das added the comment: Version 2 of the patch with a test update. ---------- Added file: http://bugs.python.org/file34767/issue21169_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 01:42:13 2014 From: report at bugs.python.org (Yakov Keselman) Date: Tue, 08 Apr 2014 23:42:13 +0000 Subject: [issue21182] json.loads errors out on valid JSON Message-ID: <1397000533.56.0.918232006199.issue21182@psf.upfronthosting.co.za> New submission from Yakov Keselman: Run the following Python JSON parsing script on valid JSON: import json json.loads( '["[\"Residential | Furniture | Cabinets\",\"119.99\"]"]' ) Result: Traceback (most recent call last): File "", line 1, in File "C:\Python33\lib\json\__init__.py", line 319, in loads return _default_decoder.decode(s) File "C:\Python33\lib\json\decoder.py", line 352, in decode obj, end = self.raw_decode(s, idx=_w(s, 0).end()) File "C:\Python33\lib\json\decoder.py", line 368, in raw_decode obj, end = self.scan_once(s, idx) ValueError: Expecting ',' delimiter: line 1 column 5 (char 4) ---------- components: IO messages: 215780 nosy: Yakov.Keselman priority: normal severity: normal status: open title: json.loads errors out on valid JSON versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 02:07:26 2014 From: report at bugs.python.org (Vinay Sajip) Date: Wed, 09 Apr 2014 00:07:26 +0000 Subject: [issue21172] Unexpected behaviour with logging.LogRecord "first arg is dict" case In-Reply-To: <1396890277.61.0.522199976389.issue21172@psf.upfronthosting.co.za> Message-ID: <1397002046.15.0.8906324441.issue21172@psf.upfronthosting.co.za> Vinay Sajip added the comment: Thanks for pinpointing what the issue is. > checking for isinstance(..., dict) is still wrong - it should at least > be collections.Mapping to give users a chance to emulate the correct > interface. That seems reasonable. ---------- resolution: invalid -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 02:16:13 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 09 Apr 2014 00:16:13 +0000 Subject: [issue21166] Bus error on "AMD64 FreeBSD 9.x 3.4" buildbot In-Reply-To: <1396863177.29.0.753462829204.issue21166@psf.upfronthosting.co.za> Message-ID: <1397002573.39.0.411769378578.issue21166@psf.upfronthosting.co.za> STINNER Victor added the comment: I still don't understand the issue but... it's now fixed (I don't understand why), so I'm closing it. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 02:17:26 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 09 Apr 2014 00:17:26 +0000 Subject: [issue21168] unicodeobject.c: likely type-punning may break strict-aliasing rules In-Reply-To: <1396868964.72.0.411392590222.issue21168@psf.upfronthosting.co.za> Message-ID: <1397002646.59.0.142088335568.issue21168@psf.upfronthosting.co.za> STINNER Victor added the comment: This issue was a follow up of issue #21166, but in fact the two issues are unrelated, and this issue is a false alarm. I don't see how to make the GCC warning quiet, and GCC 4.2 is now old, so I'm closing the issue. ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 02:17:44 2014 From: report at bugs.python.org (David Beazley) Date: Wed, 09 Apr 2014 00:17:44 +0000 Subject: [issue5845] rlcompleter should be enabled automatically In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za> Message-ID: <1397002664.73.0.967344092041.issue5845@psf.upfronthosting.co.za> David Beazley added the comment: Funny thing, this feature breaks the interactive interpreter in the most basic way on OS X systems. For example, the tab key won't even work to indent. You can't even type the most basic programs into the interactive interpreter. For example: >>> for i in range(10): ... print(i) Oh sure, you can make it work by typing the space bar a bunch of times, but it's extremely annoying. The only way I was able to get a working interactive interpreter on my machine was to manually edit site.py and remove the call to enablerlcompleter() from main(). I hope someone reconsiders this feature and removes it as default behavior. ---------- nosy: +dabeaz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 02:23:49 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 09 Apr 2014 00:23:49 +0000 Subject: [issue21147] sqlite3 doesn't complain if the request contains a null character In-Reply-To: <1396544845.43.0.82545828662.issue21147@psf.upfronthosting.co.za> Message-ID: <1397003029.53.0.592649572993.issue21147@psf.upfronthosting.co.za> STINNER Victor added the comment: Here is a first patch. I only tested the execute() method. ---------- keywords: +patch nosy: +ghaering Added file: http://bugs.python.org/file34768/sqlite_null.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 02:28:33 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 09 Apr 2014 00:28:33 +0000 Subject: [issue19977] Use "surrogateescape" error handler for sys.stdin and sys.stdout on UNIX for the C locale In-Reply-To: <1386952820.2.0.77364136667.issue19977@psf.upfronthosting.co.za> Message-ID: <1397003313.38.0.592789194153.issue19977@psf.upfronthosting.co.za> STINNER Victor added the comment: "However, I'd still like to discuss the idea of backporting this to 3.4.1." THe idea of doing this change in Python 3.5 is that I have no idea of the risk of regression. To backport such change in a minor version (3.4.1), I would feel more confident with user tests of Python 3.5 or patched Python 3.4. "That has long made Toshio nervous about the migration of core services to Python 3 (https://fedoraproject.org/wiki/Changes/Python_3_as_Default), and his concerns make sense to me, as that migration covers little things like the installer, package manager, post-image install initialisation, etc. " Which programs in this test are or may be running with the POSIX locale? Fedora doesn't use en_US.utf8 locale by default? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 02:48:15 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 09 Apr 2014 00:48:15 +0000 Subject: [issue20644] OS X installer build broken by changes to documentation build In-Reply-To: <1392590601.44.0.499989411789.issue20644@psf.upfronthosting.co.za> Message-ID: <3g3Rg15RPGz7Ljk@mail.python.org> Roundup Robot added the comment: New changeset 01f1e14cad23 by Ned Deily in branch '3.4': Issue #20644: OS X installer build support for documentation build changes http://hg.python.org/cpython/rev/01f1e14cad23 New changeset 7d004ad09bf5 by Ned Deily in branch 'default': Issue #20644: merge from 3.4 http://hg.python.org/cpython/rev/7d004ad09bf5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 02:55:22 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 09 Apr 2014 00:55:22 +0000 Subject: [issue21181] Inconsistent Definition of collections.namedtuple.__dict__ in _source In-Reply-To: <1396974950.77.0.151698168246.issue21181@psf.upfronthosting.co.za> Message-ID: <1397004922.05.0.60843731715.issue21181@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > whatever compelled the developer to declare the named fields > using _property seems to be ignored in the definition of __dict__. What compelled the _property alias is that the user could name an attribute "property" which would cause a conflict if _property has not been renamed. For example: T = namedtuple('T', ['property', 'plant', 'equipment']) would create the following field definitions: property = _property(_itemgetter(0), doc='Alias for field number 0') plant = _property(_itemgetter(1), doc='Alias for field number 1') equipment = _property(_itemgetter(2), doc='Alias for field number 2') Note, if we didn't use _property, the builtin property() would be shadowed. The code for __dict__ occurs upstream (before the field definitions), so it is safe from redefinition: @property def __dict__(self): 'A new OrderedDict mapping field names to their values' return OrderedDict(zip(self._fields, self)) ---------- resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 03:02:09 2014 From: report at bugs.python.org (Ned Deily) Date: Wed, 09 Apr 2014 01:02:09 +0000 Subject: [issue20644] OS X installer build broken by changes to documentation build In-Reply-To: <1392590601.44.0.499989411789.issue20644@psf.upfronthosting.co.za> Message-ID: <1397005329.8.0.762451282985.issue20644@psf.upfronthosting.co.za> Ned Deily added the comment: build-installer.py now assumes that sphinx-build and the previously required hg have been installed somewhere on the restricted PATH that the installer uses. Behind the scenes, the installer build process has been substantially revised to make use of a bootstrapped Python 2.7 instance on OS X 10.5 and 10.6 for the use of hg and sphinx-build, since the current version of sphinx-build requires at least Python 2.6 thus the 10.5 system Python 2.5 no longer suffices. ---------- priority: deferred blocker -> resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 03:04:55 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 09 Apr 2014 01:04:55 +0000 Subject: [issue21119] asyncio create_connection resource warning In-Reply-To: <1396321484.68.0.174945090803.issue21119@psf.upfronthosting.co.za> Message-ID: <1397005495.86.0.26092854019.issue21119@psf.upfronthosting.co.za> STINNER Victor added the comment: Updated patch (close-3.patch) combining create_connection_close.patch and close2.patch and adding unit tests. I also improved the create_connection() test to raise the TimeoutError on connect() (loop.sock_connect), not on sock.set_blocking(). ---------- Added file: http://bugs.python.org/file34769/close-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 03:15:29 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 09 Apr 2014 01:15:29 +0000 Subject: [issue21088] curses addch() argument position reverses in Python3.4.0 In-Reply-To: <1396036290.82.0.606042459455.issue21088@psf.upfronthosting.co.za> Message-ID: <1397006129.87.0.620388805923.issue21088@psf.upfronthosting.co.za> STINNER Victor added the comment: Here is a patch. I don't see how to write a unit test. ---------- keywords: +patch Added file: http://bugs.python.org/file34770/addch.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 03:16:16 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 09 Apr 2014 01:16:16 +0000 Subject: [issue21088] curses addch() argument position reverses in Python3.4.0 In-Reply-To: <1396036290.82.0.606042459455.issue21088@psf.upfronthosting.co.za> Message-ID: <1397006176.43.0.66828375995.issue21088@psf.upfronthosting.co.za> STINNER Victor added the comment: > Redirecting the test to a file fails because curses complains stdio isn't a tty. You may create a the pty module for that. https://docs.python.org/dev/library/pty.html#pty.openpty ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 03:26:30 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 09 Apr 2014 01:26:30 +0000 Subject: [issue12546] builtin __format__ methods cannot fill with \x00 char In-Reply-To: <1310540286.71.0.346156272109.issue12546@psf.upfronthosting.co.za> Message-ID: <1397006790.47.0.788698415432.issue12546@psf.upfronthosting.co.za> STINNER Victor added the comment: The patch looks good to me. ---------- type: behavior -> enhancement versions: -Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 03:50:03 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Wed, 09 Apr 2014 01:50:03 +0000 Subject: [issue21179] Rounding half to even In-Reply-To: <1396954738.37.0.54879370291.issue21179@psf.upfronthosting.co.za> Message-ID: <1397008203.44.0.574883847655.issue21179@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Python 3.2-3.4 (probably all of 3.x) use round half even, but testing 2.7.3 on Ubuntu confirms what you say. In terms of the decimal constants, Py2.7 round() appears to use decimal.ROUND_HALF_UP behavior while 3.x uses decimal.ROUND_HALF_EVEN behavior. Looks like someone accidentally copied Py3 docs down to Py2; according to https://docs.python.org/3/whatsnew/3.0.html : >The round() function rounding strategy and return type have changed. Exact halfway cases are now rounded to the nearest even result instead of away from zero. (For example, round(2.5) now returns 2 rather than 3.) round(x[, n]) now delegates to x.__round__([n]) instead of always returning a float. It generally returns an integer when called with a single argument and a value of the same type as x when called with two arguments. Looks like the behaviors never changed, but the docs for round in Py2 are incorrect. ---------- nosy: +josh.rosenberg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 03:57:35 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 09 Apr 2014 01:57:35 +0000 Subject: [issue21097] Move test_namespace_pkgs into test_importlib. In-Reply-To: <1396128084.92.0.614609718769.issue21097@psf.upfronthosting.co.za> Message-ID: <3g3TC31Kmqz7LjN@mail.python.org> Roundup Robot added the comment: New changeset 99265d30fa38 by Ned Deily in branch '3.4': Issue #21097: Update Makefile with changed install locations of test directories. http://hg.python.org/cpython/rev/99265d30fa38 New changeset 7aae2b9fcfad by Ned Deily in branch 'default': Issue #21097: merge from 3.4 http://hg.python.org/cpython/rev/7aae2b9fcfad ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 04:13:51 2014 From: report at bugs.python.org (Osvaldo Santana Neto) Date: Wed, 09 Apr 2014 02:13:51 +0000 Subject: [issue21183] Doctest capture only AssertionError but not printed text Message-ID: <1397009631.06.0.545133190838.issue21183@psf.upfronthosting.co.za> New submission from Osvaldo Santana Neto: The following doctest should pass, but it fails: >>> def spam(): print("eggs") ... >>> assert spam() eggs Traceback (most recent call last): AssertionError But if we remove the print output from printed results the test pass: >>> def spam(): print("eggs") ... >>> assert spam() Traceback (most recent call last): AssertionError I'm writing the 2nd edition of a book about Python (covering python3) and Django and I'm using doctest to run the interactive sessions that I use as examples in book. ---------- components: Library (Lib) files: doctest_bug.py messages: 215796 nosy: osantana priority: normal severity: normal status: open title: Doctest capture only AssertionError but not printed text type: behavior versions: Python 2.7, Python 3.4 Added file: http://bugs.python.org/file34771/doctest_bug.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 04:26:03 2014 From: report at bugs.python.org (Tim Peters) Date: Wed, 09 Apr 2014 02:26:03 +0000 Subject: [issue21183] Doctest capture only AssertionError but not printed text In-Reply-To: <1397009631.06.0.545133190838.issue21183@psf.upfronthosting.co.za> Message-ID: <1397010363.55.0.620840559021.issue21183@psf.upfronthosting.co.za> Tim Peters added the comment: The first footnote in the docs explain this: Examples containing both expected output and an exception are not supported. Trying to guess where one ends and the other begins is too error-prone, and that also makes for a confusing test. So, sorry, but this is intentionally not supported. ---------- nosy: +tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 04:31:23 2014 From: report at bugs.python.org (Osvaldo Santana Neto) Date: Wed, 09 Apr 2014 02:31:23 +0000 Subject: [issue21183] Doctest capture only AssertionError but not printed text In-Reply-To: <1397009631.06.0.545133190838.issue21183@psf.upfronthosting.co.za> Message-ID: <1397010683.59.0.649500337155.issue21183@psf.upfronthosting.co.za> Osvaldo Santana Neto added the comment: Hi Tim, I tried to find more information in documentation before opening this bug but I need to confess that I didn't read the footnote. Thanks and sorry for the invalid report. ---------- resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 04:41:12 2014 From: report at bugs.python.org (Steven D'Aprano) Date: Wed, 09 Apr 2014 02:41:12 +0000 Subject: [issue21183] Doctest capture only AssertionError but not printed text In-Reply-To: <1397009631.06.0.545133190838.issue21183@psf.upfronthosting.co.za> Message-ID: <1397011272.07.0.965783327212.issue21183@psf.upfronthosting.co.za> Steven D'Aprano added the comment: Personally, I think that the second reason given in the footnote, that it makes for confusing tests, is bogus, or at least it's a matter of opinion. I for one don't think they are confusing, and would like to see mixed output/tracebacks supported. Tim, would you accept this being reopened as an Enhancement request for 3.5 rather than a bug fix? ---------- nosy: +stevenjd _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 04:51:49 2014 From: report at bugs.python.org (Tim Peters) Date: Wed, 09 Apr 2014 02:51:49 +0000 Subject: [issue21183] Doctest capture only AssertionError but not printed text In-Reply-To: <1397009631.06.0.545133190838.issue21183@psf.upfronthosting.co.za> Message-ID: <1397011909.06.0.659080418563.issue21183@psf.upfronthosting.co.za> Tim Peters added the comment: Steven, no objection here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 05:08:03 2014 From: report at bugs.python.org (Kushal Das) Date: Wed, 09 Apr 2014 03:08:03 +0000 Subject: [issue21170] Incorrect signature for unittest.TestResult.startTestRun(), .stopTestRun() In-Reply-To: <1396881559.52.0.157201741461.issue21170@psf.upfronthosting.co.za> Message-ID: <1397012883.05.0.292371600901.issue21170@psf.upfronthosting.co.za> Kushal Das added the comment: Here is a patch which fixes the documentation for unittest. ---------- keywords: +patch nosy: +kushaldas Added file: http://bugs.python.org/file34772/issue21170.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 05:14:30 2014 From: report at bugs.python.org (Steven D'Aprano) Date: Wed, 09 Apr 2014 03:14:30 +0000 Subject: [issue21184] statistics.pvariance with known mean does not work as expected Message-ID: <1397013270.92.0.0743559681991.issue21184@psf.upfronthosting.co.za> New submission from Steven D'Aprano: If you know the population mean mu, you should calculate the sample variance by passing mu as an explicit argument to statistics.pvariance. Unfortunately, it doesn't work as designed: py> data = [1, 2, 2, 2, 3, 4] # sample from a population with mu=2.5 py> statistics.pvariance(data) # uses the sample mean 2.3333... 0.8888888888888888 py> statistics.pvariance(data, 2.5) # using known population mean 0.8888888888888888 The second calculation ought to be 0.91666... not 0.88888... The problem lies with the _ss private function which calculates the sum of square deviations. Unfortunately it is too clever: it includes an error adjustment term ss -= _sum((x-c) for x in data)**2/len(data) which mathematically is expected to be zero when c is calculated as the mean of data, but due to rounding may not be quite zero. But when c is given explicitly, as happens if the caller provides an explicit mu argument to pvariance, then the error adjustment has the effect of neutralizing the explicit mu. The obvious fix is to just skip the adjustment in _ss when c is explicitly given, but I'm not sure if that's the best approach. ---------- assignee: stevenjd components: Library (Lib) messages: 215802 nosy: stevenjd priority: normal severity: normal stage: needs patch status: open title: statistics.pvariance with known mean does not work as expected type: behavior versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 05:18:12 2014 From: report at bugs.python.org (Steven D'Aprano) Date: Wed, 09 Apr 2014 03:18:12 +0000 Subject: [issue21183] Doctest capture only AssertionError but not printed text In-Reply-To: <1397009631.06.0.545133190838.issue21183@psf.upfronthosting.co.za> Message-ID: <1397013492.66.0.538292880373.issue21183@psf.upfronthosting.co.za> Changes by Steven D'Aprano : ---------- resolution: invalid -> stage: -> needs patch status: closed -> open type: behavior -> enhancement versions: +Python 3.5 -Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 05:33:11 2014 From: report at bugs.python.org (Kushal Das) Date: Wed, 09 Apr 2014 03:33:11 +0000 Subject: [issue21182] json.loads errors out on valid JSON In-Reply-To: <1397000533.56.0.918232006199.issue21182@psf.upfronthosting.co.za> Message-ID: <1397014391.35.0.27888230206.issue21182@psf.upfronthosting.co.za> Kushal Das added the comment: It is not a valid JSON. You may want to validate it against http://jsonlint.com/ What you have inside the string (single quotes) is the JSON representation but not the string representation which json.loads is supposed to parse. ---------- nosy: +kushaldas _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 07:17:16 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 09 Apr 2014 05:17:16 +0000 Subject: [issue21088] curses addch() argument position reverses in Python3.4.0 In-Reply-To: <1396036290.82.0.606042459455.issue21088@psf.upfronthosting.co.za> Message-ID: <5344d7d8.64873c0a.4d3c.ffffe0c4@mx.google.com> Larry Hastings added the comment: How about examining the inspect.Signature? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 07:19:24 2014 From: report at bugs.python.org (Berker Peksag) Date: Wed, 09 Apr 2014 05:19:24 +0000 Subject: [issue21170] Incorrect signature for unittest.TestResult.startTestRun(), .stopTestRun() In-Reply-To: <1396881559.52.0.157201741461.issue21170@psf.upfronthosting.co.za> Message-ID: <1397020764.56.0.93783567035.issue21170@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +ezio.melotti, michael.foord stage: -> patch review versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 10:06:33 2014 From: report at bugs.python.org (wchlm) Date: Wed, 09 Apr 2014 08:06:33 +0000 Subject: [issue21185] heapq fails to print in sorted order for certain inputs Message-ID: <1397030793.41.0.486579475537.issue21185@psf.upfronthosting.co.za> New submission from wchlm: I observe the following in Python 2.6.1 in CentOS 5.9 and in Python 2.7.5 in MacOS 10.9.2. A heapified 3-element array containing elements in the order [low, high, medium] fails to print in sorted order, as shown below: >>> import heapq >>> lista = [1, 6, 5, 4] >>> heapq.heapify(lista) >>> lista # Gives sorted order, as expected [1, 4, 5, 6] >>> >>> listb = [1, 6, 5] >>> heapq.heapify(listb) >>> listb # Gives unsorted order -- unexpected and presumably a bug [1, 6, 5] >>> >>> [heapq.heappop(listb) for i in range(len(listb))] # But heappop works [1, 5, 6] ---------- components: Devguide messages: 215805 nosy: ezio.melotti, wchlm priority: normal severity: normal status: open title: heapq fails to print in sorted order for certain inputs type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 10:20:42 2014 From: report at bugs.python.org (Wolfgang Maier) Date: Wed, 09 Apr 2014 08:20:42 +0000 Subject: [issue21184] statistics.pvariance with known mean does not work as expected In-Reply-To: <1397013270.92.0.0743559681991.issue21184@psf.upfronthosting.co.za> Message-ID: <1397031642.37.0.525075881124.issue21184@psf.upfronthosting.co.za> Wolfgang Maier added the comment: I do not think this is a bug in the module, but rather incorrect usage. >From your own docs: data should be an iterable of Real-valued numbers, with at least one value. The optional argument mu, if given, should be the mean of the data. If it is missing or None, the mean is automatically calculated. Nowhere does it say that mu should be the known population mean, and rightly so! The definition of p_variance is that it is the variance of the data assuming that data *is* the whole population (so the correct mean can be calculated from it) s_variance on the other hand should give an estimate of the population variance under the assumption that data is a random sample of the population, but its formula _ss/(n-1) is derived under the assumption that mu is the sample mean, not the population mean. So everything's fine and there is nothing to fix really! ---------- nosy: +wolma _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 10:23:11 2014 From: report at bugs.python.org (Saimadhav Heblikar) Date: Wed, 09 Apr 2014 08:23:11 +0000 Subject: [issue21185] heapq fails to print in sorted order for certain inputs In-Reply-To: <1397030793.41.0.486579475537.issue21185@psf.upfronthosting.co.za> Message-ID: <1397031791.6.0.938564664367.issue21185@psf.upfronthosting.co.za> Saimadhav Heblikar added the comment: Hi, I dont think its a bug. The textbook definition of a min(or max) heap is "Heaps are binary trees for which every parent node has a value less than or equal to any of its children." Therefore, when lista = [1,6,5,4], and heapify is run on it,it can be viewed as 1 / \ 4 5 6 or [1,4,5,6] When listb=[1,6,5], running heapify on it,gives 1 / \ 6 5 or [1,6,5] heapify maintains the heap-invariant - Every key is smaller than its children. This invariant is not violated in the above example. The heappop maintains the heap-invariant after popping. The line in your code [heapq.heappop(listb) for i in range(len(listb))] is the heapsort algorithm!. Hopefully, this clears your question. ---------- nosy: +sahutd _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 10:34:59 2014 From: report at bugs.python.org (wchlm) Date: Wed, 09 Apr 2014 08:34:59 +0000 Subject: [issue21185] heapq fails to print in sorted order for certain inputs In-Reply-To: <1397030793.41.0.486579475537.issue21185@psf.upfronthosting.co.za> Message-ID: <1397032499.66.0.498666780949.issue21185@psf.upfronthosting.co.za> wchlm added the comment: Hi sahutd, You may be right. I was keying off a stackoverflow example (http://stackoverflow.com/questions/12373837/heapq-module-python) that might have been misleading. In fact, the Python documentation never does say what a printed heapified array is suppose to look like -- how it unwinds the tree structure into a linear list. But from the above example I assumed it was supposed to print the sorted order, and again my assumption is quite possibly wrong. It might be useful, as a documentation issue, to say what a printed heapified array is supposed to look like. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 10:53:03 2014 From: report at bugs.python.org (Adam Groszer) Date: Wed, 09 Apr 2014 08:53:03 +0000 Subject: [issue21186] RawConfigParser __name__ option handling inconsistent Message-ID: <1397033583.06.0.34789258522.issue21186@psf.upfronthosting.co.za> New submission from Adam Groszer: In RawConfigParser the "__name__" option handling is inconsistent: RawConfigParser.options() and items() works hard to hide it, but has_options() does not ---------- components: Library (Lib) messages: 215809 nosy: Adam.Groszer priority: normal severity: normal status: open title: RawConfigParser __name__ option handling inconsistent versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 11:21:19 2014 From: report at bugs.python.org (=?utf-8?q?Herv=C3=A9_Coatanhay?=) Date: Wed, 09 Apr 2014 09:21:19 +0000 Subject: [issue21187] 2.7 build-installer.py with OS X 10.9 Message-ID: <1397035277.67.0.354917057695.issue21187@psf.upfronthosting.co.za> New submission from Herv? Coatanhay: With XCode 5.1 some changes were made to clang, making it impossible to build Mac OS X installer. Shipped SQLite and Sleepycat DB pass CFLAGS and LDFLAGS to compiler in their compiler check in configure script. In particular -syslibroot option is a linker option not a compiler option, and since XCode 5.1 unused command line options are considered as errors. I manage to work around this problem with the following extra CFLAGS: -Wno-error=unused-command-line-argument-hard-error-in-future I joined my modified version of build-installer.py ---------- assignee: ronaldoussoren components: Macintosh files: build-installer.py messages: 215810 nosy: Alzakath, ronaldoussoren priority: normal severity: normal status: open title: 2.7 build-installer.py with OS X 10.9 versions: Python 2.7 Added file: http://bugs.python.org/file34773/build-installer.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 11:27:50 2014 From: report at bugs.python.org (=?utf-8?q?Herv=C3=A9_Coatanhay?=) Date: Wed, 09 Apr 2014 09:27:50 +0000 Subject: [issue21187] 2.7 build-installer.py with OS X 10.9 In-Reply-To: <1397035277.67.0.354917057695.issue21187@psf.upfronthosting.co.za> Message-ID: <1397035670.84.0.952319180572.issue21187@psf.upfronthosting.co.za> Herv? Coatanhay added the comment: By the way it seems more like an SQLite / Sleepycat issue as LDFLAGS should be passed to linker not compiler. Proposed modifications are just workarounds to allow Mac installer creation on OS X 10.9. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 12:52:05 2014 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 09 Apr 2014 10:52:05 +0000 Subject: [issue19977] Use "surrogateescape" error handler for sys.stdin and sys.stdout on UNIX for the C locale In-Reply-To: <1386952820.2.0.77364136667.issue19977@psf.upfronthosting.co.za> Message-ID: <1397040725.96.0.994063000204.issue19977@psf.upfronthosting.co.za> Nick Coghlan added the comment: The default locale on Fedora is indeed UTF-8 these days - the problem is that *users* are used to being able to use "LANG=C" to force the POSIX locale (whether for testing purposes or other reasons), and that currently means system utilities written in Python may fail in such situations if used with UTF-8 data from the filesystem (or elsewhere). (I believe there may also be other cases where POSIX mandates the use of the C locale, but Toshio would be in a better position than I am to confirm whether or not that is actually the case). So perhaps this is best left in a "wait & see" mode for now - as the Fedora migration to Python 3 progresses, if the folks working on that find specific utilities where the Python 3.4 standard stream handling in the C locale appears problematic, then Slavek & Toshio can bring them up here. The counterargument is that if we're going to change it, 3.4.1 would be a better time frame than 3.4.2. In that case, the task of identifying specific Fedora utilities of concern still falls back on Toshio & Slavek, but it would be a matter of going hunting for them specifically *now*, rather than waiting until they come up over the course of the migration. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 13:04:13 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 09 Apr 2014 11:04:13 +0000 Subject: [issue21179] Rounding half to even In-Reply-To: <1396954738.37.0.54879370291.issue21179@psf.upfronthosting.co.za> Message-ID: <3g3jKm5h4Qz7LjQ@mail.python.org> Roundup Robot added the comment: New changeset 7ec8c4555772 by Mark Dickinson in branch '2.7': Issue #21179: Fix description of 'round' function for numbers.Real. http://hg.python.org/cpython/rev/7ec8c4555772 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 13:05:52 2014 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 09 Apr 2014 11:05:52 +0000 Subject: [issue21179] Rounding half to even In-Reply-To: <1396954738.37.0.54879370291.issue21179@psf.upfronthosting.co.za> Message-ID: <1397041552.6.0.568137756458.issue21179@psf.upfronthosting.co.za> Mark Dickinson added the comment: Yep, 2.7 does round-ties-away-from-zero. There's even special code for that: the underlying machinery does a round-ties-to-even, and then there's a hack on top of that to convert to round-ties-away-from-zero. Looks like this error went unnoticed for quite a while. Now fixed. Thanks for the report! ---------- nosy: +mark.dickinson resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 13:08:44 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 09 Apr 2014 11:08:44 +0000 Subject: [issue19977] Use "surrogateescape" error handler for sys.stdin and sys.stdout on UNIX for the C locale In-Reply-To: <1397040725.96.0.994063000204.issue19977@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > The default locale on Fedora is indeed UTF-8 these days - the problem is that *users* are used to being able to use "LANG=C" to force the POSIX locale (whether for testing purposes or other reasons), and that currently means system utilities written in Python may fail in such situations if used with UTF-8 data from the filesystem (or elsewhere). (I believe there may also be other cases where POSIX mandates the use of the C locale, but Toshio would be in a better position than I am to confirm whether or not that is actually the case). A common situation where you get a C locale is for programs started by a crontab. If I remember correctly, these programs start with the C locale, instead of the "system" (user?) locale. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 14:55:14 2014 From: report at bugs.python.org (Nathaniel Smith) Date: Wed, 09 Apr 2014 12:55:14 +0000 Subject: [issue21176] Implement matrix multiplication operator (PEP 465) In-Reply-To: <1396925495.01.0.281917881542.issue21176@psf.upfronthosting.co.za> Message-ID: <1397048114.3.0.780552426392.issue21176@psf.upfronthosting.co.za> Changes by Nathaniel Smith : ---------- nosy: +njs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 15:29:31 2014 From: report at bugs.python.org (Steven D'Aprano) Date: Wed, 09 Apr 2014 13:29:31 +0000 Subject: [issue21184] statistics.pvariance with known mean does not work as expected In-Reply-To: <1397031642.37.0.525075881124.issue21184@psf.upfronthosting.co.za> Message-ID: <20140409132915.GB11385@ando> Steven D'Aprano added the comment: On Wed, Apr 09, 2014 at 08:20:42AM +0000, Wolfgang Maier wrote: > I do not think this is a bug in the module, but rather incorrect usage. [...] No, it is legitimate usage. See, for example, "Numerical Recipes in Pascal" by Press et al. When you know the population mean independently from the sample you're using, you should not apply Bessel's Correction (that is, you should use a denominator of n rather than n-1, which is equivalent to using the population variance). I don't think it is appropriate to include too much of the complexity about variance in the docs. (They should document the module, not teach all the odd corners of statistics theory.) I've tried to clarify the different uses of (p)variance here: http://import-that.dreamwidth.org/2291.html If you're still not convinced, this usage is equivalent to the gsl_stats_variance_with_fixed_mean function from the GNU Scientific Library: https://www.gnu.org/software/gsl/manual/html_node/Mean-and-standard-deviation-and-variance.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 15:30:26 2014 From: report at bugs.python.org (Adam Groszer) Date: Wed, 09 Apr 2014 13:30:26 +0000 Subject: [issue21186] RawConfigParser __name__ option handling inconsistent In-Reply-To: <1397033583.06.0.34789258522.issue21186@psf.upfronthosting.co.za> Message-ID: <1397050226.62.0.490502216987.issue21186@psf.upfronthosting.co.za> Adam Groszer added the comment: e.g. myconfig.has_options(, "__name__") is always True, whereas myconfig.options() never has a "__name__" entry ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 15:32:56 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 09 Apr 2014 13:32:56 +0000 Subject: [issue21184] statistics.pvariance with known mean does not work as expected In-Reply-To: <1397013270.92.0.0743559681991.issue21184@psf.upfronthosting.co.za> Message-ID: <1397050376.94.0.110863659146.issue21184@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 15:41:35 2014 From: report at bugs.python.org (LtWorf) Date: Wed, 09 Apr 2014 13:41:35 +0000 Subject: [issue21188] Broken link Message-ID: <1397050895.39.0.221241316975.issue21188@psf.upfronthosting.co.za> New submission from LtWorf: gcmodule.c lists a few reference links. http://www.arctrix.com/nas/python/gc/ http://www.python.org/pipermail/python-dev/2000-March/003869.html http://www.python.org/pipermail/python-dev/2000-March/004010.html http://www.python.org/pipermail/python-dev/2000-March/004022.html The last ones do not exist so they aren't very useful. ---------- components: Interpreter Core messages: 215818 nosy: tiposchi priority: normal severity: normal status: open title: Broken link type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 15:42:56 2014 From: report at bugs.python.org (LtWorf) Date: Wed, 09 Apr 2014 13:42:56 +0000 Subject: [issue21189] Broken link to patch Message-ID: <1397050976.2.0.0354182649484.issue21189@psf.upfronthosting.co.za> New submission from LtWorf: This page https://mail.python.org/mailman/listinfo/patches suggests to go here: http://www.python.org/patches/ to know how to send patches. However that page doesn't exist. ---------- assignee: docs at python components: Documentation messages: 215819 nosy: docs at python, tiposchi priority: normal severity: normal status: open title: Broken link to patch type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 16:11:02 2014 From: report at bugs.python.org (Wolfgang Maier) Date: Wed, 09 Apr 2014 14:11:02 +0000 Subject: [issue21184] statistics.pvariance with known mean does not work as expected In-Reply-To: <1397013270.92.0.0743559681991.issue21184@psf.upfronthosting.co.za> Message-ID: <1397052662.01.0.932471996009.issue21184@psf.upfronthosting.co.za> Wolfgang Maier added the comment: ok, there may be use cases for calculating a variance estimate in such situations, but IMHO what you are trying to do is to abuse a function which is not documented to be made for the purpose and then complain that it does not behave correctly. The *documented* use of the mu argument is to avoid redundant calculations of the mean of data! With just one argument, how would you know whether the user wants this documented functionality or the undocumented one ? Your suggestion of just omitting the correction means that every user who wants the documented functionality gets a potentially imprecise result. Another potential approach may be to correct the correction term based on the mean calculated from data, but such a calculation would be absurd given the documented functionality. In case the statistics module is going to use exact representations of internal results in 3.5, the error adjustment would become obsolete anyway (see http://bugs.python.org/issue20499) and pvariance could be abused just as you suggest. In this case, this usage could be sanctioned in the form of a recipe ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 16:48:36 2014 From: report at bugs.python.org (Selena Deckelmann) Date: Wed, 09 Apr 2014 14:48:36 +0000 Subject: [issue21190] Broken download link on README for CPython docs Message-ID: <1397054916.95.0.591389338462.issue21190@psf.upfronthosting.co.za> New submission from Selena Deckelmann: The page: https://github.com/python/cpython/blob/master/Doc/README.txt Links to: http://docs.python.org/download/ Which is now a 404. A URL which may be correct is: https://docs.python.org/3/download.html I'm unsure what the org policy is on linking most recent documentation, however. In the Postgres community, we have a 'current' symlink that always links to the most recent version. ---------- assignee: docs at python components: Documentation messages: 215821 nosy: Selena.Deckelmann, docs at python priority: normal severity: normal status: open title: Broken download link on README for CPython docs type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 16:53:09 2014 From: report at bugs.python.org (Alex Gaynor) Date: Wed, 09 Apr 2014 14:53:09 +0000 Subject: [issue21190] Broken download link on README for CPython docs In-Reply-To: <1397054916.95.0.591389338462.issue21190@psf.upfronthosting.co.za> Message-ID: <1397055189.93.0.879323099945.issue21190@psf.upfronthosting.co.za> Alex Gaynor added the comment: It looks like https://docs.python.org/3/download.html (and I suppose the 2.x variant) are the right URLs to use this. ---------- nosy: +alex _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 17:45:26 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 09 Apr 2014 15:45:26 +0000 Subject: [issue21190] Broken download link on README for CPython docs In-Reply-To: <1397054916.95.0.591389338462.issue21190@psf.upfronthosting.co.za> Message-ID: <3g3qZF4jh0z7LkD@mail.python.org> Roundup Robot added the comment: New changeset aec35c0d308b by Senthil Kumaran in branch '2.7': issue #21190: Fix the docs README link http://hg.python.org/cpython/rev/aec35c0d308b New changeset df8f49f8cdd2 by Senthil Kumaran in branch '3.4': issue #21190: Fix the broken docs download link http://hg.python.org/cpython/rev/df8f49f8cdd2 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 17:46:01 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Wed, 09 Apr 2014 15:46:01 +0000 Subject: [issue21190] Broken download link on README for CPython docs In-Reply-To: <1397054916.95.0.591389338462.issue21190@psf.upfronthosting.co.za> Message-ID: <1397058361.31.0.213437732844.issue21190@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Fixed this all active versions. Thanks for the report. ---------- nosy: +orsenthil resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 18:38:29 2014 From: report at bugs.python.org (Andreas Schwab) Date: Wed, 09 Apr 2014 16:38:29 +0000 Subject: [issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k In-Reply-To: <1394697296.27.0.543058724281.issue20904@psf.upfronthosting.co.za> Message-ID: <1397061509.52.0.227048782494.issue20904@psf.upfronthosting.co.za> Andreas Schwab added the comment: The only problem is that under some conditions involving denormalized numbers the result may lose a bit of precision. But that is mostly irrelevant for this issue, at least it wouldn't make it worse than it is now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 18:40:13 2014 From: report at bugs.python.org (Josiah Carlson) Date: Wed, 09 Apr 2014 16:40:13 +0000 Subject: [issue1191964] asynchronous Subprocess Message-ID: <1397061613.96.0.491763491638.issue1191964@psf.upfronthosting.co.za> Josiah Carlson added the comment: Submitting an updated patch addressing Giampaolo's comments. ---------- Added file: http://bugs.python.org/file34774/subprocess_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 19:10:44 2014 From: report at bugs.python.org (Ned Deily) Date: Wed, 09 Apr 2014 17:10:44 +0000 Subject: [issue21187] 2.7 build-installer.py with OS X 10.9 In-Reply-To: <1397035277.67.0.354917057695.issue21187@psf.upfronthosting.co.za> Message-ID: <1397063444.67.0.787123263714.issue21187@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- assignee: ronaldoussoren -> ned.deily nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 19:23:26 2014 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 09 Apr 2014 17:23:26 +0000 Subject: [issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k In-Reply-To: <1394697296.27.0.543058724281.issue20904@psf.upfronthosting.co.za> Message-ID: <1397064206.32.0.949352031405.issue20904@psf.upfronthosting.co.za> Mark Dickinson added the comment: > under some conditions involving denormalized numbers the result may lose a bit of precision That sounds like a non-issue for this application: the dtoa.c computations are careful to avoid subnormals in intermediate computations. If mirabilos has withdrawn his objection, is there anything blocking applying this for 3.5? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 19:24:16 2014 From: report at bugs.python.org (Kushal Das) Date: Wed, 09 Apr 2014 17:24:16 +0000 Subject: [issue21169] getpass.getpass() fails with non-ASCII characters in prompt In-Reply-To: <1396869835.69.0.462900859226.issue21169@psf.upfronthosting.co.za> Message-ID: <1397064256.21.0.972140164826.issue21169@psf.upfronthosting.co.za> Kushal Das added the comment: Updated patch with discovering of currect locale and corresponding test case. ---------- Added file: http://bugs.python.org/file34775/issue21169_v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 19:26:44 2014 From: report at bugs.python.org (Kushal Das) Date: Wed, 09 Apr 2014 17:26:44 +0000 Subject: [issue21169] getpass.getpass() fails with non-ASCII characters in prompt In-Reply-To: <1396869835.69.0.462900859226.issue21169@psf.upfronthosting.co.za> Message-ID: <1397064404.62.0.800978125203.issue21169@psf.upfronthosting.co.za> Kushal Das added the comment: New patch with actual test case :) ---------- Added file: http://bugs.python.org/file34776/issue21169_v4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 19:55:17 2014 From: report at bugs.python.org (Georg Brandl) Date: Wed, 09 Apr 2014 17:55:17 +0000 Subject: [issue21189] Broken link to patch In-Reply-To: <1397050976.2.0.0354182649484.issue21189@psf.upfronthosting.co.za> Message-ID: <1397066117.65.0.480135488953.issue21189@psf.upfronthosting.co.za> Georg Brandl added the comment: Barry, you "run the list", so please change this to a link to bugs.python.org (and maybe docs.python.org/devguide). ---------- assignee: docs at python -> barry nosy: +barry, georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 20:14:45 2014 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 09 Apr 2014 18:14:45 +0000 Subject: [issue21035] Python's HTTP server implementations hangs after 16.343 requests on MacOSX In-Reply-To: <1395573252.44.0.596727679776.issue21035@psf.upfronthosting.co.za> Message-ID: <1397067285.78.0.901018311437.issue21035@psf.upfronthosting.co.za> Ronald Oussoren added the comment: This could be related to a problem described on this blog: As such this appears to be a platform issue and not a python one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 20:24:55 2014 From: report at bugs.python.org (Dima Tisnek) Date: Wed, 09 Apr 2014 18:24:55 +0000 Subject: [issue21191] os.fdopen() may eat file descriptor and still raise exception Message-ID: <1397067895.73.0.194150876234.issue21191@psf.upfronthosting.co.za> New submission from Dima Tisnek: os.fdopen() should either: * consume file descriptor and return file/io object, or * leave file descriptor alone and raise an exception this invariant is broken in the following test case: fd = os.open("/", os.O_RDONLY) try: obj = os.fdopen(fd, "r") except EnvironmentError: os.close(fd) # cleanup what happens: fd = os.open("/", os.O_RDONLY) --> some fd os.fdopen(fd, "r") --> exception, fd refers to a directory os.close(fd) --> exception, no such fd For reference: 1. invariant is held in Python 3.3. 2. following positive test case works correctly fd = os.open("/etc/passwd", os.O_RDONLY) try: obj = os.fdopen(fd, "r") # success except EnvironmentError: os.close(fd) # not reached 3. following negative test case works correctly fd = os.open("/etc/passwd", os.O_RDONLY) try: obj = os.fdopen(fd, "w") # wrong mode on purpose except EnvironmentError: os.close(fd) # closed ok ---------- components: IO messages: 215832 nosy: Dima.Tisnek priority: normal severity: normal status: open title: os.fdopen() may eat file descriptor and still raise exception type: resource usage versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 20:25:15 2014 From: report at bugs.python.org (Richard Oudkerk) Date: Wed, 09 Apr 2014 18:25:15 +0000 Subject: [issue1191964] asynchronous Subprocess Message-ID: <1397067915.84.0.542488586999.issue1191964@psf.upfronthosting.co.za> Richard Oudkerk added the comment: Can you explain why you write in 512 byte chunks. Writing in one chunk should not cause a deadlock. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 20:37:40 2014 From: report at bugs.python.org (akira) Date: Wed, 09 Apr 2014 18:37:40 +0000 Subject: [issue21182] json.loads errors out on valid JSON In-Reply-To: <1397000533.56.0.918232006199.issue21182@psf.upfronthosting.co.za> Message-ID: <1397068660.95.0.958927716647.issue21182@psf.upfronthosting.co.za> akira added the comment: You need to escape backslashes inside a Python string literal or use raw-string literals: >>> import json >>> json.loads(r'["[\"Residential | Furniture | Cabinets\",\"119.99\"]"]') [u'["Residential | Furniture | Cabinets","119.99"]'] If the backslashes are unintentional then you could remove them: >>> json.loads('[["Residential | Furniture | Cabinets","119.99"]]') [[u'Residential | Furniture | Cabinets', u'119.99']] Note: the result is different ---------- nosy: +akira _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 21:01:06 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 09 Apr 2014 19:01:06 +0000 Subject: [issue21191] os.fdopen() may eat file descriptor and still raise exception In-Reply-To: <1397067895.73.0.194150876234.issue21191@psf.upfronthosting.co.za> Message-ID: <1397070066.94.0.712360766779.issue21191@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I think this is just won't fix. I agree the behavior in 3.x is better, but at least fdopen() is consistent about closing in 2.x, so you could work around it by dupping the fd. ---------- nosy: +benjamin.peterson resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 21:02:15 2014 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 09 Apr 2014 19:02:15 +0000 Subject: [issue20434] Process crashes if not enough memory to import module In-Reply-To: <1390984600.38.0.476358983499.issue20434@psf.upfronthosting.co.za> Message-ID: <1397070135.85.0.319502506409.issue20434@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Looks like the issue has gone after 3.4 Anf it's still present for 2.7. If somebody like to make a patch for 2.7 - you are welcome! ---------- versions: -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 21:22:54 2014 From: report at bugs.python.org (Dima Tisnek) Date: Wed, 09 Apr 2014 19:22:54 +0000 Subject: [issue21191] os.fdopen() may eat file descriptor and still raise exception In-Reply-To: <1397067895.73.0.194150876234.issue21191@psf.upfronthosting.co.za> Message-ID: <1397071374.07.0.660771571536.issue21191@psf.upfronthosting.co.za> Dima Tisnek added the comment: Benjamin, I think you missed the key point: file + matching mode -> fd eaten, object created file + mode mismatch -> fd remains, exception raised dir + matching mode -> fd eaten, exception raised The issue is about resouce (fd) management Thus, how can user code handle the error without either leaking file descriptor or possibly closing someone else's file descriptor? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 21:26:03 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 09 Apr 2014 19:26:03 +0000 Subject: [issue21191] os.fdopen() may eat file descriptor and still raise exception In-Reply-To: <1397067895.73.0.194150876234.issue21191@psf.upfronthosting.co.za> Message-ID: <1397071563.56.0.877096818133.issue21191@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Ah, you're right. I misread the code. ---------- resolution: wont fix -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 21:38:55 2014 From: report at bugs.python.org (Ned Deily) Date: Wed, 09 Apr 2014 19:38:55 +0000 Subject: [issue21182] json.loads errors out on valid JSON In-Reply-To: <1397000533.56.0.918232006199.issue21182@psf.upfronthosting.co.za> Message-ID: <1397072335.19.0.107326842042.issue21182@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- components: +Library (Lib) -IO resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 21:40:36 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 09 Apr 2014 19:40:36 +0000 Subject: [issue21191] os.fdopen() may eat file descriptor and still raise exception In-Reply-To: <1397067895.73.0.194150876234.issue21191@psf.upfronthosting.co.za> Message-ID: <3g3wnb6gxpz7Lkq@mail.python.org> Roundup Robot added the comment: New changeset 4a3b455abf76 by Benjamin Peterson in branch '2.7': make sure fdopen always closes the fd in error cases (closes #21191) http://hg.python.org/cpython/rev/4a3b455abf76 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 21:48:55 2014 From: report at bugs.python.org (Dima Tisnek) Date: Wed, 09 Apr 2014 19:48:55 +0000 Subject: [issue21191] os.fdopen() may eat file descriptor and still raise exception In-Reply-To: <1397067895.73.0.194150876234.issue21191@psf.upfronthosting.co.za> Message-ID: <1397072935.94.0.401044077995.issue21191@psf.upfronthosting.co.za> Dima Tisnek added the comment: I don't like proposed patch -- it changes semantics of more (?) common failure modes. I think it's best to keep semantics in line with Python 3.3 -- if fdopen fails, it leaves file descriptor alone. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 21:52:59 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 09 Apr 2014 19:52:59 +0000 Subject: [issue21191] os.fdopen() may eat file descriptor and still raise exception In-Reply-To: <1397072935.94.0.401044077995.issue21191@psf.upfronthosting.co.za> Message-ID: <1397073173.25760.104701849.41E0AAA3@webmail.messagingengine.com> Benjamin Peterson added the comment: On Wed, Apr 9, 2014, at 12:48, Dima Tisnek wrote: > > Dima Tisnek added the comment: > > I don't like proposed patch -- it changes semantics of more (?) common > failure modes. I don't know if opening the file with the wrong mode is any more wrong than opening a directory. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 22:00:00 2014 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 09 Apr 2014 20:00:00 +0000 Subject: [issue20539] math.factorial may throw OverflowError In-Reply-To: <1391770469.14.0.441115710554.issue20539@psf.upfronthosting.co.za> Message-ID: <1397073600.58.0.33937922743.issue20539@psf.upfronthosting.co.za> Mark Dickinson added the comment: Updated patch. ---------- Added file: http://bugs.python.org/file34777/huge_factorial_input_v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 22:05:37 2014 From: report at bugs.python.org (Maciej Szulik) Date: Wed, 09 Apr 2014 20:05:37 +0000 Subject: [issue1100942] Add datetime.time.strptime and datetime.date.strptime Message-ID: <1397073937.24.0.973793453412.issue1100942@psf.upfronthosting.co.za> Maciej Szulik added the comment: Sorry it took me that long - but I'm finally attaching fixed patch. I've also checked it again current default branch and updated descriptions accordingly. ---------- hgrepos: +232 Added file: http://bugs.python.org/file34778/issue1100942_20140409.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 22:08:36 2014 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 09 Apr 2014 20:08:36 +0000 Subject: [issue20539] math.factorial may throw OverflowError In-Reply-To: <1391770469.14.0.441115710554.issue20539@psf.upfronthosting.co.za> Message-ID: <1397074115.99.0.498385852692.issue20539@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- assignee: -> mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 22:18:38 2014 From: report at bugs.python.org (Dima Tisnek) Date: Wed, 09 Apr 2014 20:18:38 +0000 Subject: [issue21191] os.fdopen() may eat file descriptor and still raise exception In-Reply-To: <1397067895.73.0.194150876234.issue21191@psf.upfronthosting.co.za> Message-ID: <1397074718.24.0.712341747464.issue21191@psf.upfronthosting.co.za> Dima Tisnek added the comment: Good point. Personally I think it's more pythonic to consume fd only on success. I accept that's just an opinion. In any case, let's keep error semantics in py2.7 and py3.3 same. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 22:33:23 2014 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Wed, 09 Apr 2014 20:33:23 +0000 Subject: [issue20434] Process crashes if not enough memory to import module In-Reply-To: <1390984600.38.0.476358983499.issue20434@psf.upfronthosting.co.za> Message-ID: <1397075603.02.0.461354093249.issue20434@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Here we are. There were a lot of places where this was being incorrectly done. And some places where this was being considered a recoverable error, which it isn't because the source is freed. Which sort of supports my opinion that this is bad general api design, but perhaps a good conveneice function for limited use. ---------- Added file: http://bugs.python.org/file34779/string_resize.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 23:24:46 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 09 Apr 2014 21:24:46 +0000 Subject: [issue21192] Idle: Print filename when running a file from editor Message-ID: <1397078686.2.0.0309283772804.issue21192@psf.upfronthosting.co.za> New submission from Terry J. Reedy: Upon restarting the user process, Idle prints a separator bar in the shell: ====================================== RESTART=====================.... When restart is due to running a file with F5, print "RUN filename" instead of "RESTART". Idea from Adnan Umer, pydev list. For Shell / Restart Shell Cntl+F6, maybe change to "RESTART Shell" (my additional idea). ---------- messages: 215846 nosy: terry.reedy priority: normal severity: normal stage: needs patch status: open title: Idle: Print filename when running a file from editor type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 23:26:13 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Wed, 09 Apr 2014 21:26:13 +0000 Subject: [issue20539] math.factorial may throw OverflowError In-Reply-To: <1391770469.14.0.441115710554.issue20539@psf.upfronthosting.co.za> Message-ID: <1397078773.69.0.876869188125.issue20539@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Mark, you said: > OverflowError seems to have the majority vote. I'll change it to that. But your most recent patch seems to have gone back to ValueError for both cases. Is there a reason for that? FWIW, I favor OverflowError as the "too large" type, though I prefer the less hyperbolic phrasing of the error message in the new patch. ---------- nosy: +josh.rosenberg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 23:33:42 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Wed, 09 Apr 2014 21:33:42 +0000 Subject: [issue21185] heapq fails to print in sorted order for certain inputs In-Reply-To: <1397030793.41.0.486579475537.issue21185@psf.upfronthosting.co.za> Message-ID: <1397079222.99.0.665884830367.issue21185@psf.upfronthosting.co.za> Josh Rosenberg added the comment: It's not really relevant what a heapified list looks like (and there is no reason to guarantee a particular appearance, since it's an implementation detail that could change). It's supposed to function as a heap with the heap functions, that's all. The docs do give a guarantee that a sorted list is already "heapified", but that's a one way guarantee: All sorted lists are heaps, but not all heaps are sorted lists. The docs also mention the big-O behavior of heapify; it's linear time, O(n), while good general purpose sorting algorithms are O(n log n). A linear algorithm cannot sort a general list. ---------- nosy: +josh.rosenberg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 23:35:37 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Wed, 09 Apr 2014 21:35:37 +0000 Subject: [issue21185] heapq fails to print in sorted order for certain inputs In-Reply-To: <1397030793.41.0.486579475537.issue21185@psf.upfronthosting.co.za> Message-ID: <1397079337.81.0.901993900504.issue21185@psf.upfronthosting.co.za> Josh Rosenberg added the comment: By the way, in the top answer to the Stack Overflow post you linked, it's clear that the list wasn't sorted. [44, 42, 3, 89, 10] became [3, 10, 44, 89, 42], and you'll notice, the last three elements are out of order. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 23:36:33 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 09 Apr 2014 21:36:33 +0000 Subject: [issue11838] IDLE: make interactive code savable as a runnable script In-Reply-To: <1302631389.12.0.305553029462.issue11838@psf.upfronthosting.co.za> Message-ID: <1397079393.14.0.978602820208.issue11838@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- type: -> enhancement versions: +Python 2.7, Python 3.4, Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 23:39:55 2014 From: report at bugs.python.org (wchlm) Date: Wed, 09 Apr 2014 21:39:55 +0000 Subject: [issue21185] heapq fails to print in sorted order for certain inputs In-Reply-To: <1397030793.41.0.486579475537.issue21185@psf.upfronthosting.co.za> Message-ID: <1397079595.08.0.90723025227.issue21185@psf.upfronthosting.co.za> wchlm added the comment: All fair enough. I see the error of my ways. I am closing the case with a Resolution of "invalid." Thanks.... ---------- resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 9 23:50:02 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 09 Apr 2014 21:50:02 +0000 Subject: [issue21191] os.fdopen() may eat file descriptor and still raise exception In-Reply-To: <1397074718.24.0.712341747464.issue21191@psf.upfronthosting.co.za> Message-ID: <1397080197.10032.104743305.239108BB@webmail.messagingengine.com> Benjamin Peterson added the comment: On Wed, Apr 9, 2014, at 13:18, Dima Tisnek wrote: > > Dima Tisnek added the comment: > > Good point. > > Personally I think it's more pythonic to consume fd only on success. I > accept that's just an opinion. > > In any case, let's keep error semantics in py2.7 and py3.3 same. Unfortunately, it's not easy to implement with the 2.7 implementation of the file type. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 00:11:06 2014 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 09 Apr 2014 22:11:06 +0000 Subject: [issue20539] math.factorial may throw OverflowError In-Reply-To: <1391770469.14.0.441115710554.issue20539@psf.upfronthosting.co.za> Message-ID: <1397081466.91.0.459967160971.issue20539@psf.upfronthosting.co.za> Mark Dickinson added the comment: Josh: well spotted; thanks for picking up on this. I was wondering whether anyone would pick up on that, and I should have mentioned the change explicitly. I do think ValueError is the correct exception here. My interpretation of OverflowError is that it represents an overflow occurring during the computation, and that's not what's happening here: we're flat-out rejecting an input value because it's out of the range of values we accept. Stefan's message influenced me a bit in that direction, too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 00:49:07 2014 From: report at bugs.python.org (Aaron Meurer) Date: Wed, 09 Apr 2014 22:49:07 +0000 Subject: [issue20010] time.strftime('%z') didn't make +HHMM return in windows xp In-Reply-To: <1387319931.23.0.412917689607.issue20010@psf.upfronthosting.co.za> Message-ID: <1397083747.18.0.477084164188.issue20010@psf.upfronthosting.co.za> Aaron Meurer added the comment: The docs could be much more clear about this in my opinion. ---------- nosy: +Aaron.Meurer _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 01:23:56 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 09 Apr 2014 23:23:56 +0000 Subject: [issue20644] OS X installer build broken by changes to documentation build In-Reply-To: <1392590601.44.0.499989411789.issue20644@psf.upfronthosting.co.za> Message-ID: <3g41lH1VfKz7LjQ@mail.python.org> Roundup Robot added the comment: New changeset 88572ccb8ebe by Ned Deily in branch '2.7': Issue #20644: Keep build-installer.py in sync across active versions. http://hg.python.org/cpython/rev/88572ccb8ebe New changeset e0722b5b9412 by Ned Deily in branch '3.4': Issue #20644: Keep build-installer.py in sync across active versions. http://hg.python.org/cpython/rev/e0722b5b9412 New changeset 63bd9474be49 by Ned Deily in branch 'default': Issue #20644: merge with 3.4 http://hg.python.org/cpython/rev/63bd9474be49 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 01:23:56 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 09 Apr 2014 23:23:56 +0000 Subject: [issue21187] 2.7 build-installer.py with OS X 10.9 In-Reply-To: <1397035277.67.0.354917057695.issue21187@psf.upfronthosting.co.za> Message-ID: <3g41lH6vvxz7LjQ@mail.python.org> Roundup Robot added the comment: New changeset 63a55ed6622b by Ned Deily in branch '2.7': Issue #21187: Fix OS X installer fail-to-build with Xcode 5.1. http://hg.python.org/cpython/rev/63a55ed6622b New changeset a3299de5fc93 by Ned Deily in branch '3.4': Issue #21187: Fix OS X installer fail-to-build with Xcode 5.1. http://hg.python.org/cpython/rev/a3299de5fc93 New changeset b402e5e06f85 by Ned Deily in branch 'default': Issue #21187: merge with 3.4 http://hg.python.org/cpython/rev/b402e5e06f85 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 01:29:57 2014 From: report at bugs.python.org (Ned Deily) Date: Wed, 09 Apr 2014 23:29:57 +0000 Subject: [issue21187] build-installer.py fails using Xcode 5.1 on OS X 10.9 In-Reply-To: <1397035277.67.0.354917057695.issue21187@psf.upfronthosting.co.za> Message-ID: <1397086197.05.0.80344502124.issue21187@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks for the report. It should work OK now. ---------- components: +Build resolution: -> fixed stage: -> committed/rejected status: open -> closed title: 2.7 build-installer.py with OS X 10.9 -> build-installer.py fails using Xcode 5.1 on OS X 10.9 versions: +Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 01:56:18 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Wed, 09 Apr 2014 23:56:18 +0000 Subject: [issue20539] math.factorial may throw OverflowError In-Reply-To: <1391770469.14.0.441115710554.issue20539@psf.upfronthosting.co.za> Message-ID: <1397087778.18.0.671199308204.issue20539@psf.upfronthosting.co.za> Josh Rosenberg added the comment: I just think it's a little odd to make math.factorial uniquely sensitive to the documented definition of OverflowError. Basically every one of the non-masking PyLong_As interfaces uses OverflowError for too large values. In fact, all the functions which are converting to unsigned C types and aren't doing so for "program logic reasons" (e.g. the shift functions don't accept a negative shift due to semantic obscurity, and long_to_bytes doesn't accept a negative length for the output) use OverflowError when a negative value is passed as well. The PyArg_ParseTuple* functions raise OverflowError as well, either implicitly (when they call a PyLong_As function), or explicitly for those functions that impose more restrictive ranges than the PyLong function they wrap. Long story short: The majority of C extension functions that convert to C level types are raising OverflowError to mean "out of range for implementation's chosen C type" (whether too large, too small, or negative when only unsigned values excepted) as a side-effect of using Python's documented APIs. Making math.factorial the exception would be violating the reasonable expectation one might get from using similar functions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 02:12:07 2014 From: report at bugs.python.org (paul j3) Date: Thu, 10 Apr 2014 00:12:07 +0000 Subject: [issue21150] Add quick links table to argparse docs In-Reply-To: <1396558035.28.0.485991636726.issue21150@psf.upfronthosting.co.za> Message-ID: <1397088727.57.0.268077051074.issue21150@psf.upfronthosting.co.za> paul j3 added the comment: While 'argparse' is complex, its organization is quite different from 'itertools'. For most purposes there is one starting point: parser = argparse.ArgumentParser(...) Nearly everything else invokes a 'parser' method. Most complex and common is 'add_argument'. Some summary tables might be useful, but 'itertools' might not be best model. ---------- nosy: +paul.j3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 02:19:35 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 10 Apr 2014 00:19:35 +0000 Subject: [issue21191] os.fdopen() may eat file descriptor and still raise exception In-Reply-To: <1397067895.73.0.194150876234.issue21191@psf.upfronthosting.co.za> Message-ID: <1397089175.95.0.537073003013.issue21191@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I should note the C level fdopen has the the 2.x semantics. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 02:24:57 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Thu, 10 Apr 2014 00:24:57 +0000 Subject: [issue21193] pow(a, b, c) should not raise TypeError when b is negative and c is provided Message-ID: <1397089497.66.0.725830795875.issue21193@psf.upfronthosting.co.za> New submission from Josh Rosenberg: While checking the exceptions used to compare existing behavior while investigating #20539, I noticed a weird behavior in pow() (implemented by long_pow in longobject.c). If a 3rd argument (the modulus) is provided, and the 2nd argument (the exponent) is negative, the function raises TypeError. To my knowledge, TypeError should never be used for this purpose; some functions raise OverflowError for negative values (which violates the documented purpose of OverflowError, but the documents don't match CPython's implementation), others use ValueError (which I believe is appropriate, since it's not a matter of a C type limitation, the function is just logically restricted to the range [0,Largest possible PyLong]. I recommend switching to ValueError, possibly with a deprecation notice before making the switch if people think someone might rely on this behavior. Related: #457066 ---------- components: Interpreter Core messages: 215860 nosy: josh.rosenberg priority: normal severity: normal status: open title: pow(a, b, c) should not raise TypeError when b is negative and c is provided type: behavior versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 03:06:35 2014 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 10 Apr 2014 01:06:35 +0000 Subject: [issue20539] math.factorial may throw OverflowError In-Reply-To: <1391770469.14.0.441115710554.issue20539@psf.upfronthosting.co.za> Message-ID: <1397091995.12.0.956030928758.issue20539@psf.upfronthosting.co.za> Mark Dickinson added the comment: > Making math.factorial the exception would be violating the reasonable expectation one might get from using similar functions. Can you point to some examples of those similar functions? I can't think of any obvious examples offhand. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 05:28:49 2014 From: report at bugs.python.org (Ned Deily) Date: Thu, 10 Apr 2014 03:28:49 +0000 Subject: [issue21193] pow(a, b, c) should not raise TypeError when b is negative and c is provided In-Reply-To: <1397089497.66.0.725830795875.issue21193@psf.upfronthosting.co.za> Message-ID: <1397100529.29.0.950597577058.issue21193@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +mark.dickinson versions: -Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 05:38:49 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Thu, 10 Apr 2014 03:38:49 +0000 Subject: [issue20539] math.factorial may throw OverflowError In-Reply-To: <1391770469.14.0.441115710554.issue20539@psf.upfronthosting.co.za> Message-ID: <1397101129.67.0.540930114212.issue20539@psf.upfronthosting.co.za> Josh Rosenberg added the comment: A few examples (some are patently ridiculous, since the range of values anyone would use ends long before you'd overflow a 32 bit integer, let alone a 64 bit value on my build of Python, but bear with me: >>> datetime.datetime(2**64, 1, 2) Traceback (most recent call last): File "", line 1, in OverflowError: Python int too large to convert to C long >>> datetime.datetime(-2**64, 1, 2) Traceback (most recent call last): File "", line 1, in OverflowError: Python int too large to convert to C long >>> time.mktime(time.struct_time([2**64]*9)) Traceback (most recent call last): File "", line 1, in OverflowError: Python int too large to convert to C long >>> sqlite3.enable_callback_tracebacks(2**64) Traceback (most recent call last): File "", line 1, in OverflowError: Python int too large to convert to C long (That last one should really be changed to type code 'p' over 'i', or to 'B' since it's just a boolean, so overflow doesn't matter, just truthy/falsy behavior) It also happens if you pass re functions/methods a too large flags value: >>> re.sub(r'(abc)', r'\1', 'abcd', re.IGNORECASE << 64) Traceback (most recent call last): File "", line 1, in File "/home/shadowranger/src/cpython/Lib/re.py", line 175, in sub return _compile(pattern, flags).sub(repl, string, count) OverflowError: Python int too large to convert to C ssize_t Skipping the tracebacks, a few more examples of functions where at least one argument can raise OverflowError for implementation specific reasons, rather than a logical overflow of some kind (which is what math.factorial's is): os.getpriority, os.setpriority, os.waitid, os.tcsetpgrp, a central utility function (get_data) in zipimport (I believe the value it's parsing is derived from a zip header, so it may not be possible to feed it too-large values; haven't checked), quite a number of socket functions (often for stuff that should really be ValueErrors, e.g. port numbers out of range), and more random things. I found all of these with a simple: find cpython/ -type f -name '*.c' -exec grep -nP 'PyArg_Parse.*?"\w*?[bhilL]"' {} + > exampleoverflow.txt There aren't any other good examples in math, largely because the other functions there deal with floats (or have arbitrary precision integer fallback paths, in the case of the log suite of functions). That find only scratches the surface; many PyArg_Parse* calls are split across lines (so my simple regex won't catch them), and old Python code has a habit of not using PyArg_Parse* even when it makes sense (presumably because they wanted to customize error messages, or didn't like the way the provided formatting codes handled edge cases). In reality, any place PyLong_As* is called (when * is not one of the masking functions) on an argument that came from the user without explicitly checking for an replacing OverflowError will potentially trigger this issue. A cursory search of locations where this function is called reveals OverflowErrors in the r parameter to to itertools.permutations, and that decimal is riddled with cases where they return if PyLong_As* has an error (including OverflowError) without changing the exception type, then a second round of range checking will set ValueError if it didn't Overflow. Examples include Context object's prec and clamp properties, but there are a dozen or more functions doing this, and I don't know if all of them are publically accessible. Fewer of the calls will be publically visible, so there's more to look through, but you can run the same search to find tons of places with potentially similar behavior: find cpython/ -type f -name '*.c' -exec grep -nP 'Py(Long|Number)_As(?!.*(?:Mask|NULL|PyExc_(?!Overflow)))' {} + > exampleoverflowdirectcall.txt I suspect that for every case where Python standard libs behave this way (raising OverflowErrors in ways that disregard the official docs description of when it should be used), there are a dozen where a third party module behaves this way, since third party modules are more likely to use the standardized argument parsing and numeric parsing APIs without rejiggering the default exceptions, assuming that the common APIs raise the "correct" errors. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 05:53:14 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 10 Apr 2014 03:53:14 +0000 Subject: [issue21176] Implement matrix multiplication operator (PEP 465) In-Reply-To: <1396925495.01.0.281917881542.issue21176@psf.upfronthosting.co.za> Message-ID: <1397101994.1.0.211783271697.issue21176@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I think this patch is fairly straightforward, and I don't want it to rot, so here we go... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 05:55:14 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Thu, 10 Apr 2014 03:55:14 +0000 Subject: [issue21193] pow(a, b, c) should not raise TypeError when b is negative and c is provided In-Reply-To: <1397089497.66.0.725830795875.issue21193@psf.upfronthosting.co.za> Message-ID: <1397102114.97.0.121393381203.issue21193@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Here's the trivial patch for code and the associated unit test (we were actually testing that it raised TypeError specifically; it now raises ValueError, and the unit test expects ValueError). unit tests passed aside from test_io, but I'm pretty sure that's unrelated; my Linux VM freezes up once in a while, which does nasty things to timing dependent I/O tests. ---------- keywords: +patch Added file: http://bugs.python.org/file34780/pow_typeerror_to_valueerror.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 05:56:05 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 10 Apr 2014 03:56:05 +0000 Subject: [issue21176] Implement matrix multiplication operator (PEP 465) In-Reply-To: <1396925495.01.0.281917881542.issue21176@psf.upfronthosting.co.za> Message-ID: <3g47nJ6h3kz7LkX@mail.python.org> Roundup Robot added the comment: New changeset c553d8f72d65 by Benjamin Peterson in branch 'default': PEP 465: a dedicated infix operator for matrix multiplication (closes #21176) http://hg.python.org/cpython/rev/c553d8f72d65 ---------- nosy: +python-dev resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 05:57:34 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Thu, 10 Apr 2014 03:57:34 +0000 Subject: [issue21193] pow(a, b, c) should not raise TypeError when b is negative and c is provided In-Reply-To: <1397089497.66.0.725830795875.issue21193@psf.upfronthosting.co.za> Message-ID: <1397102254.17.0.737183119733.issue21193@psf.upfronthosting.co.za> Josh Rosenberg added the comment: As I mentioned on another bug, I filled out and submitted the contributor agreement form electronically earlier this week, it just hasn't propagated yet. I'm fairly sure trained monkeys reading the description of this bug report would produce the exact same patch (s/TypeError/ValueError/ on one line in each of two files) though, so I'll trust you if you say you reimplemented it rather than take the legal risk. :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 06:56:34 2014 From: report at bugs.python.org (Adnan Umer) Date: Thu, 10 Apr 2014 04:56:34 +0000 Subject: [issue21192] Idle: Print filename when running a file from editor In-Reply-To: <1397078686.2.0.0309283772804.issue21192@psf.upfronthosting.co.za> Message-ID: <1397105794.57.0.727040190318.issue21192@psf.upfronthosting.co.za> Changes by Adnan Umer : ---------- components: +IDLE _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 08:14:15 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 10 Apr 2014 06:14:15 +0000 Subject: [issue21172] Unexpected behaviour with logging.LogRecord "first arg is dict" case In-Reply-To: <1396890277.61.0.522199976389.issue21172@psf.upfronthosting.co.za> Message-ID: <3g4Brk3f7Sz7LjQ@mail.python.org> Roundup Robot added the comment: New changeset d08e3586dde3 by Vinay Sajip in branch '2.7': Issue #21172: isinstance check relaxed from dict to collections.Mapping. http://hg.python.org/cpython/rev/d08e3586dde3 New changeset 5e303360db14 by Vinay Sajip in branch '3.4': Issue #21172: isinstance check relaxed from dict to collections.Mapping. http://hg.python.org/cpython/rev/5e303360db14 New changeset 8e6b8cfeb172 by Vinay Sajip in branch 'default': Closes #21172: Merged fix from 3.4. http://hg.python.org/cpython/rev/8e6b8cfeb172 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 09:39:55 2014 From: report at bugs.python.org (Maciej Szulik) Date: Thu, 10 Apr 2014 07:39:55 +0000 Subject: [issue1100942] Add datetime.time.strptime and datetime.date.strptime Message-ID: <1397115595.3.0.776309934259.issue1100942@psf.upfronthosting.co.za> Changes by Maciej Szulik : ---------- hgrepos: -232 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 11:31:10 2014 From: report at bugs.python.org (Weeble) Date: Thu, 10 Apr 2014 09:31:10 +0000 Subject: [issue21194] json.dumps with ensure_ascii=False doesn't escape control characters Message-ID: <1397122270.44.0.660092890474.issue21194@psf.upfronthosting.co.za> New submission from Weeble: The JSON spec (http://www.json.org/) does not allow unescaped control characters. (See the railroad diagram for strings and the grammar on the right.) If json.dumps is called with ensure_ascii=False, it fails to escape control codes in the range U+007F to U+009F. Here's an example: >>> import json >>> import unicodedata >>> for i in range(256): ... jsonstring = json.dumps(chr(i), ensure_ascii=False) ... if any(unicodedata.category(ch) == 'Cc' for ch in jsonstring): ... print("Fail:",repr(chr(i))) Fail: '\x7f' Fail: '\x80' Fail: '\x81' Fail: '\x82' Fail: '\x83' Fail: '\x84' Fail: '\x85' Fail: '\x86' Fail: '\x87' Fail: '\x88' Fail: '\x89' Fail: '\x8a' Fail: '\x8b' Fail: '\x8c' Fail: '\x8d' Fail: '\x8e' Fail: '\x8f' Fail: '\x90' Fail: '\x91' Fail: '\x92' Fail: '\x93' Fail: '\x94' Fail: '\x95' Fail: '\x96' Fail: '\x97' Fail: '\x98' Fail: '\x99' Fail: '\x9a' Fail: '\x9b' Fail: '\x9c' Fail: '\x9d' Fail: '\x9e' Fail: '\x9f' ---------- components: Library (Lib) messages: 215868 nosy: weeble priority: normal severity: normal status: open title: json.dumps with ensure_ascii=False doesn't escape control characters type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 12:46:28 2014 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 10 Apr 2014 10:46:28 +0000 Subject: [issue21194] json.dumps with ensure_ascii=False doesn't escape control characters In-Reply-To: <1397122270.44.0.660092890474.issue21194@psf.upfronthosting.co.za> Message-ID: <1397126788.26.0.646971341046.issue21194@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti, pitrou, rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 12:58:39 2014 From: report at bugs.python.org (Stefan Krah) Date: Thu, 10 Apr 2014 10:58:39 +0000 Subject: [issue20539] math.factorial may throw OverflowError In-Reply-To: <1397101129.67.0.540930114212.issue20539@psf.upfronthosting.co.za> Message-ID: <20140410105838.GA25384@sleipnir.bytereef.org> Stefan Krah added the comment: OverflowError during initialization dates back to the early days of Python: http://hg.python.org/cpython/rev/0437738279a8 Integer arithmetic actually did raise OverflowError back then: >>> 2222222222222 * 22222222222222 Traceback (most recent call last): File "", line 1, in ? OverflowError: integer multiplication >>> This of course no longer happens, so the whole idea of OverflowError seems slightly outdated. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 13:12:47 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 10 Apr 2014 11:12:47 +0000 Subject: [issue11838] IDLE: make interactive code savable as a runnable script In-Reply-To: <1302631389.12.0.305553029462.issue11838@psf.upfronthosting.co.za> Message-ID: <1397128367.42.0.418320960359.issue11838@psf.upfronthosting.co.za> Terry J. Reedy added the comment: #21140 is about saving Output Window (renamed) as .txt instead of .py. Same method should be used to save shell log as .txt. My idea is that File menu for shell window should, if possible, have both Save as log Save as runnable code ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 14:19:35 2014 From: report at bugs.python.org (Eric O. LEBIGOT) Date: Thu, 10 Apr 2014 12:19:35 +0000 Subject: [issue21195] None float format: incomplete documentation Message-ID: <1397132375.36.0.349385981395.issue21195@psf.upfronthosting.co.za> New submission from Eric O. LEBIGOT: The documentation for a None (empty) format for floats indicates that it is equivalent to the g format. This does not appear to be correct (http://stackoverflow.com/questions/16525924/precise-definition-of-float-string-formatting). The Python?3.4 documentation (https://docs.python.org/3.4/library/string.html#format-specification-mini-language) seems to be much closer to what Python?2.7 does. It would be useful to have a more correct documentation for the effect of a None format for floats in Python?2.7 (maybe by copying the Python?3.4 documentation if it applies). ---------- assignee: docs at python components: Documentation messages: 215871 nosy: docs at python, lebigot priority: normal severity: normal status: open title: None float format: incomplete documentation type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 14:31:20 2014 From: report at bugs.python.org (Chandan Kumar) Date: Thu, 10 Apr 2014 12:31:20 +0000 Subject: [issue21196] Name mangling example in Python tutorial Message-ID: <1397133080.37.0.870141660622.issue21196@psf.upfronthosting.co.za> New submission from Chandan Kumar: The example used for demonstrating name mangling could be better if two versions of code are shown - one with name mangling and one without. I have modified the original example to incorporate this (see attached). ---------- assignee: docs at python components: Documentation files: name_mangling_works.py messages: 215872 nosy: chandan, docs at python, rhettinger priority: normal severity: normal status: open title: Name mangling example in Python tutorial type: enhancement Added file: http://bugs.python.org/file34781/name_mangling_works.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 14:32:05 2014 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 10 Apr 2014 12:32:05 +0000 Subject: [issue20539] math.factorial may throw OverflowError In-Reply-To: <1391770469.14.0.441115710554.issue20539@psf.upfronthosting.co.za> Message-ID: <1397133125.77.0.221203522984.issue20539@psf.upfronthosting.co.za> Mark Dickinson added the comment: Looks like this harmless-looking issue has opened up a can of worms. > the whole idea of OverflowError seems slightly outdated. Well, not entirely. It's still got a place for overflow of mathematical operations, and I think it's clearly the correct exception in that case (indeed, it's about the only case I can think of where OverflowError is clearly the correct exception). >>> from math import exp >>> exp(5000.0) Traceback (most recent call last): File "", line 1, in OverflowError: math range error I'd treat conversion to float as a special case of this; that is, the following is another case where OverflowError is (IMO) the right thing to use: >>> float(10**1000) Traceback (most recent call last): File "", line 1, in OverflowError: long int too large to convert to float A less clear-cut case: >>> sqrt(10**500) Traceback (most recent call last): File "", line 1, in OverflowError: long int too large to convert to float This one still seems okay to me, even though the sqrt result *is* within the floating-point range. You can read this as two operations: a conversion from the integer input to a float, followed by a floating-point square root operation, and it's the intermediate result that overflows. And a case that's clearly wrong: >>> 53 >> 10**100 # Why not simply return 0? Traceback (most recent call last): File "", line 1, in OverflowError: Python int too large to convert to C ssize_t Another historical oddity is that OverflowError inherits from ArithmeticError (along with FloatingPointError and ZeroDivisionError), which supports its use for arithmetic and mathematical operations that overflow their target type. >>> OverflowError.__mro__ (, , , , ) In the interests of moving this *particular* issue forward, I'll revert to OverflowError for this patch. I still personally think it's the wrong exception, but: (1) It's not more wrong than before: we were already raising OverflowError for large positive values. (2) It achieves the main aim of replacing an obscure error message with a more understandable one (which is what Nick wanted in the first place: msg210454). (3) Given the lack of clarity about which exception types are appropriate where, I think we shouldn't be changing exception types unless/until there's a clear vision of where we want to end up. Getting that clear vision may require a python-dev discussion. We can still make the change from OverflowError to ValueError at some later point once it's clear that that's the right thing to do. But converting from OverflowError to ValueError now, and then deciding later that that was wrong and converting back to OverflowError would be a horrible thing to do. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 14:32:27 2014 From: report at bugs.python.org (Chandan Kumar) Date: Thu, 10 Apr 2014 12:32:27 +0000 Subject: [issue21196] Name mangling example in Python tutorial In-Reply-To: <1397133080.37.0.870141660622.issue21196@psf.upfronthosting.co.za> Message-ID: <1397133147.94.0.18142895908.issue21196@psf.upfronthosting.co.za> Chandan Kumar added the comment: Adding the second code sample, since only one attachment allowed at one go. ---------- Added file: http://bugs.python.org/file34782/without_name_mangling.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 14:37:10 2014 From: report at bugs.python.org (Chandan Kumar) Date: Thu, 10 Apr 2014 12:37:10 +0000 Subject: [issue21196] Name mangling example in Python tutorial In-Reply-To: <1397133080.37.0.870141660622.issue21196@psf.upfronthosting.co.za> Message-ID: <1397133430.68.0.524083831829.issue21196@psf.upfronthosting.co.za> Chandan Kumar added the comment: Here is a link to the documentation section in question: https://docs.python.org/2/tutorial/classes.html#private-variables-and-class-local-references ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 15:01:46 2014 From: report at bugs.python.org (=?utf-8?q?Jurko_Gospodneti=C4=87?=) Date: Thu, 10 Apr 2014 13:01:46 +0000 Subject: [issue21161] list comprehensions don't see local variables in pdb in python3 In-Reply-To: <1396698943.39.0.489151150852.issue21161@psf.upfronthosting.co.za> Message-ID: <1397134906.51.0.360740804271.issue21161@psf.upfronthosting.co.za> Jurko Gospodneti? added the comment: Just ran into this problem and it's sooooo uncomfortable researching dynamic structures at run-time using PDB without this. :-( As a workaround, you can use a trick similar to this one to 'import' your locals into the list comprehension body: [l['r'](x) for l in (locals(),) for x in l['some_local']] assuming 'r' & 'some_local' are two local variables in your surrounding scope. Ugly, but at least it can be made/forced to work if needed... Best regards, Jurko Gospodneti? ---------- nosy: +Jurko.Gospodneti? versions: +Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 15:08:56 2014 From: report at bugs.python.org (Stefan Krah) Date: Thu, 10 Apr 2014 13:08:56 +0000 Subject: [issue20539] math.factorial may throw OverflowError In-Reply-To: <1397133125.77.0.221203522984.issue20539@psf.upfronthosting.co.za> Message-ID: <20140410130856.GA24363@sleipnir.bytereef.org> Stefan Krah added the comment: Mark Dickinson wrote: > > the whole idea of OverflowError seems slightly outdated. > > Well, not entirely. It's still got a place for overflow of mathematical operations, and I think it's clearly the correct exception in that case (indeed, it's about the only case I can think of where OverflowError is clearly the correct exception). Indeed, I was focusing on integer arithmetic and assignments. For float operations and conversions OverflowError is quite natural. > (3) Given the lack of clarity about which exception types are appropriate where, I think we shouldn't be changing exception types unless/until there's a clear vision of where we want to end up. Getting that clear vision may require a python-dev discussion. Using OverflowError for now sounds like a good plan. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 15:18:48 2014 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 10 Apr 2014 13:18:48 +0000 Subject: [issue21195] None float format: incomplete documentation In-Reply-To: <1397132375.36.0.349385981395.issue21195@psf.upfronthosting.co.za> Message-ID: <1397135928.65.0.475423333041.issue21195@psf.upfronthosting.co.za> Eric V. Smith added the comment: An empty format specifier can (and to my knowledge, does) match str(). So you get: >>> format(1e10, '') '10000000000.0' >>> format(1e10, 'g') '1e+10' >>> str(1e10) '10000000000.0' The SO question is asking about an empty "presentation type", which is indeed similar to 'g' for floats. I think this is all the same in 2.7 and 3.4, with the exception of how str() might operate on floats. ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 15:29:52 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 10 Apr 2014 13:29:52 +0000 Subject: [issue20539] math.factorial may throw OverflowError In-Reply-To: <1391770469.14.0.441115710554.issue20539@psf.upfronthosting.co.za> Message-ID: <3g4NWN1Tyyz7LjP@mail.python.org> Roundup Robot added the comment: New changeset 273e17260d25 by Mark Dickinson in branch 'default': Issue #20539: Improve math.factorial error messages and types for large inputs. http://hg.python.org/cpython/rev/273e17260d25 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 15:30:26 2014 From: report at bugs.python.org (Eric O. LEBIGOT) Date: Thu, 10 Apr 2014 13:30:26 +0000 Subject: [issue21195] None float format: incomplete documentation In-Reply-To: <1397132375.36.0.349385981395.issue21195@psf.upfronthosting.co.za> Message-ID: <1397136626.22.0.131322963183.issue21195@psf.upfronthosting.co.za> Eric O. LEBIGOT added the comment: These examples are good. I am confused, though, about "The SO question is asking about an empty "presentation type", which is indeed similar to 'g' for floats.": the question is actually about why the '' format gives a result that differs from the 'g' format despite the Python?2.7 documentation saying that a "None" format type is "The same as 'g'.". Both the SO question and your examples show that the Python?2.7 documentation is incorrect, unless the other commenters and I were missing something? Clarifying the documentation would in any case be useful, as the comments to the SO question show? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 15:35:31 2014 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 10 Apr 2014 13:35:31 +0000 Subject: [issue20539] math.factorial may throw OverflowError In-Reply-To: <1391770469.14.0.441115710554.issue20539@psf.upfronthosting.co.za> Message-ID: <1397136931.01.0.885732474357.issue20539@psf.upfronthosting.co.za> Mark Dickinson added the comment: Patch applied to the default branch (but with OverflowError instead of ValueError for large positive inputs). I don't see a lot of benefit in applying the fix to the maintenance branches. Closing this issue. ---------- resolution: -> fixed status: open -> closed versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 15:49:29 2014 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 10 Apr 2014 13:49:29 +0000 Subject: [issue21193] pow(a, b, c) should not raise TypeError when b is negative and c is provided In-Reply-To: <1397089497.66.0.725830795875.issue21193@psf.upfronthosting.co.za> Message-ID: <1397137769.09.0.734022054294.issue21193@psf.upfronthosting.co.za> Mark Dickinson added the comment: I was wondering how the TypeError got there in the first place. Diving into the history is instructive: changeset cdfdd5359411 modified the exception message: taniyama:cpython mdickinson$ hg log -r19719 changeset: 19719:cdfdd5359411 branch: legacy-trunk user: Tim Peters date: Wed Sep 05 06:24:58 2001 +0000 summary: Make the error msgs in our pow() implementations consistent. Before that change, the code looked like this: if (x != Py_None) { PyErr_SetString(PyExc_TypeError, "integer pow() arg " "3 must not be specified when arg 2 is < 0"); return NULL; } >From that point of view the TypeError makes more sense: it's complaining about the wrong number of arguments rather than the negative value. The current message changes the perspective, and I agree that ValueError makes more sense. Tim: any objections to changing the exception type from TypeError to ValueError for Python 3.5? I'd prefer not to change it for 2.7 or 3.4: there's an (admittedly probably quite low) risk of code breakage, and little real gain to offset that breakage. ---------- nosy: +tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 15:50:20 2014 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 10 Apr 2014 13:50:20 +0000 Subject: [issue21193] pow(a, b, c) should not raise TypeError when b is negative and c is provided In-Reply-To: <1397089497.66.0.725830795875.issue21193@psf.upfronthosting.co.za> Message-ID: <1397137820.44.0.394186862505.issue21193@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- assignee: -> mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 15:50:32 2014 From: report at bugs.python.org (Matthias Dahl) Date: Thu, 10 Apr 2014 13:50:32 +0000 Subject: [issue21197] venv does not create lib64 directory and appropriate symlinks Message-ID: <1397137832.25.0.881871760177.issue21197@psf.upfronthosting.co.za> New submission from Matthias Dahl: Creating a new venv on a multilib system does not install an appropriate link from lib to lib64 or the other way around. Currently, venv creates a single lib dir, but everything installed with pip within the venv, will be installed to lib64/... instead while lib will remain empty. For some third party apps, this is confusing. virtualenv, for example, installs a lib64 symlink to lib automatically. IMHO, more correctly would be a lib to lib64 symlink. ---------- components: Library (Lib) messages: 215883 nosy: BinaryKhaos priority: normal severity: normal status: open title: venv does not create lib64 directory and appropriate symlinks versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 16:01:17 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Thu, 10 Apr 2014 14:01:17 +0000 Subject: [issue21193] pow(a, b, c) should not raise TypeError when b is negative and c is provided In-Reply-To: <1397089497.66.0.725830795875.issue21193@psf.upfronthosting.co.za> Message-ID: <1397138477.28.0.319617564246.issue21193@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Agreed that there is no need to patch 2.7/3.4; this is a pedantic correctness fix, not a serious bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 16:13:38 2014 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Thu, 10 Apr 2014 14:13:38 +0000 Subject: [issue20434] Process crashes if not enough memory to import module In-Reply-To: <1390984600.38.0.476358983499.issue20434@psf.upfronthosting.co.za> Message-ID: <1397139218.89.0.361753349267.issue20434@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Could someone please review this patch? I'd like to see it committed asap. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 16:47:17 2014 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 10 Apr 2014 14:47:17 +0000 Subject: [issue21195] None float format: incomplete documentation In-Reply-To: <1397132375.36.0.349385981395.issue21195@psf.upfronthosting.co.za> Message-ID: <1397141237.53.0.693416922917.issue21195@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 16:47:24 2014 From: report at bugs.python.org (Brigitta S) Date: Thu, 10 Apr 2014 14:47:24 +0000 Subject: [issue11975] Fix referencing of built-in types (list, int, ...) In-Reply-To: <1304281262.53.0.265979216697.issue11975@psf.upfronthosting.co.za> Message-ID: <1397141244.98.0.54433368179.issue11975@psf.upfronthosting.co.za> Brigitta S added the comment: I would like to reference the list methods in a documentation using intersphinx-ing e.g ":meth:`list.append`" etc. However there are no links generated for these. I may underestimate issues raised in this thread, but it naively seems that removing the :noindex: lines from datastructures.rst would solve the problem. thanks ---------- nosy: +bsipocz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 17:04:53 2014 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 10 Apr 2014 15:04:53 +0000 Subject: [issue21195] None float format: incomplete documentation In-Reply-To: <1397132375.36.0.349385981395.issue21195@psf.upfronthosting.co.za> Message-ID: <1397142293.74.0.208420838357.issue21195@psf.upfronthosting.co.za> Eric V. Smith added the comment: The rule is: - if the entire format specifier is the empty string (not None, but ''), then return str(value) - else, look at the presentation type. if it is missing, set it to something like 'g' - do the normal float formatting using the presentation type The first of these has an empty string for the format specifier (so uses str(1e10), the rest do not: >>> format(1e10, '') '10000000000.0' >>> format(1e10, ' ') ' 10000000000.0' >>> format(1e10, ' g') ' 1e+10' >>> format(1e10, ' e') ' 1.000000e+10' >>> format(1e10, ' f') ' 10000000000.000000' Now, how much the "something like g" part of the above is true is debatable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 17:13:48 2014 From: report at bugs.python.org (Adnan Umer) Date: Thu, 10 Apr 2014 15:13:48 +0000 Subject: [issue21192] Idle: Print filename when running a file from editor In-Reply-To: <1397078686.2.0.0309283772804.issue21192@psf.upfronthosting.co.za> Message-ID: <1397142828.93.0.757820324691.issue21192@psf.upfronthosting.co.za> Adnan Umer added the comment: Method: runcode Class: ModifiedInterpreter Line: 752 Added if code.co_filename[0] != '<': self.tkconsole.write('Executing ' + code.co_filename + '\n') To print file path that is executed ---------- nosy: +Adnan.Umer versions: +Python 3.4 Added file: http://bugs.python.org/file34783/PyShell.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 17:33:09 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Thu, 10 Apr 2014 15:33:09 +0000 Subject: [issue11975] Fix referencing of built-in types (list, int, ...) In-Reply-To: <1304281262.53.0.265979216697.issue11975@psf.upfronthosting.co.za> Message-ID: <1397143989.17.0.937704131133.issue11975@psf.upfronthosting.co.za> ?ric Araujo added the comment: > I may underestimate issues raised in this thread I re-read the discussion, these are the two main issues: 1) We?d like list/tuple/etc. documented in two different pages (as functions and as types), which causes issues when Sphinx builds its index of referenceable objects, as investigated by Jonas. 2) We?d like to have link targets for list.count/tuple.count/etc. but the existing doc has one place only to document all sequence types? count method, so the fix is not simple. For 1), I now think that Ezio?s builtins.list/list hack could be a good idea, as long as ?list? (i.e. not ?builtins.list?) is always displayed in the text for humans (I don?t care about URIs or rst source), and that people using intersphinx can write ?:meth:`list.append`? and don?t have to go with ?:meth:`builtins.list.append `?. For 2), I would be fine with adding mostly empty method directives to make links work, without duplicating the info in the existing ?common sequence operations? table and footnotes. For example, in https://docs.python.org/3/library/stdtypes.html#tuples after ?Tuples implement all of the :ref:`common ` sequence operations?, I?d add directives for tuple.index and tuple.count. On a related note, it?s unfortunate that the global index has one entry for ?tuple (built-in function)?, seven entries for ?tuple object?, but none for ?tuple.count? (and search doesn?t find it either) or ?tuple class?. ---------- stage: patch review -> needs patch versions: +Python 3.5 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 18:04:37 2014 From: report at bugs.python.org (Eric Snow) Date: Thu, 10 Apr 2014 16:04:37 +0000 Subject: [issue20434] Process crashes if not enough memory to import module In-Reply-To: <1390984600.38.0.476358983499.issue20434@psf.upfronthosting.co.za> Message-ID: <1397145877.94.0.700817896141.issue20434@psf.upfronthosting.co.za> Eric Snow added the comment: I don't see a review link. Looks like your patch wasn't against tip (at attach-time) or you used the --git flag in diff. Having the patch in the review tool would be really would be really helpful. I'll take a look otherwise, but won't be able to immediately regardless. ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 18:35:52 2014 From: report at bugs.python.org (Erik Purins) Date: Thu, 10 Apr 2014 16:35:52 +0000 Subject: [issue7980] time.strptime not thread safe In-Reply-To: <1266835598.13.0.361031999331.issue7980@psf.upfronthosting.co.za> Message-ID: <1397147752.43.0.208245207757.issue7980@psf.upfronthosting.co.za> Changes by Erik Purins : ---------- nosy: +epu _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 18:43:35 2014 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Thu, 10 Apr 2014 16:43:35 +0000 Subject: [issue20434] Process crashes if not enough memory to import module In-Reply-To: <1390984600.38.0.476358983499.issue20434@psf.upfronthosting.co.za> Message-ID: <1397148215.23.0.837601928382.issue20434@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Ok, retrying without the --git flag (I thought that was recommended, it was once...) ---------- Added file: http://bugs.python.org/file34784/string_resize.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 18:43:47 2014 From: report at bugs.python.org (Andrew Scheller) Date: Thu, 10 Apr 2014 16:43:47 +0000 Subject: [issue21198] Minor tarfile documentation bug Message-ID: <1397148227.41.0.631676560193.issue21198@psf.upfronthosting.co.za> New submission from Andrew Scheller: I've just noticed that the documentation for TarInfo.type says "To determine the type of a TarInfo object more conveniently, use the is_*() methods below." However none of the methods mentioned actually contain an underscore, so I believe the documentation should be updated to "...use the is*() methods below." (for comparison, the documentation for stat.S_IFMT correctly talks about "is*() functions") ---------- assignee: docs at python components: Documentation messages: 215892 nosy: docs at python, lurchman priority: normal severity: normal status: open title: Minor tarfile documentation bug type: enhancement versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 18:53:17 2014 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Thu, 10 Apr 2014 16:53:17 +0000 Subject: [issue20434] Process crashes if not enough memory to import module In-Reply-To: <1390984600.38.0.476358983499.issue20434@psf.upfronthosting.co.za> Message-ID: <1397148797.26.0.119041432747.issue20434@psf.upfronthosting.co.za> Changes by Kristj?n Valur J?nsson : Removed file: http://bugs.python.org/file34779/string_resize.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 18:58:53 2014 From: report at bugs.python.org (Matt Mackall) Date: Thu, 10 Apr 2014 16:58:53 +0000 Subject: [issue21199] Python on 64-bit Windows uses signed 32-bit type for read length Message-ID: <1397149133.44.0.946556558932.issue21199@psf.upfronthosting.co.za> New submission from Matt Mackall: Python's file_read uses an 'l' type to parse its args which results in a 31-bit size limit on reads on 64-bit Windows. It should instead use an ssize_t. Related Mercurial bug: http://bz.selenic.com/show_bug.cgi?id=4215 ---------- components: IO messages: 215893 nosy: Matt.Mackall, larry, ncoghlan priority: normal severity: normal status: open title: Python on 64-bit Windows uses signed 32-bit type for read length type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 19:01:25 2014 From: report at bugs.python.org (Berker Peksag) Date: Thu, 10 Apr 2014 17:01:25 +0000 Subject: [issue21198] Minor tarfile documentation bug In-Reply-To: <1397148227.41.0.631676560193.issue21198@psf.upfronthosting.co.za> Message-ID: <1397149285.76.0.335791523662.issue21198@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- type: enhancement -> versions: -Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 19:09:54 2014 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 10 Apr 2014 17:09:54 +0000 Subject: [issue21199] Python on 64-bit Windows uses signed 32-bit type for read length In-Reply-To: <1397149133.44.0.946556558932.issue21199@psf.upfronthosting.co.za> Message-ID: <1397149794.22.0.515701884965.issue21199@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 19:26:35 2014 From: report at bugs.python.org (paul j3) Date: Thu, 10 Apr 2014 17:26:35 +0000 Subject: [issue9253] argparse: optional subparsers In-Reply-To: <1279056589.03.0.566167994161.issue9253@psf.upfronthosting.co.za> Message-ID: <1397150795.1.0.105472024303.issue9253@psf.upfronthosting.co.za> paul j3 added the comment: http://stackoverflow.com/questions/22990977/why-does-this-argparse-code-behave-differently-between-python-2-and-3 is answered by this change in how `required` arguments are tested, and how subparsers fell through the cracks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 19:35:51 2014 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 10 Apr 2014 17:35:51 +0000 Subject: [issue7980] time.strptime not thread safe In-Reply-To: <1266835598.13.0.361031999331.issue7980@psf.upfronthosting.co.za> Message-ID: <1397151351.67.0.939623280456.issue7980@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 19:46:51 2014 From: report at bugs.python.org (Dima Tisnek) Date: Thu, 10 Apr 2014 17:46:51 +0000 Subject: [issue21191] os.fdopen() may eat file descriptor and still raise exception In-Reply-To: <1397067895.73.0.194150876234.issue21191@psf.upfronthosting.co.za> Message-ID: <1397152010.99.0.0751502542298.issue21191@psf.upfronthosting.co.za> Dima Tisnek added the comment: I'm not sure if you are referring to Python's C-level fdopen or GNU libc fdopen. GNU libc fdopen does not consume file descriptor on error: #include #include #include #include #include #include #include int main(int argc, char** argv) { int fd = -1; int rv = 0; FILE* fh = NULL; if (argc<3) return 1; errno = 0; fd = open(argv[1], O_RDONLY); printf("got fd %d errno %d text %s\n", fd, errno, strerror(errno)); errno = 0; fh = fdopen(fd, argv[2]); printf("got fh %x errno %d text %s\n", fh, errno, strerror(errno)); errno = 0; rv = close(fd); printf("got rv %d errno %d text %s\n", rv, errno, strerror(errno)); } [dima at bmg ~]$ ./a.out /etc/passwd w got fd 4 errno 0 text Success got fh 0 errno 22 text Invalid argument got rv 0 errno 0 text Success To be fair, GNU libc fdopen doesn't consider it an error to use a file descriptor that refers to a directory, which is the crux of this bug. Anyhow, point is the semantics change your patch brings in sets Python 2.7+ in contrast with both Python 3.x and GNU libc. Perhaps if it's too hard to implement properly, it's better to leave this issue as won't fix / technical limitation? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 19:57:39 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 10 Apr 2014 17:57:39 +0000 Subject: [issue21199] Python on 64-bit Windows uses signed 32-bit type for read length In-Reply-To: <1397149133.44.0.946556558932.issue21199@psf.upfronthosting.co.za> Message-ID: <1397152659.09.0.998022544589.issue21199@psf.upfronthosting.co.za> Larry Hastings added the comment: Benjamin: given the brave new world of 2.7 living even longer, Guido said this sort of bug fix was fair game. Will you accept a patch for this in 2.7? ---------- assignee: -> larry nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 20:25:12 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Thu, 10 Apr 2014 18:25:12 +0000 Subject: [issue19628] maxlevels -1 on compileall for unlimited recursion In-Reply-To: <1384634450.77.0.212426893492.issue19628@psf.upfronthosting.co.za> Message-ID: <1397154312.89.0.0689257094244.issue19628@psf.upfronthosting.co.za> Claudiu.Popa added the comment: Ping. :) Can someone review this patch, please? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 20:40:58 2014 From: report at bugs.python.org (akira) Date: Thu, 10 Apr 2014 18:40:58 +0000 Subject: [issue21194] json.dumps with ensure_ascii=False doesn't escape control characters In-Reply-To: <1397122270.44.0.660092890474.issue21194@psf.upfronthosting.co.za> Message-ID: <1397155258.31.0.659773107222.issue21194@psf.upfronthosting.co.za> akira added the comment: json.dumps works correctly in this case. Both json/application rfc [1] and ecma json standard [2] say: > All characters may be placed within the quotation marks, except for the characters that must be escaped: quotation mark (U+0022), reverse solidus (U+005C), and the control characters (U+0000 through U+001F). i.e., only a subset (00-1F) of control characters must be escaped in json string [1]: https://tools.ietf.org/html/rfc7159#section-7 [2]: http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf ---------- nosy: +akira _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 21:27:12 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 10 Apr 2014 19:27:12 +0000 Subject: [issue21199] Python on 64-bit Windows uses signed 32-bit type for read length In-Reply-To: <1397149133.44.0.946556558932.issue21199@psf.upfronthosting.co.za> Message-ID: <1397158031.99.0.00660204741992.issue21199@psf.upfronthosting.co.za> Antoine Pitrou added the comment: It is much simpler for Mercurial to add a workaround (which they already did, apparently :-)), than to risk introducing regressions by fixing this. AFAIK nobody else complained before. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 21:34:14 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 10 Apr 2014 19:34:14 +0000 Subject: [issue7980] time.strptime not thread safe In-Reply-To: <1266835598.13.0.361031999331.issue7980@psf.upfronthosting.co.za> Message-ID: <1397158454.4.0.394908535882.issue7980@psf.upfronthosting.co.za> Antoine Pitrou added the comment: There are probably reasons why the import is currently done lazily, so I would advise against changing this in 2.7, unless the reasons are investigated and clearly understood. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 21:37:43 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 10 Apr 2014 19:37:43 +0000 Subject: [issue21177] ValueError: byte must be in range(0, 256) In-Reply-To: <1396947250.75.0.807471111064.issue21177@psf.upfronthosting.co.za> Message-ID: <1397158663.23.0.894475256809.issue21177@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Uh, from the context, it's clear that the error is that 256 doesn't fit in the average 8-bits byte. Is there an actual problem here? (if you don't know what a byte is, you probably shouldn't use that form of the bytes() constructor) ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 21:40:11 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 10 Apr 2014 19:40:11 +0000 Subject: [issue21197] venv does not create lib64 directory and appropriate symlinks In-Reply-To: <1397137832.25.0.881871760177.issue21197@psf.upfronthosting.co.za> Message-ID: <1397158811.84.0.0734953417572.issue21197@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Which third party apps are these? AFAIK, venv's directory layout is private - it shouldn't be "interpreted" by other programs (as opposed to the system-level lib/lib64 layout). ---------- nosy: +pitrou, vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 21:42:34 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 10 Apr 2014 19:42:34 +0000 Subject: [issue20924] openssl init 100% CPU utilization In-Reply-To: <1394807354.77.0.238568366714.issue20924@psf.upfronthosting.co.za> Message-ID: <1397158954.12.0.145383083942.issue20924@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thanks. It would be nice if you could investigate why the underlying NT socket is in non-blocking mode (AFAIK, this issue hasn't been reported before). Also, it would be nice if you could check with Python 3 as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 21:44:26 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 10 Apr 2014 19:44:26 +0000 Subject: [issue21193] pow(a, b, c) should not raise TypeError when b is negative and c is provided In-Reply-To: <1397089497.66.0.725830795875.issue21193@psf.upfronthosting.co.za> Message-ID: <1397159066.15.0.987855772495.issue21193@psf.upfronthosting.co.za> Antoine Pitrou added the comment: +1 for ValueError as well. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 21:46:41 2014 From: report at bugs.python.org (Stefan Krah) Date: Thu, 10 Apr 2014 19:46:41 +0000 Subject: [issue21177] ValueError: byte must be in range(0, 256) In-Reply-To: <1397158663.23.0.894475256809.issue21177@psf.upfronthosting.co.za> Message-ID: <20140410194640.GA27574@sleipnir.bytereef.org> Stefan Krah added the comment: There's no real problem. I find "must be in the range [0, 255]" easier to understand, but I also would not make a big effort to change this. As for me, we can close this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 21:47:33 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 10 Apr 2014 19:47:33 +0000 Subject: [issue21177] ValueError: byte must be in range(0, 256) In-Reply-To: <20140410194640.GA27574@sleipnir.bytereef.org> Message-ID: <5346F551.7080900@free.fr> Antoine Pitrou added the comment: > There's no real problem. I find "must be in the range [0, 255]" easier to > understand, but I also would not make a big effort to change this. The problem is that [0, 255] looks very much like a Python list, not a range. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 22:06:59 2014 From: report at bugs.python.org (Geoffrey Spear) Date: Thu, 10 Apr 2014 20:06:59 +0000 Subject: [issue21015] support SSL_CTX_set_ecdh_auto on newer OpenSSLs In-Reply-To: <1395455671.92.0.144736574461.issue21015@psf.upfronthosting.co.za> Message-ID: <1397160419.42.0.548813077279.issue21015@psf.upfronthosting.co.za> Changes by Geoffrey Spear : ---------- nosy: +geoffreyspear _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 22:08:11 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 10 Apr 2014 20:08:11 +0000 Subject: [issue21127] Path objects cannot be constructed from str subclasses In-Reply-To: <1396390108.81.0.285327356985.issue21127@psf.upfronthosting.co.za> Message-ID: <1397160491.87.0.880959018921.issue21127@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I'm curious: what is the use case for str subclasses in Path objects? If this is to be supported, I think I'd rather force-cast to str rather than accept arbitrary subclasses. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 22:19:08 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 10 Apr 2014 20:19:08 +0000 Subject: [issue21015] support SSL_CTX_set_ecdh_auto on newer OpenSSLs In-Reply-To: <1395455671.92.0.144736574461.issue21015@psf.upfronthosting.co.za> Message-ID: <1397161148.95.0.27607772681.issue21015@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > The OpenSSL command advertise itself as 0.9.8y but it doesn't include > any ECDH ciphers. Really? Apple's packaging looks almost criminal here. > FreeBSD 9 is failing as well: It's not necessarily the same issue as on OS X. Stefan, can you post the output of the following commands: * openssl ciphers -v * openssl ciphers -v ECDH * openssl ciphers -v EECDH ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 22:31:13 2014 From: report at bugs.python.org (Stefan Krah) Date: Thu, 10 Apr 2014 20:31:13 +0000 Subject: [issue21015] support SSL_CTX_set_ecdh_auto on newer OpenSSLs In-Reply-To: <1397161148.95.0.27607772681.issue21015@psf.upfronthosting.co.za> Message-ID: <20140410203112.GA27934@sleipnir.bytereef.org> Stefan Krah added the comment: This is for FreeBSD-9 (which, to be fair, has EOL status): [stefan at freebsd-amd64 ~]$ openssl ciphers -v DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1 AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(256) Mac=SHA1 DHE-DSS-CAMELLIA256-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(256) Mac=SHA1 CAMELLIA256-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(256) Mac=SHA1 EDH-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1 EDH-DSS-DES-CBC3-SHA SSLv3 Kx=DH Au=DSS Enc=3DES(168) Mac=SHA1 DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1 DES-CBC3-MD5 SSLv2 Kx=RSA Au=RSA Enc=3DES(168) Mac=MD5 DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1 DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1 AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(128) Mac=SHA1 DHE-DSS-CAMELLIA128-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(128) Mac=SHA1 CAMELLIA128-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(128) Mac=SHA1 RC2-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC2(128) Mac=MD5 RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 RC4-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 EDH-RSA-DES-CBC-SHA SSLv3 Kx=DH Au=RSA Enc=DES(56) Mac=SHA1 EDH-DSS-DES-CBC-SHA SSLv3 Kx=DH Au=DSS Enc=DES(56) Mac=SHA1 DES-CBC-SHA SSLv3 Kx=RSA Au=RSA Enc=DES(56) Mac=SHA1 DES-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=DES(56) Mac=MD5 EXP-EDH-RSA-DES-CBC-SHA SSLv3 Kx=DH(512) Au=RSA Enc=DES(40) Mac=SHA1 export EXP-EDH-DSS-DES-CBC-SHA SSLv3 Kx=DH(512) Au=DSS Enc=DES(40) Mac=SHA1 export EXP-DES-CBC-SHA SSLv3 Kx=RSA(512) Au=RSA Enc=DES(40) Mac=SHA1 export EXP-RC2-CBC-MD5 SSLv3 Kx=RSA(512) Au=RSA Enc=RC2(40) Mac=MD5 export EXP-RC2-CBC-MD5 SSLv2 Kx=RSA(512) Au=RSA Enc=RC2(40) Mac=MD5 export EXP-RC4-MD5 SSLv3 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export EXP-RC4-MD5 SSLv2 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export [stefan at freebsd-amd64 ~]$ openssl ciphers -v ECDH Error in cipher list 34610:error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list:no cipher match:/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/ssl_lib.c:1218: [stefan at freebsd-amd64 ~]$ openssl ciphers -v EECDH Error in cipher list 34611:error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list:no cipher match:/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/ssl_lib.c:1218: ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 10 22:57:41 2014 From: report at bugs.python.org (Tim Peters) Date: Thu, 10 Apr 2014 20:57:41 +0000 Subject: [issue21193] pow(a, b, c) should not raise TypeError when b is negative and c is provided In-Reply-To: <1397089497.66.0.725830795875.issue21193@psf.upfronthosting.co.za> Message-ID: <1397163461.82.0.78953509316.issue21193@psf.upfronthosting.co.za> Tim Peters added the comment: Yup, agreed with all: ValueError makes a lot more sense, but the change shouldn't be backported. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 11 00:35:02 2014 From: report at bugs.python.org (Charles-Axel Dein) Date: Thu, 10 Apr 2014 22:35:02 +0000 Subject: [issue20351] Add doc examples for DictReader and DictWriter In-Reply-To: <1390414077.91.0.281809568509.issue20351@psf.upfronthosting.co.za> Message-ID: <1397169302.41.0.426531252975.issue20351@psf.upfronthosting.co.za> Charles-Axel Dein added the comment: Hey - is there anything else I need to do here? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 11 00:55:33 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 10 Apr 2014 22:55:33 +0000 Subject: [issue21191] os.fdopen() may eat file descriptor and still raise exception In-Reply-To: <1397152010.99.0.0751502542298.issue21191@psf.upfronthosting.co.za> Message-ID: <1397170530.18620.105191245.72C0A391@webmail.messagingengine.com> Benjamin Peterson added the comment: On Thu, Apr 10, 2014, at 10:46, Dima Tisnek wrote: > > Dima Tisnek added the comment: > > I'm not sure if you are referring to Python's C-level fdopen or GNU libc > fdopen. > > GNU libc fdopen does not consume file descriptor on error: > > #include > #include > #include > #include > #include > #include > #include > > > int main(int argc, char** argv) > { > int fd = -1; > int rv = 0; > FILE* fh = NULL; > if (argc<3) return 1; > > errno = 0; > fd = open(argv[1], O_RDONLY); > printf("got fd %d errno %d text %s\n", fd, errno, strerror(errno)); > > errno = 0; > fh = fdopen(fd, argv[2]); > printf("got fh %x errno %d text %s\n", fh, errno, strerror(errno)); > > errno = 0; > rv = close(fd); > printf("got rv %d errno %d text %s\n", rv, errno, strerror(errno)); > } > > [dima at bmg ~]$ ./a.out /etc/passwd w > got fd 4 errno 0 text Success > got fh 0 errno 22 text Invalid argument > got rv 0 errno 0 text Success > > To be fair, GNU libc fdopen doesn't consider it an error to use a file > descriptor that refers to a directory, which is the crux of this bug. I meant once you manage to get fdopen to succeed, the fd has basically been consumed. > > Anyhow, point is the semantics change your patch brings in sets Python > 2.7+ in contrast with both Python 3.x and GNU libc. I realize. > > Perhaps if it's too hard to implement properly, it's better to leave this > issue as won't fix / technical limitation? I mean if you'd prefer for it to just be inconsistent in 2.x... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 11 04:41:29 2014 From: report at bugs.python.org (Eric O. LEBIGOT) Date: Fri, 11 Apr 2014 02:41:29 +0000 Subject: [issue21195] None float format: incomplete documentation In-Reply-To: <1397132375.36.0.349385981395.issue21195@psf.upfronthosting.co.za> Message-ID: <1397184088.99.0.684159332077.issue21195@psf.upfronthosting.co.za> Eric O. LEBIGOT added the comment: The Python 2.7 goes even as far as to say that format(1e10, ' ') should give "the same as" format(1e10, ' g') (not something "similar to g"), which is obviously incorrect. If the Python 3.4 documentation for the empty presentation type of floats were used in the Python?2.7 documentation, it would be closer to the real behavior of Python?2.7, so that would be an improvement. Now, the real question is whether the Python?3.4 documentation applies exactly to Python?2.7, here, or whether improving the Python?2.7 documentation would require a different description. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 11 07:27:15 2014 From: report at bugs.python.org (Konstantin Zemlyak) Date: Fri, 11 Apr 2014 05:27:15 +0000 Subject: [issue21177] ValueError: byte must be in range(0, 256) In-Reply-To: <1396947250.75.0.807471111064.issue21177@psf.upfronthosting.co.za> Message-ID: <1397194035.59.0.676616570489.issue21177@psf.upfronthosting.co.za> Konstantin Zemlyak added the comment: To clarify few things: - Yes, I know that 256 doesn't fit into byte. I was checking how bytes/bytearray are handling overflow. - I know that range() is a half-open interval. Yet this error message still gave me a "wtf" moment because I didn't realize it was talking about python's range() builtin and not about mathematical term. So even though this message is technically 100% correct it still doesn't feel right. May I propose a message "byte must be in range [0-255]" instead? This won't be confused with either python's range() nor [] list notation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 11 08:11:13 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 11 Apr 2014 06:11:13 +0000 Subject: [issue20397] distutils --record option does not validate existence of byte-compiled files In-Reply-To: <1390746014.88.0.900467086198.issue20397@psf.upfronthosting.co.za> Message-ID: <1397196673.68.0.840703121435.issue20397@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo stage: -> needs patch title: distutils --record option does not validate existance of byte-compiled files -> distutils --record option does not validate existence of byte-compiled files versions: +Python 3.4, Python 3.5 -Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 11 08:15:14 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 11 Apr 2014 06:15:14 +0000 Subject: [issue17861] put opcode information in one place In-Reply-To: <1367162089.6.0.986391601417.issue17861@psf.upfronthosting.co.za> Message-ID: <1397196914.48.0.301204991107.issue17861@psf.upfronthosting.co.za> ?ric Araujo added the comment: Patch looks good to me. ---------- nosy: +eric.araujo versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 11 08:17:42 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 11 Apr 2014 06:17:42 +0000 Subject: [issue17826] Setting a side_effect on mock from create_autospec doesn't work In-Reply-To: <1366797608.02.0.0150366437779.issue17826@psf.upfronthosting.co.za> Message-ID: <1397197062.82.0.767651198419.issue17826@psf.upfronthosting.co.za> ?ric Araujo added the comment: Michael, a patch including tests is ready for this issue. ---------- nosy: +eric.araujo stage: patch review -> commit review versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 11 08:21:00 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 11 Apr 2014 06:21:00 +0000 Subject: [issue17660] mock.patch could whitelist builtins to not need create=True In-Reply-To: <1365418089.99.0.0976801798706.issue17660@psf.upfronthosting.co.za> Message-ID: <1397197260.42.0.106244029522.issue17660@psf.upfronthosting.co.za> ?ric Araujo added the comment: Reviewed on Rietveld. ---------- nosy: +eric.araujo stage: needs patch -> patch review versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 11 08:21:09 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 11 Apr 2014 06:21:09 +0000 Subject: [issue21177] ValueError: byte must be in range(0, 256) In-Reply-To: <1397194035.59.0.676616570489.issue21177@psf.upfronthosting.co.za> Message-ID: <534789D1.3080707@free.fr> Antoine Pitrou added the comment: > Yet this error message still gave me a "wtf" moment because I didn't realize it was talking about python's range() builtin and not about mathematical term. So even though this message is technically 100% correct it still doesn't feel right. If that "wtf" moment makes you more familiar with the range() builtin and the fact that it's a full-blown sequence, for example that it allows writing "256 in range(0, 256)", then it's a rather good thing IMO. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 11 10:50:52 2014 From: report at bugs.python.org (Dima Tisnek) Date: Fri, 11 Apr 2014 08:50:52 +0000 Subject: [issue5639] Support TLS SNI extension in ssl module In-Reply-To: <1238567905.09.0.139467917453.issue5639@psf.upfronthosting.co.za> Message-ID: <1397206252.71.0.980704297412.issue5639@psf.upfronthosting.co.za> Dima Tisnek added the comment: Hopefully pep-466 resolves this for 2.x series. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 11 11:00:07 2014 From: report at bugs.python.org (pocek) Date: Fri, 11 Apr 2014 09:00:07 +0000 Subject: [issue18304] ElementTree -- provide a way to ignore namespace in tags and seaches In-Reply-To: <1372218497.28.0.26294900817.issue18304@psf.upfronthosting.co.za> Message-ID: <1397206807.47.0.296825113796.issue18304@psf.upfronthosting.co.za> Changes by pocek : ---------- nosy: +pocek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 11 11:12:11 2014 From: report at bugs.python.org (Matthias Dahl) Date: Fri, 11 Apr 2014 09:12:11 +0000 Subject: [issue21197] venv does not create lib64 directory and appropriate symlinks In-Reply-To: <1397137832.25.0.881871760177.issue21197@psf.upfronthosting.co.za> Message-ID: <1397207531.35.0.550229403486.issue21197@psf.upfronthosting.co.za> Matthias Dahl added the comment: Take for example the case that you have to juggle with several venvs and mix them together. This has happened to me in the past in very legitimate cases. You have to add those venvs to the path yourself. I am not talking about having a shell where you do your work but some other automated tasks. Or jedi (http://jedi.jedidjah.ch/) which has become a popular autocompletion third party tool that supports venvs. You pass it the base directories and it adds their site-packages to the appropriate places. Naturally it has to know if those are under lib or lib64. Just to name two examples. I guess there are more tools out there which have to juggle with venvs and would stumble upon this inconsistency in comparison with virtualenv. Both are naturally fixable on the user side here but since virtualenv provided those symlinks since quite a while and since IMHO venv should stay as compatible with it as possible, it would be nice if venv provided those too. Besides all of that, creating a "lib"-dir during the venv creation while for all later installations via pip "lib64" is used (which wasn't created initially), sounds like a bug all in itself. ;-) If you want, I could have a look and come up with a patch, if you would be willing to consider this "feature" (adding a lib64 to lib symlink). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 11 11:40:20 2014 From: report at bugs.python.org (Dima Tisnek) Date: Fri, 11 Apr 2014 09:40:20 +0000 Subject: [issue21191] os.fdopen() may eat file descriptor and still raise exception In-Reply-To: <1397067895.73.0.194150876234.issue21191@psf.upfronthosting.co.za> Message-ID: <1397209220.11.0.00351625682393.issue21191@psf.upfronthosting.co.za> Dima Tisnek added the comment: I think consistency between Python versions is just as important as consistency between fd types. Here's my hack quickfix outline: fd = os.open(...) try: if not stat.S_ISREG(os.fstat(fd).st_mode): raise OSError(None, "Not a regular file", ...) f = os.fdopen(fd, ...) except EnvironmentError: os.close(fd) Can something like this be implemented in os.py There's already a check `if not isinstance(fd, int): raise ...` Granted we'd have to get fd type check exactly right. fdopen should probably succeed for regular files, pipes, char devices, block device, ptry's ... fdopen should fail where underlying implementation fails, i.e. directories, sockets(?), epoll(?), timerfd(?) There's a list at http://en.wikipedia.org/wiki/File_descriptor I'm not sure about some types. P.S. I wish there was a way to rescue fd from FILE*, but nothing like that seems to exist... P.P.S. another option is to always use dup(), but that may break existing programs is they expect fd == fdopen(fd).fileno() ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 11 12:08:35 2014 From: report at bugs.python.org (Vinay Sajip) Date: Fri, 11 Apr 2014 10:08:35 +0000 Subject: [issue21197] venv does not create lib64 directory and appropriate symlinks In-Reply-To: <1397137832.25.0.881871760177.issue21197@psf.upfronthosting.co.za> Message-ID: <1397210915.58.0.952182933016.issue21197@psf.upfronthosting.co.za> Vinay Sajip added the comment: What does pip do under Windows? The symlink feature doesn't work on all Windows versions and is not quite the same as on POSIX. What is it that actually requires lib64? As venvs are specific to a single interpreter, it seems like it is inherently not a good idea to add site-package links to venvs in other venvs willy-nilly, though of course it would work in homogeneous scenarios. Do we know *why* virtualenv added a lib64 symlink? What (apart from possibly pip) fails if it doesn't do this? Does distutils require it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 11 12:18:06 2014 From: report at bugs.python.org (Weeble) Date: Fri, 11 Apr 2014 10:18:06 +0000 Subject: [issue21194] json.dumps with ensure_ascii=False doesn't escape control characters In-Reply-To: <1397122270.44.0.660092890474.issue21194@psf.upfronthosting.co.za> Message-ID: <1397211486.5.0.962053358664.issue21194@psf.upfronthosting.co.za> Weeble added the comment: Ah, sorry for the confusion. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 11 15:15:57 2014 From: report at bugs.python.org (Matthias Dahl) Date: Fri, 11 Apr 2014 13:15:57 +0000 Subject: [issue21197] venv does not create lib64 directory and appropriate symlinks In-Reply-To: <1397137832.25.0.881871760177.issue21197@psf.upfronthosting.co.za> Message-ID: <1397222157.5.0.0994845445885.issue21197@psf.upfronthosting.co.za> Matthias Dahl added the comment: The problem is: Some Linux dists install Python under /usr/lib64 on a multilib systems and patch Python accordingly, e.g. Gentoo or Fedora. Thus, Python looks for lib64/pythonX.Y/... which is also why pip installs to lib64/... by default on those systems. This has no effect on Windows systems btw. virtualenv introduced the symlink sometime 2007, if I researched that correctly (https://github.com/pypa/virtualenv/commit/244b23b5e89b58a4c2777a0f0975bbab7fda4dd2) and kept and tuned it ever since. Again, it is debatable where this should be fixed but since it is such an easy fix to venv while potentially keeping compatibility with tools relying on finding everything under lib/... as well as virtualenv itself, I'd think it would be nice to have it here. @vinay.sajip: I never said anything about adding links to the site-packages itself-- even though those can be useful and safe in a very limited number of cases. It is just about the fact that on systems where Python is installed under lib64, pip also installs to lib64 while the venv only creates a lib/ dir, no lib64/ symlink to it and some tools (rightfully so) rely on finding everything under lib/ itself... which is empty in that case. For the global python that is irrelevant because there is always a lib to lib64 symlink on multilib systems. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 11 15:24:02 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 11 Apr 2014 13:24:02 +0000 Subject: [issue21177] ValueError: byte must be in range(0, 256) In-Reply-To: <534789D1.3080707@free.fr> Message-ID: STINNER Victor added the comment: I suggested "must be in the range [0; 255]" which is not a valid Python list: ";" is the instruction operator and there is "range" word in front of the "list". In my opinion, it's much easier to read and understand it. Another example is the Unicode range(0x110000). "range [0; 0x10ffff]" would be better. Or maybe "must be in the range U+0000-U+10ffff" but it requires to know the Unicode U+HHHH syntax and the input type may be int, not a character. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 11 16:07:35 2014 From: report at bugs.python.org (Eric Snow) Date: Fri, 11 Apr 2014 14:07:35 +0000 Subject: [issue21200] pkgutil.get_loader() fails on "__main__" Message-ID: <1397225255.72.0.022634576387.issue21200@psf.upfronthosting.co.za> New submission from Eric Snow: Prior to 3.4, pkgutil.get_loader('__main__') would return None. Now it results in an ImportError. That's because it calls importlib.util.find_spec() which fails if an existing module does not have __spec__ or it is None. ---------- components: Library (Lib) keywords: 3.4regression messages: 215926 nosy: brett.cannon, eric.snow, larry, ncoghlan priority: release blocker severity: normal stage: test needed status: open title: pkgutil.get_loader() fails on "__main__" type: behavior versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 11 17:25:02 2014 From: report at bugs.python.org (akira) Date: Fri, 11 Apr 2014 15:25:02 +0000 Subject: [issue21177] ValueError: byte must be in range(0, 256) In-Reply-To: <1396947250.75.0.807471111064.issue21177@psf.upfronthosting.co.za> Message-ID: <1397229902.79.0.685294107881.issue21177@psf.upfronthosting.co.za> akira added the comment: "byte must be in range [0, 256)" - it hints at the builtin `range()` -- the intuition works for those who knows what `range()` does - it uses the standard math notation for half-open intervals [1] -- no Python knowledge required (among other things) - it is not a valid Python -- no confusion with a list, tuple literals - Dijkstra explains why half-open intervals are preferable [2] Another alternative is to use `range(0x100)` and require that to understand the error message, you should know Python and the hex notation. [1]: http://en.wikipedia.org/wiki/Interval_(mathematics)#Notations_for_intervals [2]: http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html ---------- nosy: +akira _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 11 17:30:40 2014 From: report at bugs.python.org (Vinay Sajip) Date: Fri, 11 Apr 2014 15:30:40 +0000 Subject: [issue21197] venv does not create lib64 directory and appropriate symlinks In-Reply-To: <1397137832.25.0.881871760177.issue21197@psf.upfronthosting.co.za> Message-ID: <1397230240.59.0.389621451221.issue21197@psf.upfronthosting.co.za> Vinay Sajip added the comment: Thanks for the info. I'm not opposed to adding a symlink on POSIX systems - I just wanted to make sure that was the right solution. My comment about adding links willy-nilly was about tools like Jedi that you mentioned (perhaps I misunderstood how it works). Clearly, if the idea is to support Pythons patched by distros, then it seems that there is little alternative available apart from the symlink. As you say, lib64 should be the symlink name, pointing to the lib directory. Should the symlink be created on 64-bit Linux venvs on all POSIX platforms, and should OS X be excluded? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 11 17:52:51 2014 From: report at bugs.python.org (Mark Lawrence) Date: Fri, 11 Apr 2014 15:52:51 +0000 Subject: [issue21177] ValueError: byte must be in range(0, 256) In-Reply-To: <1396947250.75.0.807471111064.issue21177@psf.upfronthosting.co.za> Message-ID: <1397231571.92.0.61022827899.issue21177@psf.upfronthosting.co.za> Mark Lawrence added the comment: How about plain English? "byte must be between 0 and 255 inclusive" ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 11 18:18:53 2014 From: report at bugs.python.org (Ned Deily) Date: Fri, 11 Apr 2014 16:18:53 +0000 Subject: [issue21197] venv does not create lib64 directory and appropriate symlinks In-Reply-To: <1397137832.25.0.881871760177.issue21197@psf.upfronthosting.co.za> Message-ID: <1397233133.63.0.779570713198.issue21197@psf.upfronthosting.co.za> Ned Deily added the comment: "should OS X be excluded?" Yes. OS X uses universal binaries, with multiple CPU archs automatically combined at build time into one file, so there generally is no need for arch-specific directories. But if the problem is being caused by Pythons patched by third-party distributors, shouldn't the onus be on them to properly patch venv, too, rather than having upstream CPython trying to guess what distributors are doing? ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 11 18:20:21 2014 From: report at bugs.python.org (Ned Deily) Date: Fri, 11 Apr 2014 16:20:21 +0000 Subject: [issue21194] json.dumps with ensure_ascii=False doesn't escape control characters In-Reply-To: <1397122270.44.0.660092890474.issue21194@psf.upfronthosting.co.za> Message-ID: <1397233221.5.0.829688751148.issue21194@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 11 18:49:12 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 11 Apr 2014 16:49:12 +0000 Subject: [issue21158] Windows installer service could not be accessed (Python bug!) In-Reply-To: <1396639122.72.0.136527705506.issue21158@psf.upfronthosting.co.za> Message-ID: <1397234952.08.0.694211888032.issue21158@psf.upfronthosting.co.za> Terry J. Reedy added the comment: If you were upgrading an existing install, try cleanly removing it from Control Panel / Programs and Features (Win 7). To do that, you may have to first fix the existing installation and that will require the installer used to install it. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 11 19:07:00 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 11 Apr 2014 17:07:00 +0000 Subject: [issue21177] ValueError: byte must be in range(0, 256) In-Reply-To: <1396947250.75.0.807471111064.issue21177@psf.upfronthosting.co.za> Message-ID: <1397236020.09.0.460057527168.issue21177@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > I suggested "must be in the range [0; 255]" which is not a valid Python > list: ";" is the instruction operator and there is "range" word in front of > the "list". In my opinion, it's much easier to read and understand it. I'm -1 on it. It may not be a valid Python list, but it definitely *looks* like a valid Python list, which makes it a double "wtf" IMO. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 11 19:08:13 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 11 Apr 2014 17:08:13 +0000 Subject: [issue21177] ValueError: byte must be in range(0, 256) In-Reply-To: <1396947250.75.0.807471111064.issue21177@psf.upfronthosting.co.za> Message-ID: <1397236093.93.0.387690026885.issue21177@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok, seeing how the alternative proposals are all worse than the statu quo, and how this is going a massive bikeshedding anyway, I'd rather close the issue. ---------- resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 11 19:20:20 2014 From: report at bugs.python.org (Wojciech Walczak) Date: Fri, 11 Apr 2014 17:20:20 +0000 Subject: [issue21201] Uninformative error message in multiprocessing.Manager() Message-ID: <1397236820.61.0.692426224091.issue21201@psf.upfronthosting.co.za> New submission from Wojciech Walczak: While using multiprocessing.Manager() to send data between processes I've noticed that one of the traceback messages is not very informative: Traceback (most recent call last): File "age_predict.py", line 39, in train_data, train_target, test_data = prepare_data() File "age_predict.py", line 30, in prepare_data train_data = q.get(True, 10000) File "", line 2, in get File "/usr/lib/python2.7/multiprocessing/managers.py", line 777, in _callmethod raise convert_to_error(kind, result) multiprocessing.managers.RemoteError: --------------------------------------------------------------------- Unserializable message: ('#RETURN', [A WHOLE LOT OF DATA GOES HERE] The real problem here is that my machine is running out of memory, but the traceback message shadows this information and reports "Unserializable message" instead. After a simple path (see: attached file) the traceback message is as follows: Traceback (most recent call last): File "age_predict.py", line 39, in train_data, train_target, test_data = prepare_data() File "age_predict.py", line 30, in prepare_data train_data = q.get(True, 10000) File "", line 2, in get File "/usr/lib/python2.7/multiprocessing/managers.py", line 775, in _callmethod raise convert_to_error(kind, result) multiprocessing.managers.RemoteError: --------------------------------------------------------------------- Unserializable message: Traceback (most recent call last): File "/usr/lib/python2.7/multiprocessing/managers.py", line 288, in serve_client send(msg) MemoryError: out of memory Here's another example (see: http://bugs.python.org/issue6766): This python3 code: from multiprocessing import Manager manager = Manager() ns_proxy = manager.Namespace() evt_proxy = manager.Event() ns_proxy.my_event_proxy = evt_proxy print(ns_proxy.my_event_proxy) Produces following traceback message: Traceback (most recent call last): File "test.py", line 6, in print(ns_proxy.my_event_proxy) File "/cpython/Lib/multiprocessing/managers.py", line 1032, in __getattr__ return callmethod('__getattribute__', (key,)) File "/cpython/Lib/multiprocessing/managers.py", line 748, in _callmethod raise convert_to_error(kind, result) multiprocessing.managers.RemoteError: ---------------------------------------------------------------------- Unserializable message: ('#RETURN', ) ---------------------------------------------------------------------- ...and after applying the attached patch it becomes clearer what's going on: Traceback (most recent call last): File "test.py", line 6, in print(ns_proxy.my_event_proxy) File "/cpython/Lib/multiprocessing/managers.py", line 1032, in __getattr__ return callmethod('__getattribute__', (key,)) File "/cpython/Lib/multiprocessing/managers.py", line 748, in _callmethod raise convert_to_error(kind, result) multiprocessing.managers.RemoteError: ---------------------------------------------------------------------- Unserializable message: Traceback (most recent call last): File "/cpython/Lib/multiprocessing/managers.py", line 276, in serve_client send(msg) File "/cpython/Lib/multiprocessing/connection.py", line 206, in send self._send_bytes(ForkingPickler.dumps(obj)) File "/cpython/Lib/multiprocessing/reduction.py", line 50, in dumps cls(buf, protocol).dump(obj) _pickle.PicklingError: Can't pickle : attribute lookup lock on _thread failed This patch doesn't break any tests. ---------- components: Library (Lib) files: managers_tb_msg.patch keywords: patch messages: 215934 nosy: wojtekwalczak priority: normal severity: normal status: open title: Uninformative error message in multiprocessing.Manager() type: behavior versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file34785/managers_tb_msg.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 11 19:38:07 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Fri, 11 Apr 2014 17:38:07 +0000 Subject: [issue19628] maxlevels -1 on compileall for unlimited recursion In-Reply-To: <1384634450.77.0.212426893492.issue19628@psf.upfronthosting.co.za> Message-ID: <1397237887.57.0.245702822525.issue19628@psf.upfronthosting.co.za> Claudiu.Popa added the comment: Added patch which addresses the comments of Berker Peksag. Thanks for the review! ---------- Added file: http://bugs.python.org/file34786/issue19628_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 11 19:41:53 2014 From: report at bugs.python.org (Antony Lee) Date: Fri, 11 Apr 2014 17:41:53 +0000 Subject: [issue21127] Path objects cannot be constructed from str subclasses In-Reply-To: <1396390108.81.0.285327356985.issue21127@psf.upfronthosting.co.za> Message-ID: <1397238113.09.0.545963020797.issue21127@psf.upfronthosting.co.za> Antony Lee added the comment: I am loading some structure from a MATLAB binary file using scipy.io.loadmat. This structure contains (in particular) paths (written as bytestrings) to other files which end up being loaded as numpy.str_ objects. In fact, just trying to store and retrieve strings from numpy arrays wraps them in numpy.str_: >>> import numpy >>> type(numpy.array(["foo"])[0]) ... and now trying to construct a Path from that will crash. I agree, though, that force-casting str subclasses in the constructor may avoid other issues. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 11 19:43:23 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 11 Apr 2014 17:43:23 +0000 Subject: [issue21164] print unicode in Windows console In-Reply-To: <1396839472.79.0.493888101601.issue21164@psf.upfronthosting.co.za> Message-ID: <1397238203.35.0.38139538478.issue21164@psf.upfronthosting.co.za> Terry J. Reedy added the comment: You can change the code page of a Command Prompt window, before calling Python, with ...> chcp . There is 'something' called cp65001 that is supposed to be a utf-8 codepage. Once can change to it, but it does not work right. This has been discussed on StackOverflow and elsewhere. The Idle Shell, running on tkinter, handles everything in the BMP because tcl/tk is unicode (ucs-2) based. The characters that display properly depend on the font you select. On my machine, all but three of the following arbitrary codepoints display proper characters. >>> print('\u1111\u2222\u3333\u4444\u5555\u6666\u7777\u8888\u9999\uaaaa\ubbbb\ucccc\udddd\ueeee') ?????????????? ---------- nosy: +terry.reedy resolution: -> duplicate status: open -> closed superseder: -> windows console doesn't print or input Unicode _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 11 19:46:00 2014 From: report at bugs.python.org (Stefan Krah) Date: Fri, 11 Apr 2014 17:46:00 +0000 Subject: [issue21177] ValueError: byte must be in range(0, 256) In-Reply-To: <1397236020.09.0.460057527168.issue21177@psf.upfronthosting.co.za> Message-ID: <20140411174559.GA6135@sleipnir.bytereef.org> Stefan Krah added the comment: Antoine Pitrou wrote: > > I suggested "must be in the range [0; 255]" which is not a valid Python > > list: ";" is the instruction operator and there is "range" word in front of > > the "list". In my opinion, it's much easier to read and understand it. > > I'm -1 on it. It may not be a valid Python list, but it definitely *looks* like a valid Python list, which makes it a double "wtf" IMO. It's a valid OCaml list;; :P [Glad that the issue is closed] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 11 19:57:22 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 11 Apr 2014 17:57:22 +0000 Subject: [issue21170] Incorrect signature for unittest.TestResult.startTestRun(), .stopTestRun() In-Reply-To: <1396881559.52.0.157201741461.issue21170@psf.upfronthosting.co.za> Message-ID: <1397239042.64.0.712895941716.issue21170@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Good catch. I verified in code that patch is correct. ---------- assignee: docs at python -> terry.reedy nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 11 20:05:51 2014 From: report at bugs.python.org (Madison May) Date: Fri, 11 Apr 2014 18:05:51 +0000 Subject: [issue21202] Naming a file` io.py` causes cryptic error message Message-ID: <1397239551.94.0.578791540537.issue21202@psf.upfronthosting.co.za> New submission from Madison May: Naming a file `io.py` in the root directory of a project causes the following error on 2.7: AttributeError: 'module' object has no attribute 'BufferedIOBase' Similar issues arise on 3.x., although the error message is a bit more useful: Fatal Python error: Py_Initialize: can't initialize sys standard streams AttributeError: 'module' object has no attribute 'OpenWrapper' At the very least we should ensure that the error message is a bit more straightforward and clear, as I imagine its not all that uncommon to cause this kind of conflict. ---------- assignee: docs at python components: Documentation, IO messages: 215940 nosy: docs at python, madison.may priority: normal severity: normal status: open title: Naming a file` io.py` causes cryptic error message versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 11 20:06:04 2014 From: report at bugs.python.org (Madison May) Date: Fri, 11 Apr 2014 18:06:04 +0000 Subject: [issue21202] Naming a file` io.py` causes cryptic error message In-Reply-To: <1397239551.94.0.578791540537.issue21202@psf.upfronthosting.co.za> Message-ID: <1397239564.78.0.0710686181413.issue21202@psf.upfronthosting.co.za> Changes by Madison May : ---------- versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 11 20:12:10 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 11 Apr 2014 18:12:10 +0000 Subject: [issue21170] Incorrect signature for unittest.TestResult.startTestRun(), .stopTestRun() In-Reply-To: <1396881559.52.0.157201741461.issue21170@psf.upfronthosting.co.za> Message-ID: <3g56kc5MqJz7LjP@mail.python.org> Roundup Robot added the comment: New changeset c1ea2846a564 by Terry Jan Reedy in branch '2.7': Issue #21170: Removed invalid parameter names from unittest doc. http://hg.python.org/cpython/rev/c1ea2846a564 New changeset 5734175a87d1 by Terry Jan Reedy in branch '3.4': Issue #21170: Removed invalid parameter names from unittest doc. http://hg.python.org/cpython/rev/5734175a87d1 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 11 20:12:59 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 11 Apr 2014 18:12:59 +0000 Subject: [issue21170] Incorrect signature for unittest.TestResult.startTestRun(), .stopTestRun() In-Reply-To: <1396881559.52.0.157201741461.issue21170@psf.upfronthosting.co.za> Message-ID: <1397239979.59.0.481634157743.issue21170@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 11 20:35:14 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 11 Apr 2014 18:35:14 +0000 Subject: [issue21193] pow(a, b, c) should not raise TypeError when b is negative and c is provided In-Reply-To: <1397089497.66.0.725830795875.issue21193@psf.upfronthosting.co.za> Message-ID: <3g57FF6tfbz7LjM@mail.python.org> Roundup Robot added the comment: New changeset dc6c2ab7fec2 by Mark Dickinson in branch 'default': Issue #21193: Make (e.g.,) pow(2, -3, 5) raise ValueError rather than TypeError. Patch by Josh Rosenberg. http://hg.python.org/cpython/rev/dc6c2ab7fec2 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 11 20:36:53 2014 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 11 Apr 2014 18:36:53 +0000 Subject: [issue21193] pow(a, b, c) should not raise TypeError when b is negative and c is provided In-Reply-To: <1397089497.66.0.725830795875.issue21193@psf.upfronthosting.co.za> Message-ID: <1397241413.17.0.204904463001.issue21193@psf.upfronthosting.co.za> Mark Dickinson added the comment: Patch applied. Thanks, all. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 11 20:38:07 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 11 Apr 2014 18:38:07 +0000 Subject: [issue21171] Outdated usage str.encode('rot-13') in rot13 codec In-Reply-To: <1396887951.87.0.0918755245814.issue21171@psf.upfronthosting.co.za> Message-ID: <1397241487.77.0.368509721163.issue21171@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Since rot_13 is a transcoder, not an encoder, the error message is correct, as is the fix for the function. However, since neither the module encodings.rot_13 nor the rot13 function in the module are documented, (not even in 2.7), I wonder if the function and the if __name__; clause are ancient holdovers that should be removed. In other words, I am not sure if Berker's test is currently a supported usage. I remember that there was some discussion on pydev about how much to add back but not the details. ---------- nosy: +benjamin.peterson, ezio.melotti, haypo, pitrou, terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 11 20:51:09 2014 From: report at bugs.python.org (Leslie Klein) Date: Fri, 11 Apr 2014 18:51:09 +0000 Subject: [issue21164] print unicode in Windows console In-Reply-To: <1396868920.46.0.884837755106.issue21164@psf.upfronthosting.co.za> Message-ID: Leslie Klein added the comment: I start ipython in Windows PowerShell. The "console" I am referring to is ipython running in WindowsPowerShell. I do not use the DOS cmd.exe When running ipython notebook from WindowsPowerShell -- no problem printing unicode. When running in PTVS (Python Tools for Visual Studio) debugger -- no problem printing unicode in Output window, or Interactive Python window. Problem does appear in Console window (which is the DOS window I believe). On Mon, Apr 7, 2014 at 7:08 AM, STINNER Victor wrote: > > STINNER Victor added the comment: > > Hi, when you say "The console" is the the old MS-DOS command ("Windows > console") opened when you run the "cmd.exe" program? Or IDLE or another > console? > > For the Windows console, see the old issue #1602 which is not fixed yet. > > On Windows, sys.stdout.encoding is your OEM code page, which is usually > different than the ANSI code page (locale.getpreferredencoding()). > > ---------- > nosy: +haypo > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 11 20:58:02 2014 From: report at bugs.python.org (Ned Deily) Date: Fri, 11 Apr 2014 18:58:02 +0000 Subject: [issue21202] Naming a file` io.py` causes cryptic error message In-Reply-To: <1397239551.94.0.578791540537.issue21202@psf.upfronthosting.co.za> Message-ID: <1397242682.67.0.185637016322.issue21202@psf.upfronthosting.co.za> Ned Deily added the comment: Using a local module name that shadows one in the standard library is a very common "import trap". See, for example, https://ncoghlan_devs-python-notes.readthedocs.org/en/latest/python_concepts/import_traps.html#the-name-shadowing-trap. I did a quick search through the documentation and didn't find an explicit reference to the general topic. If it isn't already, it probably should be mentioned in the tutorial and the FAQ. I don't think that 'io' should be special-cased. ---------- components: -IO nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 11 21:01:04 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 11 Apr 2014 19:01:04 +0000 Subject: [issue21202] Naming a file` io.py` causes cryptic error message In-Reply-To: <1397239551.94.0.578791540537.issue21202@psf.upfronthosting.co.za> Message-ID: <1397242864.41.0.399333677425.issue21202@psf.upfronthosting.co.za> Brett Cannon added the comment: While mentioning something in the FAQ and/or tutorial is fine, I wouldn't want to change Python's message too much to deal with this unless it was extremely fast (e.g. we pre-generated a set and check that on ImportError and then modified the message only in those instances). ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 11 21:07:01 2014 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 11 Apr 2014 19:07:01 +0000 Subject: [issue21202] Naming a file` io.py` causes cryptic error message In-Reply-To: <1397239551.94.0.578791540537.issue21202@psf.upfronthosting.co.za> Message-ID: <1397243221.9.0.559692564786.issue21202@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti, ncoghlan type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 11 21:22:28 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 11 Apr 2014 19:22:28 +0000 Subject: [issue21178] doctest cause warnings in tests using generators In-Reply-To: <1396954146.87.0.0393521418681.issue21178@psf.upfronthosting.co.za> Message-ID: <1397244148.35.0.863310331939.issue21178@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I not am not sure I see a bug here, a discrepancy between doc and behavior. Even if not, you may have a legitimate enhancement request. 3.4 now warns about ignored exceptions during shutdown in case there is a fixable bug in the code being shut down. This is intended to be a feature, not a problem. I don't know if the warnings can be suppressed. 3.4 also implemented PEP 442 so "objects with __del__() methods, as well as generators with finally clauses, can be finalized when they are part of a reference cycle." Your second patch puts a generator in a reference cycle. Generators have a .__del__ method. Perhaps its body is the equivalent of "self.throw(GeneratorExit)". If so, that could be wrapped with the equivalent of "try:...except BaseException: pass" to avoid leaking exceptions. ---------- nosy: +ncoghlan, terry.reedy stage: -> needs patch versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 11 21:31:30 2014 From: report at bugs.python.org (Ned Deily) Date: Fri, 11 Apr 2014 19:31:30 +0000 Subject: [issue21201] Uninformative error message in multiprocessing.Manager() In-Reply-To: <1397236820.61.0.692426224091.issue21201@psf.upfronthosting.co.za> Message-ID: <1397244690.62.0.306075061893.issue21201@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +sbt versions: -Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 11 21:38:09 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 11 Apr 2014 19:38:09 +0000 Subject: [issue21193] pow(a, b, c) should not raise TypeError when b is negative and c is provided In-Reply-To: <1397089497.66.0.725830795875.issue21193@psf.upfronthosting.co.za> Message-ID: <3g58ds0ngwz7Lk7@mail.python.org> Roundup Robot added the comment: New changeset a8f3ca72f703 by Benjamin Peterson in branch 'default': test the change of #21193 correctly http://hg.python.org/cpython/rev/a8f3ca72f703 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 11 21:38:37 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 11 Apr 2014 19:38:37 +0000 Subject: [issue21180] Cannot efficiently create empty array.array of given size, inconsistency with bytearray In-Reply-To: <1396963926.18.0.0845457465299.issue21180@psf.upfronthosting.co.za> Message-ID: <1397245117.95.0.945232306925.issue21180@psf.upfronthosting.co.za> Terry J. Reedy added the comment: You are proposing to copy behavior that will likely be deprecated and removed (see http://legacy.python.org/dev/peps/pep-0467/#id5). Lets reject that idea. The same pep proposes to replace byte(s/array)(n) "by two more explicit alternate constructors provided as class methods" -- perhaps called .zeros(n). A proposal to copy the new replacements to array might be accepted. ---------- nosy: +ncoghlan, terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 11 21:41:20 2014 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 11 Apr 2014 19:41:20 +0000 Subject: [issue21193] pow(a, b, c) should not raise TypeError when b is negative and c is provided In-Reply-To: <1397089497.66.0.725830795875.issue21193@psf.upfronthosting.co.za> Message-ID: <1397245280.24.0.653157068523.issue21193@psf.upfronthosting.co.za> Mark Dickinson added the comment: Benjamin: thanks for the fix. To be clear: Josh Rosenberg's patch had the correct test change. It was the (poorly) trained monkey who made the commit who broke the test. Sorry, all. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 11 22:03:17 2014 From: report at bugs.python.org (Madison May) Date: Fri, 11 Apr 2014 20:03:17 +0000 Subject: [issue21202] Naming a file` io.py` causes cryptic error message In-Reply-To: <1397239551.94.0.578791540537.issue21202@psf.upfronthosting.co.za> Message-ID: <1397246597.13.0.750000012717.issue21202@psf.upfronthosting.co.za> Madison May added the comment: I definitely agree that io shouldn't be special cased, as it's more about the name shadowing issue that this specific example. A simple docs addition would make me happy, to be honest. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 11 22:34:08 2014 From: report at bugs.python.org (R. David Murray) Date: Fri, 11 Apr 2014 20:34:08 +0000 Subject: [issue14758] SMTPServer of smptd does not support binding to an IPv6 address In-Reply-To: <1336511750.16.0.237606043889.issue14758@psf.upfronthosting.co.za> Message-ID: <1397248448.5.0.0210472116533.issue14758@psf.upfronthosting.co.za> R. David Murray added the comment: I added some review comments. Since this is a new feature, the patch also needs a 'versionchanged' that indicates that ipv6 support was added. ---------- stage: needs patch -> patch review versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 11 23:39:28 2014 From: report at bugs.python.org (Jure Koren) Date: Fri, 11 Apr 2014 21:39:28 +0000 Subject: [issue21203] logging configurators ignoring documented options Message-ID: <1397252368.02.0.0923177521945.issue21203@psf.upfronthosting.co.za> New submission from Jure Koren: 2.7's logging.config.DictConfig does not respect the "class" option, but fileConfig does. The default branch logging.config has the same problem in DictConfig, but also lacks "style" support in fileConfig. ---------- components: Library (Lib) files: logging_config_2_7.diff hgrepos: 233 keywords: patch messages: 215954 nosy: Jure.Koren priority: normal severity: normal status: open title: logging configurators ignoring documented options type: behavior versions: Python 2.7, Python 3.5 Added file: http://bugs.python.org/file34787/logging_config_2_7.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 11 23:41:56 2014 From: report at bugs.python.org (Jure Koren) Date: Fri, 11 Apr 2014 21:41:56 +0000 Subject: [issue21203] logging configurators ignoring documented options In-Reply-To: <1397252368.02.0.0923177521945.issue21203@psf.upfronthosting.co.za> Message-ID: <1397252516.19.0.993480624678.issue21203@psf.upfronthosting.co.za> Jure Koren added the comment: 2.7's logging.config.DictConfig does not respect the "class" option, but fileConfig does. The default branch logging.config has the same problem in DictConfig, but also lacks "style" support in fileConfig. ---------- hgrepos: +234 Added file: http://bugs.python.org/file34788/logging_config_default.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 12 02:04:00 2014 From: report at bugs.python.org (Josiah Carlson) Date: Sat, 12 Apr 2014 00:04:00 +0000 Subject: [issue1191964] asynchronous Subprocess Message-ID: <1397261040.2.0.656148417625.issue1191964@psf.upfronthosting.co.za> Josiah Carlson added the comment: I added the chunking for Windows because in manual testing before finishing the patch, I found that large sends on Windows without actually waiting for the result can periodically result in zero data sent, despite a child process that wants to read. Looking a bit more, this zero result is caused by ov.cancel() followed by ov.getresult() raising an OSError, specifically: [WinError 995] The I/O operation has been aborted because of either a thread exit or an application request That causes us to observe on the Python side of things that zero data was sent for some writes, but when looking at what the child process actually received, we discover that some data was actually sent. How much compared to what we thought we sent? That depends. I observed in testing today that the client could receive ~3.5 megs when we thought we had sent ~3 megs. To make a long story short-ish, using Overlapped IO with WriteFile() and Overlapped.cancel(), without pausing between attempts with either a sleep or something else results in a difference in what we think vs. reality roughly 87% of the time with 512 byte chunks (87 trials out of 100), and roughly 100% of the time with 4096 byte chunks (100 trials out of 100). Note that this is when constantly trying to write data to the pipe. (each trial is as many Popen.write_nonblocking() calls as can complete in .25 seconds) Inducing a 1 ms sleep between each overlapped.WriteFile() attempt drops the error rate to 0/100 trials and 1/100 trials for 512 byte and 4096 byte writes, respectively. Testing for larger block sizes suggests that 2048 bytes is the largest send that we can push through and actually get correct results. So, according to my tests, there isn't a method by which we can both cancel an overlapped IO while at the same time guaranteeing that we will account exactly for the data that was actually sent without adding an implicit or explicit delay. Which makes sense as we are basically trying to interrupt another process in their attempts to read data that we said they could read, but doing so via a kernel call that interrupts another kernel call that is doing chunk-by-chunk copies from our write buffer (maybe to some kernel memory then) to their read buffer. Anyway, by cutting down what we attempt to send at any one time, and forcing delays between attempted sends, we can come pretty close to guaranteeing that child processes don't have any sends that we can't account for. I'll try to get a patch out this weekend that encompasses these ideas with a new test that demonstrates the issue on Windows (for those who want to verify my results). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 12 03:50:40 2014 From: report at bugs.python.org (jmaki) Date: Sat, 12 Apr 2014 01:50:40 +0000 Subject: [issue21204] published examples don't work Message-ID: <1397267440.3.0.253901505287.issue21204@psf.upfronthosting.co.za> New submission from jmaki: Would you consider putting examples given in official documentation as part of release testing? e.g. (from official python.org documentation): ----------------- snip --------------------- An example of how a pool of worker processes can each run a SimpleHTTPServer.HttpServer instance while sharing a single listening socket. # # Example where a pool of http servers share a single listening socket # # On Windows this module depends on the ability to pickle a socket # object so that the worker processes can inherit a copy of the server # object. (We import `multiprocessing.reduction` to enable this pickling.) # # Not sure if we should synchronize access to `socket.accept()` method by # using a process-shared lock -- does not seem to be necessary. # # Copyright (c) 2006-2008, R Oudkerk # All rights reserved. # import os import sys from multiprocessing import Process, current_process, freeze_support from BaseHTTPServer import HTTPServer from SimpleHTTPServer import SimpleHTTPRequestHandler if sys.platform == 'win32': import multiprocessing.reduction # make sockets pickable/inheritable def note(format, *args): sys.stderr.write('[%s]\t%s\n' % (current_process().name, format%args)) class RequestHandler(SimpleHTTPRequestHandler): # we override log_message() to show which process is handling the request def log_message(self, format, *args): note(format, *args) def serve_forever(server): note('starting server') try: server.serve_forever() except KeyboardInterrupt: pass def runpool(address, number_of_processes): # create a single server object -- children will each inherit a copy server = HTTPServer(address, RequestHandler) # create child processes to act as workers for i in range(number_of_processes-1): Process(target=serve_forever, args=(server,)).start() # main process also acts as a worker serve_forever(server) def test(): DIR = os.path.join(os.path.dirname(__file__), '..') ADDRESS = ('localhost', 8000) NUMBER_OF_PROCESSES = 4 print 'Serving at http://%s:%d using %d worker processes' % \ (ADDRESS[0], ADDRESS[1], NUMBER_OF_PROCESSES) print 'To exit press Ctrl-' + ['C', 'Break'][sys.platform=='win32'] os.chdir(DIR) runpool(ADDRESS, NUMBER_OF_PROCESSES) if __name__ == '__main__': freeze_support() test() ----------------- snip --------------------- does not work on windows... Regards, John ---------- components: Cross-Build messages: 215957 nosy: jmaki priority: normal severity: normal status: open title: published examples don't work type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 12 04:40:49 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 12 Apr 2014 02:40:49 +0000 Subject: [issue7951] Should str.format allow negative indexes when used for __getitem__ access? In-Reply-To: <1266450859.13.0.906832569526.issue7951@psf.upfronthosting.co.za> Message-ID: <1397270449.56.0.423086344465.issue7951@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Either leading sign, '+' or '-', cause string interpretation, so I think 'unsigned integer' should be the term in the doc. >>> '{0[-1]}'.format({'-1': 'neg int key'}) 'neg int key' >>> '{0[+1]}'.format({'+1': 'neg int key'}) 'neg int key' >>> '{0[+1]}'.format([1,2,3]) Traceback (most recent call last): File "", line 1, in '{0[+1]}'.format([1,2,3]) TypeError: list indices must be integers, not str ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 12 05:29:45 2014 From: report at bugs.python.org (STINNER Victor) Date: Sat, 12 Apr 2014 03:29:45 +0000 Subject: [issue21171] Outdated usage str.encode('rot-13') in rot13 codec In-Reply-To: <1396887951.87.0.0918755245814.issue21171@psf.upfronthosting.co.za> Message-ID: <1397273385.39.0.382383877747.issue21171@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 12 07:04:21 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Sat, 12 Apr 2014 05:04:21 +0000 Subject: [issue15955] gzip, bz2, lzma: add option to limit output size In-Reply-To: <1347884562.79.0.801674791772.issue15955@psf.upfronthosting.co.za> Message-ID: <1397279061.89.0.947012972326.issue15955@psf.upfronthosting.co.za> Nikolaus Rath added the comment: I've attached the second iteration of the patch. I've factored out a new function decompress_buf, and added two new (C only) instance variables input_buffer and input_buffer_size. I've tested the patch by enabling Py_USING_MEMORY_DEBUGGER in Objects/obmalloc.c and compiling --with-pydebug --without-pymalloc. Output is: $ valgrind --tool=memcheck --suppressions=Misc/valgrind-python.supp ./python -m test -R : -v test_lzma ==18635== Memcheck, a memory error detector ==18635== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==18635== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info ==18635== Command: ./python -m test -R : -v test_lzma ==18635== == CPython 3.5.0a0 (default:a8f3ca72f703+, Apr 11 2014, 21:48:07) [GCC 4.8.2] [....] Ran 103 tests in 43.655s OK beginning 9 repetitions 123456789 [...] OK . 1 test OK. ==18635== ==18635== HEAP SUMMARY: ==18635== in use at exit: 2,328,705 bytes in 13,625 blocks ==18635== total heap usage: 2,489,623 allocs, 2,475,998 frees, 91,305,463,593 bytes allocated ==18635== ==18635== LEAK SUMMARY: ==18635== definitely lost: 0 bytes in 0 blocks ==18635== indirectly lost: 0 bytes in 0 blocks ==18635== possibly lost: 963,533 bytes in 1,334 blocks ==18635== still reachable: 1,365,172 bytes in 12,291 blocks ==18635== suppressed: 0 bytes in 0 blocks ==18635== Rerun with --leak-check=full to see details of leaked memory ==18635== ==18635== For counts of detected and suppressed errors, rerun with: -v ==18635== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2) When running the tests only once (no -R option), the number of possibly lost bytes is 544,068 in 1,131 blocks. When running without the patch, the number is 545,740 bytes in 1,134 blocks (for one iteration). I guess this means that Python is using interior pointers, so these blocks are not truly lost? ---------- Added file: http://bugs.python.org/file34789/issue15955_r2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 12 07:35:53 2014 From: report at bugs.python.org (Ned Deily) Date: Sat, 12 Apr 2014 05:35:53 +0000 Subject: [issue21203] logging configurators ignoring documented options In-Reply-To: <1397252368.02.0.0923177521945.issue21203@psf.upfronthosting.co.za> Message-ID: <1397280953.51.0.305336855147.issue21203@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 12 07:55:10 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sat, 12 Apr 2014 05:55:10 +0000 Subject: [issue21196] Name mangling example in Python tutorial In-Reply-To: <1397133080.37.0.870141660622.issue21196@psf.upfronthosting.co.za> Message-ID: <1397282110.7.0.521700678326.issue21196@psf.upfronthosting.co.za> ?ric Araujo added the comment: Thanks for the report and proposed fix! Could you upload a patch file that we could directly apply to the documentation instead of Python files? More information about how to do that is found here: https://docs.python.org/devguide/#quick-start If you need any kind of help, the devguide has the address of the core-mentorship mailing list where many friendly people can answer questions. You can also ask in this issue page. ---------- nosy: +eric.araujo stage: -> patch review versions: +Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 12 08:00:28 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sat, 12 Apr 2014 06:00:28 +0000 Subject: [issue21197] venv does not create lib64 directory and appropriate symlinks In-Reply-To: <1397137832.25.0.881871760177.issue21197@psf.upfronthosting.co.za> Message-ID: <1397282428.47.0.712880791451.issue21197@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 12 08:24:52 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sat, 12 Apr 2014 06:24:52 +0000 Subject: [issue21171] Outdated usage str.encode('rot-13') in rot13 codec In-Reply-To: <1396887951.87.0.0918755245814.issue21171@psf.upfronthosting.co.za> Message-ID: <1397283892.91.0.873069653847.issue21171@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 12 08:27:29 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sat, 12 Apr 2014 06:27:29 +0000 Subject: [issue21188] Broken link In-Reply-To: <1397050895.39.0.221241316975.issue21188@psf.upfronthosting.co.za> Message-ID: <1397284049.22.0.379213009571.issue21188@psf.upfronthosting.co.za> ?ric Araujo added the comment: Thanks for the report. If the python.org links can be found in the Internet Archive, then one could find the new addresses to use by looking for the same message on http://www.python.org/pipermail/python-dev/2000-March/ Would you be willing to try that? ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 12 08:27:45 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sat, 12 Apr 2014 06:27:45 +0000 Subject: [issue21186] RawConfigParser __name__ option handling inconsistent In-Reply-To: <1397033583.06.0.34789258522.issue21186@psf.upfronthosting.co.za> Message-ID: <1397284065.05.0.00734881468711.issue21186@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- assignee: -> lukasz.langa nosy: +lukasz.langa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 12 08:28:32 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sat, 12 Apr 2014 06:28:32 +0000 Subject: [issue21198] Minor tarfile documentation bug In-Reply-To: <1397148227.41.0.631676560193.issue21198@psf.upfronthosting.co.za> Message-ID: <1397284112.39.0.137299392355.issue21198@psf.upfronthosting.co.za> ?ric Araujo added the comment: Thanks for the report. Is it an issue in the docstrings, the HTML documentation or both? ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 12 09:09:51 2014 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 12 Apr 2014 07:09:51 +0000 Subject: [issue21161] list comprehensions don't see local variables in pdb in python3 In-Reply-To: <1396698943.39.0.489151150852.issue21161@psf.upfronthosting.co.za> Message-ID: <1397286591.37.0.571425509942.issue21161@psf.upfronthosting.co.za> Xavier de Gaye added the comment: FWIW this generator expression can be evaluated with the 'interact' command: --Return-- > /test/comprehension.py(5)foo()->None -> pdb.set_trace() (Pdb) interact *interactive* >>> all(x < limit for x in items) True >>> (Pdb) ---------- nosy: +xdegaye _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 12 09:18:18 2014 From: report at bugs.python.org (Matthias Dahl) Date: Sat, 12 Apr 2014 07:18:18 +0000 Subject: [issue21197] venv does not create lib64 directory and appropriate symlinks In-Reply-To: <1397137832.25.0.881871760177.issue21197@psf.upfronthosting.co.za> Message-ID: <1397287098.34.0.489746503485.issue21197@psf.upfronthosting.co.za> Matthias Dahl added the comment: @vinay.sajip: No problem. Jedi is a auto-completion library. It does not add any links anywhere. It naturally has to know about which venvs you use so it can find all modules and their sources to process them. Thus, you (or the implementation using Jedi) pass it the base directories of the venvs and it constructs the appropriate path to the site-packages and uses those internally. Rightfully, it assumes a lib/ directory to contain everything which works just fine for virtualenv created venvs due to the symlink but not for venv created venvs. @ned.deily: I know what you mean. And I am very inclined to fully agree with you that dists should patch this as well. But the problem I see with this is: Except for Debian-based dists, all of the other major ones (Gentoo, Fedora/RedHat/CentOS, OpenSUSE, ...) and their derivatives, put Python under lib64/ on multilib systems. And the patches they use and the changes they introduce already differ here and there in important key details. It would be no different with this issue as well. Besides, this scenario (Python under lib64/) is not so uncommon anymore and imho, should be supported by Python out of the box by making those things properly configurable during compilation. But that is a different subject altogether. IMHO, this feature is small enough to be added to Python's venv to standardize it across dists. Besides, it makes it more compatible and a better drop-in replacement for virtualenv itself. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 12 10:22:41 2014 From: report at bugs.python.org (=?utf-8?q?Ontje_L=C3=BCnsdorf?=) Date: Sat, 12 Apr 2014 08:22:41 +0000 Subject: [issue21178] doctest cause warnings in tests using generators In-Reply-To: <1396954146.87.0.0393521418681.issue21178@psf.upfronthosting.co.za> Message-ID: <1397290961.22.0.392882765226.issue21178@psf.upfronthosting.co.za> Ontje L?nsdorf added the comment: I think there may be a bug in doctest which is getting exposed by Python 3.4 new handling of reference cycles. I've attached a simpler example with a global variable. There's no error if you run the code directly, the global variable still exists during the generator exit. If you run it with doctest in Python 3.4 you get the warning because the global variable has been deleted. In this corner case, doctest execution seem to differ from Python. ---------- Added file: http://bugs.python.org/file34790/doctest.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 12 11:28:16 2014 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 12 Apr 2014 09:28:16 +0000 Subject: [issue21161] list comprehensions don't see local variables in pdb in python3 In-Reply-To: <1396698943.39.0.489151150852.issue21161@psf.upfronthosting.co.za> Message-ID: <1397294896.55.0.456711302284.issue21161@psf.upfronthosting.co.za> Xavier de Gaye added the comment: The runcode() method of InteractiveInterpreter in code.py uses the 'self.locals' dictionary as the 'globals' parameter of the invoked exec() function. And the do_interact() method of Pdb instantiates InteractiveInterpreter with 'locals' as a merge of the current frame's locals and globals dictionary. This explains why the interact command of pdb evaluates sucessfully the generator expression: the generator function object is evaluated by the interpreter in a frame where 'locals' is NULL (see fast_function() in ceval.c) and 'globals' includes now the debugged frame locals dictionary. So a fix for this problem is to have the default() method of pdb be implemented in the same manner as do_interact() and the runcode() method of InteractiveInterpreter. The attached patch does this. ---------- keywords: +patch Added file: http://bugs.python.org/file34791/genexp.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 12 11:58:57 2014 From: report at bugs.python.org (Florent Xicluna) Date: Sat, 12 Apr 2014 09:58:57 +0000 Subject: [issue21202] Naming a file` io.py` causes cryptic error message In-Reply-To: <1397239551.94.0.578791540537.issue21202@psf.upfronthosting.co.za> Message-ID: <1397296737.58.0.0166881695258.issue21202@psf.upfronthosting.co.za> Changes by Florent Xicluna : ---------- nosy: +flox _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 12 12:03:58 2014 From: report at bugs.python.org (=?utf-8?q?Jurko_Gospodneti=C4=87?=) Date: Sat, 12 Apr 2014 10:03:58 +0000 Subject: [issue21161] list comprehensions don't see local variables in pdb in python3 In-Reply-To: <1396698943.39.0.489151150852.issue21161@psf.upfronthosting.co.za> Message-ID: <1397297038.61.0.108282931252.issue21161@psf.upfronthosting.co.za> Jurko Gospodneti? added the comment: Thanks for looking into this Xavier. Could someone reopen this issue so it can gets looked at again? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 12 12:40:55 2014 From: report at bugs.python.org (mk) Date: Sat, 12 Apr 2014 10:40:55 +0000 Subject: [issue15716] Ability to specify the PYTHONPATH via a command line flag In-Reply-To: <1345164027.44.0.397805734201.issue15716@psf.upfronthosting.co.za> Message-ID: <1397299255.76.0.569003959402.issue15716@psf.upfronthosting.co.za> Changes by mk : ---------- nosy: +migel.k _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 12 13:14:07 2014 From: report at bugs.python.org (=?utf-8?q?Szieberth_=C3=81d=C3=A1m?=) Date: Sat, 12 Apr 2014 11:14:07 +0000 Subject: [issue21205] Unable to make decorated generator object to inherit generator function's __name__ Message-ID: <1397301247.66.0.634427842107.issue21205@psf.upfronthosting.co.za> New submission from Szieberth ?d?m: I faced this particular issue by writing decorators for asyncio coroutines. I even posted a question to SO: http://stackoverflow.com/questions/23015626/how-to-decorate-an-asyncio-coroutine-to-retain-its-name However, since that I realized the problem is more general. I believe that a generator object should inherit its function's __name__ attribute instead of ignoring it. Example: ################################################################ import functools def decorated(genfunc): @functools.wraps(genfunc) def wrapper(*args, **kargs): print('inside wrapper') for x in genfunc(*args, **kargs): yield 'decorated: {!r}'.format(x) print('outside wrapper') print('wrapper.__name__: {!r}'.format(wrapper.__name__)) return wrapper @decorated def simple_genfunc(): """Testdoc.""" yield from range(10) if __name__ == '__main__': print('simple_genfunc.__name__: {!r}'.format( simple_genfunc.__name__)) print('simple_genfunc().__name__: {!r}'.format( simple_genfunc().__name__)) ################################################################ And its result: Z:\>python -i genfuncdec.py outside wrapper wrapper.__name__: 'simple_genfunc' simple_genfunc.__name__: 'simple_genfunc' simple_genfunc().__name__: 'wrapper' >>> simple_genfunc >>> simple_genfunc.__wrapped__ >>> simple_genfunc() >>> simple_genfunc.__wrapped__() As you can see the generator object's __name__ remained the hardcoded one. ---------- messages: 215968 nosy: SzieberthAdam priority: normal severity: normal status: open title: Unable to make decorated generator object to inherit generator function's __name__ type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 12 13:32:56 2014 From: report at bugs.python.org (Richard Oudkerk) Date: Sat, 12 Apr 2014 11:32:56 +0000 Subject: [issue1191964] asynchronous Subprocess Message-ID: <1397302376.33.0.86381951793.issue1191964@psf.upfronthosting.co.za> Richard Oudkerk added the comment: I added some comments. Your problem with lost data may be caused by the fact you call ov.cancel() and expect ov.pending to tell you whether the write has/will succeed. Instead you should use ov.getresult() and expect either success or an "aborted" error. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 12 14:29:43 2014 From: report at bugs.python.org (Ram Rachum) Date: Sat, 12 Apr 2014 12:29:43 +0000 Subject: [issue21206] Provide legit HTTPS certificate for http://bugs.python.org/, redirect HTTP to HTTPS Message-ID: <1397305783.0.0.175051224011.issue21206@psf.upfronthosting.co.za> New submission from Ram Rachum: Otherwise people could MITM our passwords. ---------- components: Demos and Tools messages: 215970 nosy: cool-RR priority: normal severity: normal status: open title: Provide legit HTTPS certificate for http://bugs.python.org/, redirect HTTP to HTTPS _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 12 15:10:19 2014 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 12 Apr 2014 13:10:19 +0000 Subject: [issue20624] Clarify recommendation to inherit from Exception In-Reply-To: <1392377489.91.0.767550317256.issue20624@psf.upfronthosting.co.za> Message-ID: <1397308219.72.0.448080831927.issue20624@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- assignee: docs at python -> mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 12 15:12:45 2014 From: report at bugs.python.org (Wolfgang Maier) Date: Sat, 12 Apr 2014 13:12:45 +0000 Subject: [issue21204] published examples don't work In-Reply-To: <1397267440.3.0.253901505287.issue21204@psf.upfronthosting.co.za> Message-ID: <1397308365.96.0.0097388310016.issue21204@psf.upfronthosting.co.za> Changes by Wolfgang Maier : ---------- nosy: +wolma _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 12 15:13:23 2014 From: report at bugs.python.org (Eric Snow) Date: Sat, 12 Apr 2014 13:13:23 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1397308403.16.0.893889581079.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: After pulling up to tip and sticking in the basic **kwargs change, the results on the benchmark suite imply a refleak somewhere. As soon as I sort that out I'll push up the updated patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 12 15:20:53 2014 From: report at bugs.python.org (Stefan Krah) Date: Sat, 12 Apr 2014 13:20:53 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1397308853.3.0.783641850848.issue16991@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 12 15:27:14 2014 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 12 Apr 2014 13:27:14 +0000 Subject: [issue21009] Potential deadlock in concurrent futures when garbage collection occurs during Queue.get In-Reply-To: <1395416846.85.0.759574712799.issue21009@psf.upfronthosting.co.za> Message-ID: <1397309234.23.0.0356767572958.issue21009@psf.upfronthosting.co.za> Mark Dickinson added the comment: Adding Brian Quinlan to the nosy list. I don't see an easy way around this other than documenting it and recommending that people do explicit executor shutdown where necessary. Weakref callbacks are dangerous things. Weakref callbacks that acquire a lock at any point doubly so. ---------- nosy: +bquinlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 12 15:39:45 2014 From: report at bugs.python.org (Berker Peksag) Date: Sat, 12 Apr 2014 13:39:45 +0000 Subject: [issue21204] published examples don't work In-Reply-To: <1397267440.3.0.253901505287.issue21204@psf.upfronthosting.co.za> Message-ID: <1397309985.25.0.0851101619315.issue21204@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 12 16:06:01 2014 From: report at bugs.python.org (Eric V. Smith) Date: Sat, 12 Apr 2014 14:06:01 +0000 Subject: [issue7951] Should str.format allow negative indexes when used for __getitem__ access? In-Reply-To: <1266450859.13.0.906832569526.issue7951@psf.upfronthosting.co.za> Message-ID: <1397311561.73.0.885650639119.issue7951@psf.upfronthosting.co.za> Changes by Eric V. Smith : ---------- assignee: eric.smith -> docs at python nosy: +docs at python _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 12 17:29:31 2014 From: report at bugs.python.org (koobs) Date: Sat, 12 Apr 2014 15:29:31 +0000 Subject: [issue20128] Re-enable test_modules_search_builtin() in test_pydoc In-Reply-To: <1388905827.82.0.948519018287.issue20128@psf.upfronthosting.co.za> Message-ID: <1397316571.45.0.769000315521.issue20128@psf.upfronthosting.co.za> Changes by koobs : ---------- nosy: +koobs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 12 17:31:33 2014 From: report at bugs.python.org (koobs) Date: Sat, 12 Apr 2014 15:31:33 +0000 Subject: [issue20123] pydoc.synopsis fails to load binary modules In-Reply-To: <1388874425.94.0.221860493391.issue20123@psf.upfronthosting.co.za> Message-ID: <1397316693.14.0.792515539078.issue20123@psf.upfronthosting.co.za> Changes by koobs : ---------- nosy: +koobs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 12 17:33:39 2014 From: report at bugs.python.org (Steven Hiscocks) Date: Sat, 12 Apr 2014 15:33:39 +0000 Subject: [issue21207] urandom persistent fd - not re-openned after fd close Message-ID: <1397316819.31.0.463593532744.issue21207@psf.upfronthosting.co.za> New submission from Steven Hiscocks: I've seen an issue with using urandom on Python 3.4. I've traced down to fd being closed (not by core CPython, but by third party library code). After this, access to urandom fails. I assume this is related to persistent fd for urandom in http://bugs.python.org/issue18756 $ python -c "import os;os.urandom(1);os.closerange(3,256);os.urandom(1)" Traceback (most recent call last): File "", line 1, in OSError: [Errno 9] Bad file descriptor ---------- messages: 215973 nosy: kwirk priority: normal severity: normal status: open title: urandom persistent fd - not re-openned after fd close type: crash versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 12 17:54:46 2014 From: report at bugs.python.org (Ned Deily) Date: Sat, 12 Apr 2014 15:54:46 +0000 Subject: [issue21206] Provide legit HTTPS certificate for http://bugs.python.org/, redirect HTTP to HTTPS In-Reply-To: <1397305783.0.0.175051224011.issue21206@psf.upfronthosting.co.za> Message-ID: <1397318086.78.0.979151718547.issue21206@psf.upfronthosting.co.za> Ned Deily added the comment: Please report issues with bugs.python.org to its issue tracker (Help -> Report Tracker Problem): http://psf.upfronthosting.co.za/roundup/meta/ ---------- nosy: +ned.deily resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 12 18:09:43 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 12 Apr 2014 16:09:43 +0000 Subject: [issue5845] rlcompleter should be enabled automatically In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za> Message-ID: <1397318983.54.0.984486103371.issue5845@psf.upfronthosting.co.za> R. David Murray added the comment: This issue should have gone back to being a release blocker after the alpha release to fix the tab-as-indent issue, but obviously that didn't happen (I forgot about it myself). Please open a new issue requesting a fix for?this bug (that tab doesn't work as indent at the ... prompt), referencing the discussion in this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 12 18:09:55 2014 From: report at bugs.python.org (STINNER Victor) Date: Sat, 12 Apr 2014 16:09:55 +0000 Subject: [issue21207] urandom persistent fd - not re-openned after fd close In-Reply-To: <1397316819.31.0.463593532744.issue21207@psf.upfronthosting.co.za> Message-ID: <1397318995.79.0.423363176912.issue21207@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 12 18:31:14 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 12 Apr 2014 16:31:14 +0000 Subject: [issue20010] time.strftime('%z') didn't make +HHMM return in windows xp In-Reply-To: <1387319931.23.0.412917689607.issue20010@psf.upfronthosting.co.za> Message-ID: <1397320274.94.0.732107965294.issue20010@psf.upfronthosting.co.za> R. David Murray added the comment: Can you suggest how to improve the docs? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 12 19:14:24 2014 From: report at bugs.python.org (Aaron Meurer) Date: Sat, 12 Apr 2014 17:14:24 +0000 Subject: [issue20010] time.strftime('%z') didn't make +HHMM return in windows xp In-Reply-To: <1387319931.23.0.412917689607.issue20010@psf.upfronthosting.co.za> Message-ID: <1397322864.27.0.367137367614.issue20010@psf.upfronthosting.co.za> Aaron Meurer added the comment: Nowhere at https://docs.python.org/3.5/library/time.html#time.strftime is it indicated that %z behaves differently on different platforms. What it *does* say is %z Time zone offset indicating a positive or negative time difference from UTC/GMT of the form +HHMM or -HHMM, where H represents decimal hour digits and M represents decimal minute digits [-23:59, +23:59]. I see now that this is mentioned in the footnote at the bottom of the page. I would split that footnote into two notes. It's really about two things, %Z/%z compatibility, and the RFC. The RFC note should stay as it is in the footnote, but I would move the bits about %Z/%z compatibility much close to their entries in the table, as that is where people are going to look (I personally wouldn't even hide the information in a footnote, but that can be debated). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 12 19:16:28 2014 From: report at bugs.python.org (Aaron Meurer) Date: Sat, 12 Apr 2014 17:16:28 +0000 Subject: [issue20010] time.strftime('%z') didn't make +HHMM return in windows xp In-Reply-To: <1387319931.23.0.412917689607.issue20010@psf.upfronthosting.co.za> Message-ID: <1397322988.59.0.374915017821.issue20010@psf.upfronthosting.co.za> Aaron Meurer added the comment: I also just noticed that the %z entry in the table wasn't added until the Python 3.3 docs, although it apparently works at least in OS X in Python 2.7 (I can't test Windows right now). Was it supposed to be one of the "additional directives supported on certain platforms"? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 12 20:39:36 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Sat, 12 Apr 2014 18:39:36 +0000 Subject: [issue15955] gzip, bz2, lzma: add option to limit output size In-Reply-To: <1347884562.79.0.801674791772.issue15955@psf.upfronthosting.co.za> Message-ID: <1397327976.22.0.0820466439232.issue15955@psf.upfronthosting.co.za> Changes by Nikolaus Rath : Added file: http://bugs.python.org/file34792/issue15955_r3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 12 20:51:48 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Sat, 12 Apr 2014 18:51:48 +0000 Subject: [issue20578] BufferedIOBase.readinto1 is missing In-Reply-To: <1391991229.05.0.363628736117.issue20578@psf.upfronthosting.co.za> Message-ID: <1397328708.75.0.930371119227.issue20578@psf.upfronthosting.co.za> Nikolaus Rath added the comment: Seems as if no one has an opinion on this at all: https://mail.python.org/pipermail/python-dev/2014-April/133739.html What next? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 12 21:12:26 2014 From: report at bugs.python.org (Chris Angelico) Date: Sat, 12 Apr 2014 19:12:26 +0000 Subject: [issue19414] iter(ordered_dict) yields keys not in dict in some circumstances In-Reply-To: <1382844474.66.0.775956254592.issue19414@psf.upfronthosting.co.za> Message-ID: <1397329946.61.0.319926417455.issue19414@psf.upfronthosting.co.za> Chris Angelico added the comment: I agree that current behaviour is a bit confusing; also, the implication is that deleting from the dictionary while you have an iterator may leave some hanging references around the place, which raises a red flag in my mind (maybe something else might find the stale data, too). My inclination would be to Armin's idea of setting next to None. Seems simpler than trying too hard to patch around something that's a bad idea anyway. ---------- nosy: +Rosuav _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 12 21:19:32 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 12 Apr 2014 19:19:32 +0000 Subject: [issue19414] iter(ordered_dict) yields keys not in dict in some circumstances In-Reply-To: <1382844474.66.0.775956254592.issue19414@psf.upfronthosting.co.za> Message-ID: <1397330372.29.0.754440150997.issue19414@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- nosy: +belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 12 22:47:02 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 12 Apr 2014 20:47:02 +0000 Subject: [issue21207] urandom persistent fd - not re-openned after fd close In-Reply-To: <1397316819.31.0.463593532744.issue21207@psf.upfronthosting.co.za> Message-ID: <1397335622.69.0.665806873453.issue21207@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Well, if a third-party library decides to close fds it doesn't own, that library should have a bug reported to it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 12 23:09:50 2014 From: report at bugs.python.org (Steven Hiscocks) Date: Sat, 12 Apr 2014 21:09:50 +0000 Subject: [issue21207] urandom persistent fd - not re-openned after fd close In-Reply-To: <1397316819.31.0.463593532744.issue21207@psf.upfronthosting.co.za> Message-ID: <1397336990.66.0.721286316688.issue21207@psf.upfronthosting.co.za> Steven Hiscocks added the comment: I agree in part, but it's quite common to close fd's in some cases like in a child process after using "os.fork()". There is no way, as far as I'm aware, to identify which fd is associated with /dev/urandom to keep it open; or anyway to reopen it such that other libraries which depend on it can use it (for example "tempfile.TemporaryFile"). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 12 23:09:55 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 12 Apr 2014 21:09:55 +0000 Subject: [issue21169] getpass.getpass() fails with non-ASCII characters in prompt In-Reply-To: <1396869835.69.0.462900859226.issue21169@psf.upfronthosting.co.za> Message-ID: <1397336995.51.0.90195851392.issue21169@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 12 23:58:04 2014 From: report at bugs.python.org (Karl Richter) Date: Sat, 12 Apr 2014 21:58:04 +0000 Subject: [issue21208] Change default behavior of arguments with type bool when options are specified Message-ID: <1397339884.4.0.416428545862.issue21208@psf.upfronthosting.co.za> New submission from Karl Richter: As arguments with type bool are the only ones whose values can be manipulated without passing an option to the argument on CLI, the default behavior for those should be changed from ignoring options to failing when options are specified. Consider the following example: import argparse cache_size_default=1000 cache_size_option = "c" cache_size_option_long = "cache-size" start_db_default = False start_db_option = "t" start_db_option_long = "start-db" parser = argparse.ArgumentParser(description='Process some integers.') parser.add_argument("-%s" % start_db_option, "--%s" % start_db_option_long, default=start_db_default, type=bool, nargs='?', help='@TODO', dest=start_db_option_long) parser.add_argument("-%s" % cache_size_option, "--%s" % cache_size_option_long, type=int, nargs='?', default=cache_size_default, help='size of osm2pgsql cache', dest=cache_size_option_long) def osm_postgis_transform(cache_size=cache_size_default, start_db=start_db_default): print(start_db, cache_size) if __name__ == "__main__": args = vars(parser.parse_args()) osm_postgis_transform(cache_size=args[cache_size_option_long], start_db=args[start_db_option_long]) When the script is invoked with python issue-argparse.py --start-db False --cache-size 2000 The value for start-db is True which is not really intuitive. Changing the default behavior to either fail at argument parsing or overwrite the argument value would be an improvement in my opinion. ---------- components: Library (Lib) messages: 215983 nosy: krichter priority: normal severity: normal status: open title: Change default behavior of arguments with type bool when options are specified type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 00:01:55 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 12 Apr 2014 22:01:55 +0000 Subject: [issue20578] BufferedIOBase.readinto1 is missing In-Reply-To: <1391991229.05.0.363628736117.issue20578@psf.upfronthosting.co.za> Message-ID: <1397340115.41.0.585753769933.issue20578@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I put some review into rietveld. In addition, please avoid code duplication of more than three subsequent lines of code. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 00:23:05 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 12 Apr 2014 22:23:05 +0000 Subject: [issue21057] TextIOWrapper does not support reading bytearrays or memoryviews In-Reply-To: <1395720869.89.0.455515257207.issue21057@psf.upfronthosting.co.za> Message-ID: <1397341385.77.0.444383639252.issue21057@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Nikolaus, can you please restate from scratch what the issue is? If the issue is still the one you posed in msg214776, I think the issue should be closed as "invalid" - it's *not* the case that there is no good reason for TextIOWrapper not accepting any bytes-like object. Or, to drop the double negation: as Serhiy states, read1() should return bytes, and it's perfectly fine to rely on that. Your MyByteStream ought to fail, so it is correct behaviour that it does fail. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 00:48:18 2014 From: report at bugs.python.org (Karl Richter) Date: Sat, 12 Apr 2014 22:48:18 +0000 Subject: [issue21208] Change default behavior of arguments with type bool when options are specified In-Reply-To: <1397339884.4.0.416428545862.issue21208@psf.upfronthosting.co.za> Message-ID: <1397342898.6.0.180154150998.issue21208@psf.upfronthosting.co.za> Karl Richter added the comment: I've been mistaken about the behavior if no argument is specified (then the argument value is None), so this is a bug! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 01:03:43 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Sat, 12 Apr 2014 23:03:43 +0000 Subject: [issue21057] TextIOWrapper does not support reading bytearrays or memoryviews In-Reply-To: <1395720869.89.0.455515257207.issue21057@psf.upfronthosting.co.za> Message-ID: <1397343823.85.0.872765733747.issue21057@psf.upfronthosting.co.za> Nikolaus Rath added the comment: My usecase is that I have a binary stream class that internally uses memoryviews. I would like to read text data from this stream and thus encapsulate it in a TextIOWrapper. Currently, TextIOWrapper (correctly) expects read() to return bytes and fails if it receives any other bytes-like object. I can change my custom class to internally convert to bytes, but this means that the data is needlessly copied around and affects every other consumer of the class as well. Changing TextIOWrapper to work with any bytes-like object is (as far as I can see) rather simple. It does not introduce any new branches in the code, and it does not change the behavior for bytes objects at all. It does, however, eliminate unnecessary memcopies for classes that do not internally work with bytes objects. Therefore, I was hoping this patch could be considered for inclusion. The MyByteStream example that I gave in the first message is useless. I merely included it as the smallest possible code fragment that currently does not work, but would work after the patch in an attempt to illustrate what I meant - but apparently it had the opposite effect. Thanks for considering! ---------- type: behavior -> enhancement versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 01:25:09 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Sat, 12 Apr 2014 23:25:09 +0000 Subject: [issue20578] BufferedIOBase.readinto1 is missing In-Reply-To: <1391991229.05.0.363628736117.issue20578@psf.upfronthosting.co.za> Message-ID: <1397345109.2.0.774727685808.issue20578@psf.upfronthosting.co.za> Nikolaus Rath added the comment: Thanks for the review! Attached is a new patch. I was actually pretty careful to avoid any code duplication.. are you refering to the readinto1() implementations for BytesIO and BufferedReader in Lib/_pyio.py? ---------- Added file: http://bugs.python.org/file34793/issue20578_r2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 02:23:07 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 13 Apr 2014 00:23:07 +0000 Subject: [issue20578] BufferedIOBase.readinto1 is missing In-Reply-To: <1391991229.05.0.363628736117.issue20578@psf.upfronthosting.co.za> Message-ID: <1397348587.43.0.878898747305.issue20578@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Put up a new review. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 02:34:06 2014 From: report at bugs.python.org (Josiah Carlson) Date: Sun, 13 Apr 2014 00:34:06 +0000 Subject: [issue1191964] asynchronous Subprocess Message-ID: <1397349246.3.0.127391163007.issue1191964@psf.upfronthosting.co.za> Josiah Carlson added the comment: No, the problem is that that ov.cancel() will attempt to cancel the IO, but a subsequent ov.getresult(True) doesn't always return what was *actually* written to the pipe unless you explicitly wait for the result to be available. But even if you explicitly wait for ov.pending to be False, even if you alternate between checking for ov.pending to be False and for WaitForSingleObject() to return that the event was signaled (which may never actually happen, according to my tests), ov.getresult(True) could *still* raise an exception (that same WinError 995), and we *still* don't know how much data was sent. As one of your comments on subprocess_2.patch, you said: > Should probably add an assertion that 512 bytes was written. That's not always the case. I found several odd byte writes, and some writes that were whatever blocksize I'd chosen minus 32 bytes (though not reported on the write side due to the aforementioned exception/counting error, but the child process read an odd number of bytes). How about you take a look at the patch I'm uploading now. It gets rid of the loop in write_nonblocking(), as per Giampaolo's request adds a blocksize parameter on reading, and because I was in there, I added a timeout to writing. If in this new patch I'm doing something wrong, and you can explain via code how to guarantee that ProcessTestCase._test_multiple_passes doesn't fail, I'd really appreciate it. ---------- Added file: http://bugs.python.org/file34794/subprocess_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 03:10:42 2014 From: report at bugs.python.org (Richard Kiss) Date: Sun, 13 Apr 2014 01:10:42 +0000 Subject: [issue21209] q.put(some_tuple) fails when PYTHONASYNCIODEBUG=1 Message-ID: <1397351442.01.0.248805040826.issue21209@psf.upfronthosting.co.za> New submission from Richard Kiss: import asyncio import os def t1(q): yield from asyncio.sleep(0.5) q.put_nowait((0, 1, 2, 3, 4, 5)) def t2(q): v = yield from q.get() print(v) q = asyncio.Queue() asyncio.get_event_loop().run_until_complete(asyncio.wait([t1(q), t2(q)])) When PYTHONASYNCIODEBUG is set to 1, this causes a strange error: TypeError: send() takes 2 positional arguments but 7 were given See also https://gist.github.com/richardkiss/10564363 ---------- components: Library (Lib) files: put_get_bug.py messages: 215991 nosy: richard.kiss priority: normal severity: normal status: open title: q.put(some_tuple) fails when PYTHONASYNCIODEBUG=1 type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file34795/put_get_bug.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 03:30:43 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Sun, 13 Apr 2014 01:30:43 +0000 Subject: [issue21208] Change default behavior of arguments with type bool when options are specified In-Reply-To: <1397339884.4.0.416428545862.issue21208@psf.upfronthosting.co.za> Message-ID: <1397352643.46.0.150550721388.issue21208@psf.upfronthosting.co.za> Josh Rosenberg added the comment: If your goal is to get a boolean on/off switch, that's what action='store_true' is for. You don't need to specify nargs or type at all; using bool as the type means it wants an argument, and will pass the string form of the argument to the bool constructor; since only the empty string is False, it would be quite difficult to pass it intuitively. ---------- nosy: +josh.rosenberg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 05:39:43 2014 From: report at bugs.python.org (Richard Kiss) Date: Sun, 13 Apr 2014 03:39:43 +0000 Subject: [issue21209] q.put(some_tuple) fails when PYTHONASYNCIODEBUG=1 In-Reply-To: <1397351442.01.0.248805040826.issue21209@psf.upfronthosting.co.za> Message-ID: <1397360383.2.0.717693228868.issue21209@psf.upfronthosting.co.za> Richard Kiss added the comment: For a reason that I don't understand, this patch to asyncio fixes the problem: --- a/asyncio/tasks.py Mon Mar 31 11:31:16 2014 -0700 +++ b/asyncio/tasks.py Sat Apr 12 20:37:02 2014 -0700 @@ -49,7 +49,8 @@ def __next__(self): return next(self.gen) - def send(self, value): + def send(self, value, *args): return self.gen.send(value) def throw(self, exc): Maybe the problem really is somewhere else, but this works. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 06:11:09 2014 From: report at bugs.python.org (R. David Murray) Date: Sun, 13 Apr 2014 04:11:09 +0000 Subject: [issue21204] published examples don't work In-Reply-To: <1397267440.3.0.253901505287.issue21204@psf.upfronthosting.co.za> Message-ID: <1397362269.0.0.028197556952.issue21204@psf.upfronthosting.co.za> R. David Murray added the comment: Testing the documentation examples is a long term goal, which people occasionally contribute to. I think there is an open issue about using the Sphinx doctest support, that for a long time was blocked by the documentation tool chain not using python3. Some examples are very hard to run in an automated fashion, as well. Perhaps the examples can be tweaked...but in some cases they can't, without losing their teaching value. I have a feeling the multiprocessing examples fall into this category, as I seem to remember doing a pass of testing of them a (python3) release or two ago. I did not test them on windows, though. ---------- assignee: -> docs at python components: +Documentation -Cross-Build nosy: +docs at python, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 06:15:23 2014 From: report at bugs.python.org (R. David Murray) Date: Sun, 13 Apr 2014 04:15:23 +0000 Subject: [issue21205] Unable to make decorated generator object to inherit generator function's __name__ In-Reply-To: <1397301247.66.0.634427842107.issue21205@psf.upfronthosting.co.za> Message-ID: <1397362523.41.0.201517630401.issue21205@psf.upfronthosting.co.za> R. David Murray added the comment: I think this is a specific case of a more general need to improve 'wraps' that was discussed on python-dev not too long ago. ---------- nosy: +r.david.murray versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 06:22:31 2014 From: report at bugs.python.org (R. David Murray) Date: Sun, 13 Apr 2014 04:22:31 +0000 Subject: [issue21208] Change default behavior of arguments with type bool when options are specified In-Reply-To: <1397339884.4.0.416428545862.issue21208@psf.upfronthosting.co.za> Message-ID: <1397362951.59.0.38782353997.issue21208@psf.upfronthosting.co.za> R. David Murray added the comment: Yeah, this is a bit non-obvious, but it is a specific instance of the general way that argparse handles types. So as far as I can see there really isn't anything to do here. ---------- nosy: +r.david.murray resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 08:45:24 2014 From: report at bugs.python.org (koobs) Date: Sun, 13 Apr 2014 06:45:24 +0000 Subject: [issue20123] pydoc.synopsis fails to load binary modules In-Reply-To: <1388874425.94.0.221860493391.issue20123@psf.upfronthosting.co.za> Message-ID: <1397371524.35.0.266294135102.issue20123@psf.upfronthosting.co.za> koobs added the comment: koobs-freebsd9 (3.4) buildbot has also been failing for a while on what seems to be this changeset: ====================================================================== ERROR: test_synopsis_sourceless (test.test_pydoc.PydocDocTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/home/buildbot/python/3.4.koobs-freebsd9/build/Lib/test/test_pydoc.py", line 504, in test_synopsis_sourceless synopsis = pydoc.synopsis(filename) File "/usr/home/buildbot/python/3.4.koobs-freebsd9/build/Lib/pydoc.py", line 238, in synopsis mtime = os.stat(filename).st_mtime FileNotFoundError: [Errno 2] No such file or directory: '/usr/home/buildbot/python/3.4.koobs-freebsd9/build/Lib/__pycache__/os.cpython-34.pyc' Full buildlog is attached. ---------- Added file: http://bugs.python.org/file34796/koobs-freebsd9-3.4-build57.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 08:48:33 2014 From: report at bugs.python.org (koobs) Date: Sun, 13 Apr 2014 06:48:33 +0000 Subject: [issue20128] Re-enable test_modules_search_builtin() in test_pydoc In-Reply-To: <1388905827.82.0.948519018287.issue20128@psf.upfronthosting.co.za> Message-ID: <1397371713.44.0.99232851353.issue20128@psf.upfronthosting.co.za> koobs added the comment: test_synopsis_sourceless is also failing on koobs-freebsd9 (3.4) and has been for a while. Failing test inlined here, for full buildlog, see msg215997 in #20123 ====================================================================== ERROR: test_synopsis_sourceless (test.test_pydoc.PydocDocTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/home/buildbot/python/3.4.koobs-freebsd9/build/Lib/test/test_pydoc.py", line 504, in test_synopsis_sourceless synopsis = pydoc.synopsis(filename) File "/usr/home/buildbot/python/3.4.koobs-freebsd9/build/Lib/pydoc.py", line 238, in synopsis mtime = os.stat(filename).st_mtime FileNotFoundError: [Errno 2] No such file or directory: '/usr/home/buildbot/python/3.4.koobs-freebsd9/build/Lib/__pycache__/os.cpython-34.pyc' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 09:15:40 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 13 Apr 2014 07:15:40 +0000 Subject: [issue21204] published examples don't work In-Reply-To: <1397267440.3.0.253901505287.issue21204@psf.upfronthosting.co.za> Message-ID: <1397373340.91.0.910922785081.issue21204@psf.upfronthosting.co.za> Martin v. L?wis added the comment: jmaki: not sure what the issue is that you are reporting. I can see three different possible issues. 1. "Would you consider putting examples...". As R. David said: yes, we consider it. If you really wanted to know whether we consider it, we could close the issue as fixed. 2. "Please make examples ...". This would be a (near) duplicate of #15939, so I should close this issue as a duplicate. 3. "The specific example does not work on Windows". This issue should stay open until it is analysed an possibly fixed. If that is the issue, then it would be helpful if you could report how exactly the example fails. I'd like to see a strict "one issue at a time" policy in this tracker, so please let us know how you would like us to proceed. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 10:38:39 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 13 Apr 2014 08:38:39 +0000 Subject: [issue21158] Windows installer service could not be accessed (Python bug!) In-Reply-To: <1396639122.72.0.136527705506.issue21158@psf.upfronthosting.co.za> Message-ID: <1397378319.91.0.426402891398.issue21158@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Payden Comer, please run msiexec /i /l*v python.log in a terminal window, and attach the resulting python.log here. R. David: Feel free to copy these instructions; they can be standard in all cases of "the installer does not work". As for the actual report: The first issue (python bug.PNG) has a clear explanation: Windows installer does not support simultaneous installation of two MSI files. So while ffmpeg (or whatever the scratched-out name is) is being installed, it refuses to start the Python installation. As for the second problem: Other software authors have put texts on the net on potential causes for this problem. I think going through http://support.affixa.com/kb/236 could be helpful. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 10:39:48 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 13 Apr 2014 08:39:48 +0000 Subject: [issue21158] Windows installer service could not be accessed In-Reply-To: <1396639122.72.0.136527705506.issue21158@psf.upfronthosting.co.za> Message-ID: <1397378388.08.0.727671501117.issue21158@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- title: Windows installer service could not be accessed (Python bug!) -> Windows installer service could not be accessed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 10:50:51 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 13 Apr 2014 08:50:51 +0000 Subject: [issue21202] Naming a file` io.py` causes cryptic error message In-Reply-To: <1397239551.94.0.578791540537.issue21202@psf.upfronthosting.co.za> Message-ID: <1397379051.13.0.493358577177.issue21202@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I think the AttributeError message should improve, and special-case certain common types, in particular modules. E.g. it could read AttributeError: module 'io' has no attribute 'BufferedIOBase' or even AttributeError: has no attribute 'BufferedIOBase' IIUC, the first version would already have helped the OP, and the second version would have been dead-clear (except that it is a little verbose). ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 10:51:20 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 13 Apr 2014 08:51:20 +0000 Subject: [issue21169] getpass.getpass() fails with non-ASCII characters in prompt In-Reply-To: <1396869835.69.0.462900859226.issue21169@psf.upfronthosting.co.za> Message-ID: <1397379080.16.0.741803330464.issue21169@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I don't think this is a bug. Any text output operation can fail when outputs unencodable string. You should use a stream with proper encoding and/or error handler. ---------- nosy: +serhiy.storchaka resolution: -> invalid stage: needs patch -> committed/rejected status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 11:00:36 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 13 Apr 2014 09:00:36 +0000 Subject: [issue21188] Broken link In-Reply-To: <1397050895.39.0.221241316975.issue21188@psf.upfronthosting.co.za> Message-ID: <1397379636.34.0.351216281971.issue21188@psf.upfronthosting.co.za> Martin v. L?wis added the comment: LtWorf: What copy of the file are you looking at? In http://hg.python.org/cpython/file/84bc6998f760/Modules/gcmodule.c I see different links, and the all work fine. They were changed in http://hg.python.org/cpython/diff/d040a3b63df4/Modules/gcmodule.c Closing the issue as fixed. ---------- nosy: +loewis resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 11:03:11 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 13 Apr 2014 09:03:11 +0000 Subject: [issue17861] put opcode information in one place In-Reply-To: <1367162089.6.0.986391601417.issue17861@psf.upfronthosting.co.za> Message-ID: <1397379791.39.0.555441671972.issue17861@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Please add the file to .hgtouch as well, and verify that "make touch" works correctly. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 11:07:38 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 13 Apr 2014 09:07:38 +0000 Subject: [issue9066] Standard type codes for array.array, same as struct In-Reply-To: <1277355510.37.0.62223618655.issue9066@psf.upfronthosting.co.za> Message-ID: <1397380058.75.0.48715949125.issue9066@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka versions: +Python 3.5 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 11:07:53 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 13 Apr 2014 09:07:53 +0000 Subject: [issue17345] Portable and extended type specifiers for array module In-Reply-To: <1362385577.82.0.862277690656.issue17345@psf.upfronthosting.co.za> Message-ID: <1397380073.58.0.349072980441.issue17345@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 11:10:04 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 13 Apr 2014 09:10:04 +0000 Subject: [issue21171] Outdated usage str.encode('rot-13') in rot13 codec In-Reply-To: <1396887951.87.0.0918755245814.issue21171@psf.upfronthosting.co.za> Message-ID: <1397380204.84.0.463042000819.issue21171@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 11:14:29 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 13 Apr 2014 09:14:29 +0000 Subject: [issue21169] getpass.getpass() fails with non-ASCII characters in prompt In-Reply-To: <1396869835.69.0.462900859226.issue21169@psf.upfronthosting.co.za> Message-ID: <1397380468.99.0.347894728901.issue21169@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I agree that it is not a bug if the device where the prompt is shown simply does not support the characters; on Unix, this includes cases where the locale does not support the characters. Arfrever: when you say that it fails in Python 3 in a non-UTF-8 locale, which specific locale was that that it failed in? ---------- nosy: +loewis status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 11:27:21 2014 From: report at bugs.python.org (Eduardo Robles Elvira) Date: Sun, 13 Apr 2014 09:27:21 +0000 Subject: [issue18321] Multivolume support in tarfile module In-Reply-To: <1372406777.07.0.523288075904.issue18321@psf.upfronthosting.co.za> Message-ID: <1397381241.16.0.496692025901.issue18321@psf.upfronthosting.co.za> Eduardo Robles Elvira added the comment: > The example I gave is based on the idea that there is a TarVolumeSet class in the tarfile module that implements all the required file-object methods (e.g. read(), write(), seek(), etc.) and acts as if the sequence of volumes is actually one big file. It is passed to tarfile.open() as the fileobj argument. This TarVolumeSet class is supposed to be subclassable to let the user implement her/his own mode of operation. This way the open_volume() method can do whatever the user wants it to do. The TarVolumeSet class might as well have a new_volume() method for writing multivol archives, the example only covered the case of reading a multivol archive. This is not so easy, because for example if you want to move the logic in addfile() that manages volumes to the write() function, you have some issues: * write() will need to take into account blocks (BLOCKSIZE), just to be able to split the volumes correctly. This is something that usually shouldn't belong in a write() function as it has to do to tarfile.. and it can be messy that both layers deal with it (write() splitting volumes, and tarfile adding NUL at the end of a BLOCK..) This can be done I guess, but remember, we split a volume only in the middle of a big file, not in any other case (AFAIK). Hopefully you don't get huge pax headers or anything strange. Usually all other records are either in the begining or just occupy one block, but can we rule this problem out for good? * multivolume logic in write() needs read/write access to the current tarinfo being written (look for "tarfile" in addfile() funcion in my patch to see why). How do you propose this object should be accessed from write()? > BTW, my version of GNU tar refuses to create compressed multiple-volume archives which is why I doubt the usefulness of this feature overall. But it has multivolume support right? Which is what I am proposing here. Also, you can gzip (or encrypt or anything) the volumes after creating the volumes.. >> [...] because a multivol tarfile is not exactly the same as a normal tarfile chopped up. > No, I think it is exactly that. The only purpose of the GNUTYPE_MULTIVOL header that is at the start of each subsequent volume is to give GNU tar the ability to detect if it is reading the correct volume. It is not essential and could as well be left out. I'm not going to discuss this, because I think that we can implement it in the way you propose to implement it anyway. But my patch supports it and I think it's an *useful* feature, so I want it in :-P ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 11:37:36 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 13 Apr 2014 09:37:36 +0000 Subject: [issue21199] Python on 64-bit Windows uses signed 32-bit type for read length In-Reply-To: <1397149133.44.0.946556558932.issue21199@psf.upfronthosting.co.za> Message-ID: <1397381856.7.0.816208041683.issue21199@psf.upfronthosting.co.za> Martin v. L?wis added the comment: FWIW, using "l" for file_read goes back to http://hg.python.org/cpython/diff/f44a56e697fb/Objects/fileobject.c from Fri, 09 May 1997 22:27:31 +0000 ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 12:10:10 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 13 Apr 2014 10:10:10 +0000 Subject: [issue21169] getpass.getpass() fails with non-ASCII characters in prompt In-Reply-To: <1396869835.69.0.462900859226.issue21169@psf.upfronthosting.co.za> Message-ID: <1397383810.31.0.556966037758.issue21169@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: $ LC_ALL=en_US.iso88591 ./python -c "print('\u20ac')" Traceback (most recent call last): File "", line 1, in UnicodeEncodeError: 'latin-1' codec can't encode character '\u20ac' in position 0: ordinal not in range(256) $ LC_ALL=en_US.iso88591 ./python -c "input('\u20ac')" Traceback (most recent call last): File "", line 1, in UnicodeEncodeError: 'latin-1' codec can't encode character '\u20ac' in position 0: ordinal not in range(256) $ LC_ALL=en_US.iso88591 ./python -c "import getpass; getpass.getpass('\u20ac')" Traceback (most recent call last): File "", line 1, in File "/home/serhiy/py/cpython/Lib/getpass.py", line 78, in unix_getpass passwd = _raw_input(prompt, stream, input=input) File "/home/serhiy/py/cpython/Lib/getpass.py", line 138, in _raw_input stream.write(prompt) UnicodeEncodeError: 'latin-1' codec can't encode character '\u20ac' in position 0: ordinal not in range(256) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 12:19:01 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 13 Apr 2014 10:19:01 +0000 Subject: [issue20701] warning in compileall.rst In-Reply-To: <1392912685.12.0.93082248857.issue20701@psf.upfronthosting.co.za> Message-ID: <1397384341.11.0.258222938774.issue20701@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: It seems to have been fixed by: New changeset f8dbec87dbfe by Georg Brandl in branch '3.4': Fix option description that is a warning in new Sphinx versions. http://hg.python.org/cpython/rev/f8dbec87dbfe ---------- nosy: +Arfrever resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 12:19:13 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 13 Apr 2014 10:19:13 +0000 Subject: [issue20702] warning in cmdline.rst In-Reply-To: <1392912711.56.0.068160127769.issue20702@psf.upfronthosting.co.za> Message-ID: <1397384353.9.0.491916151639.issue20702@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: I cannot reproduce it with Sphinx 1.2.2. Can you still reproduce it? Which version of Sphinx? ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 12:19:27 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 13 Apr 2014 10:19:27 +0000 Subject: [issue21210] Warnings in Doc/library/json.rst Message-ID: <1397384367.1.0.38760092166.issue21210@psf.upfronthosting.co.za> New submission from Arfrever Frehtes Taifersar Arahesis: Warnings during building of documentation (with Sphinx 1.2.2): ${cpython_working_copy}/Doc/library/json.rst:593: WARNING: Malformed option description '[]', should look like "opt", "-opt args", "--opt args" or "/opt args" ${cpython_working_copy}/Doc/library/json.rst:609: WARNING: Malformed option description '[]', should look like "opt", "-opt args", "--opt args" or "/opt args" Probably introduced by: New changeset a2ad16e86e60 by Benjamin Peterson in branch 'default': improve the command-line interface of json.tool (closes #21000) http://hg.python.org/cpython/rev/a2ad16e86e60 ---------- assignee: docs at python components: Documentation messages: 216012 nosy: Arfrever, benjamin.peterson, berker.peksag, docs at python priority: normal severity: normal status: open title: Warnings in Doc/library/json.rst versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 12:42:24 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 13 Apr 2014 10:42:24 +0000 Subject: [issue21169] getpass.getpass() fails with non-ASCII characters in prompt In-Reply-To: <1396869835.69.0.462900859226.issue21169@psf.upfronthosting.co.za> Message-ID: <1397385744.89.0.970375098937.issue21169@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: Martin v. L?wis: In this case, device support non-ASCII characters, but Python's getpass module forgets to properly encode string. Message 215697 contains example with C locale. ---------- resolution: invalid -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 12:43:18 2014 From: report at bugs.python.org (Berker Peksag) Date: Sun, 13 Apr 2014 10:43:18 +0000 Subject: [issue21210] Warnings in Doc/library/json.rst In-Reply-To: <1397384367.1.0.38760092166.issue21210@psf.upfronthosting.co.za> Message-ID: <1397385798.64.0.392426531947.issue21210@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the report Arfrever. Here's a patch to silence the warnings. ---------- keywords: +patch Added file: http://bugs.python.org/file34797/issue21210.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 14:11:17 2014 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Sun, 13 Apr 2014 12:11:17 +0000 Subject: [issue18321] Multivolume support in tarfile module In-Reply-To: <1372406777.07.0.523288075904.issue18321@psf.upfronthosting.co.za> Message-ID: <1397391077.8.0.899139169781.issue18321@psf.upfronthosting.co.za> Lars Gust?bel added the comment: > [...] but remember, we split a volume only in the middle of a big file, not in any other case (AFAIK). Hopefully you don't get huge pax headers or anything strange. [...] Hopefully? Sorry, but have you tested this? I did. I let GNU tar create a two volume archive that is split exactly between the two blocks of an XHDTYPE pax header. The result is terrifying. At the beginning of the second volume GNU tar creates an XGLTYPE header as the pax replacement for a GNUTYPE_MULTIVOL header, followed by an XHDTYPE header ("GNUFileParts") that somehow decorates the following REGTYPE(!) tar header that contains the continuation of the split XHDTYPE header data from the previous volume. After that comes the REGTYPE file that the split XHDTYPE header was actually meant for as decoration. I attached the archive to this issue. What happens if a GNUTYPE_LONGNAME header is split in two? I don't wanna know... > write() will need to take into account blocks (BLOCKSIZE), just to be able to split the volumes correctly. It is mandatory to do the split on a block boundary (a multiple of 512). > * multivolume logic in write() needs read/write access to the current tarinfo being written [...]. How do you propose this object should be accessed from write()? I don't know and this problem seems to be quite hard to address with my approach. That's too bad. > > BTW, my version of GNU tar refuses to create compressed multiple-volume archives which is why I doubt the usefulness of this feature overall. > But it has multivolume support right? Which is what I am proposing here. Also, you can gzip (or encrypt or anything) the volumes after creating the volumes.. Yeah, it has multivolume support, but a very limited one that is not only weird but isn't even usable together with compression. And sure, I can compress and encrypt the volumes afterwards, but I can also create a compressed archive and pipe it through split(1) to split it into parts. Both ways create tar archives that are not readable by GNU tar because they're non-standard. So what? Please tell me, what is your actual personal use-case for this feature? ---------- Added file: http://bugs.python.org/file34798/split-xhdtype.tar.gz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 15:51:22 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Sun, 13 Apr 2014 13:51:22 +0000 Subject: [issue21199] Python on 64-bit Windows uses signed 32-bit type for read length In-Reply-To: <1397149133.44.0.946556558932.issue21199@psf.upfronthosting.co.za> Message-ID: <1397397082.87.0.74194474951.issue21199@psf.upfronthosting.co.za> Josh Rosenberg added the comment: So it predates the existence of type code 'n', which would be the appropriate type code, but no one updated it. Antoine: Inability to perform a 2GB+ read properly is not something that should be worked around on a case by case basis. There is one compatibility risk here, which is that 'n' requires index integers (__index__), where 'l' will accept coercible types (__int__). If you think people are reading from files using Fraction and Decimal, then this would be a compatibility issue (and you could work around it be making it use type code 'L' only on 64 bit Windows), but this just looks like an oversight from the upgrade from int to Py_ssize_t across the Python code base. ---------- nosy: +josh.rosenberg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 16:09:05 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 13 Apr 2014 14:09:05 +0000 Subject: [issue21171] Outdated usage str.encode('rot-13') in rot13 codec In-Reply-To: <1396887951.87.0.0918755245814.issue21171@psf.upfronthosting.co.za> Message-ID: <3g6FFC6kr1zLq6@mail.python.org> Roundup Robot added the comment: New changeset a81f0caab279 by Serhiy Storchaka in branch '3.4': Issue #21171: Fixed undocumented filter API of the rot13 codec. http://hg.python.org/cpython/rev/a81f0caab279 New changeset f86504da2fcc by Serhiy Storchaka in branch 'default': Issue #21171: Fixed undocumented filter API of the rot13 codec. http://hg.python.org/cpython/rev/f86504da2fcc ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 17:19:09 2014 From: report at bugs.python.org (Paul Sokolovsky) Date: Sun, 13 Apr 2014 15:19:09 +0000 Subject: [issue21180] Cannot efficiently create empty array.array of given size, inconsistency with bytearray In-Reply-To: <1396963926.18.0.0845457465299.issue21180@psf.upfronthosting.co.za> Message-ID: <1397402349.42.0.233488933208.issue21180@psf.upfronthosting.co.za> Paul Sokolovsky added the comment: > >>> array.array('i', [0]) * 3 @Serhiy Storchaka: The keyword is "efficiently". Let's analyze: this creates useless array.array('i', [0]) object destined only for garbage collection. Then, it forces using loop of loops to fill in a new object. Whereas array.array('i', 3) immediately reduces to a memset(). You can say that these implementation efficiency issues are of little concert to CPython. But what's being reported here is that, while generally Python is pretty good in allowing to efficiently process raw binary data (memoryview and all other bits and pieces), there are inconsistent accidental gaps in API here and there which jeopardize efficiency, in obvious way (and also obvious to resolve), what may be of concern for other Python implementations (my case). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 17:25:19 2014 From: report at bugs.python.org (Ned Deily) Date: Sun, 13 Apr 2014 15:25:19 +0000 Subject: [issue21209] q.put(some_tuple) fails when PYTHONASYNCIODEBUG=1 In-Reply-To: <1397351442.01.0.248805040826.issue21209@psf.upfronthosting.co.za> Message-ID: <1397402719.36.0.793341193272.issue21209@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +giampaolo.rodola, gvanrossum, haypo, pitrou, yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 17:28:32 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 13 Apr 2014 15:28:32 +0000 Subject: [issue20998] fullmatch isn't matching correctly under re.IGNORECASE In-Reply-To: <1396637374.23.0.844365787024.issue20998@psf.upfronthosting.co.za> Message-ID: <3748591.jtbvfHa361@raxxla> Serhiy Storchaka added the comment: > After stepping through the code for that regex that fails, I concluded > that the condition shouldn't depend on ctx->match_all at that point > after all. Tests are passed without this check. But I'm not sure it is not needed. At least without this check the code is not equivalent to the code before adding support for fullmatch(). So I prefer to left it as is. > I thought I'd initialised it in all the places it's used. > > I admit that I find the code a little hard to follow at times... :-( Indeed, it is initialized in Modules/_sre.c, and it is always 0. Perhaps it will be more consistent to get rid of the match_all field in the SRE_STATE structure and pass it as argument. ---------- Added file: http://bugs.python.org/file34799/issue20998_2.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r f86504da2fcc Lib/test/test_re.py --- a/Lib/test/test_re.py Sun Apr 13 17:08:51 2014 +0300 +++ b/Lib/test/test_re.py Sun Apr 13 18:23:53 2014 +0300 @@ -1223,6 +1223,11 @@ pat.scanner(string='abracadabra', pos=3, endpos=10).search().span(), (7, 9)) + def test_bug_20998(self): + # Issue #20998: Fullmatch of repeated single character pattern + # with ignore case. + self.assertEqual(re.fullmatch('[a-c]+', 'ABC', re.I).span(), (0, 3)) + class PatternReprTests(unittest.TestCase): def check(self, pattern, expected): diff -r f86504da2fcc Modules/_sre.c --- a/Modules/_sre.c Sun Apr 13 17:08:51 2014 +0300 +++ b/Modules/_sre.c Sun Apr 13 18:23:53 2014 +0300 @@ -505,14 +505,14 @@ } LOCAL(Py_ssize_t) -sre_match(SRE_STATE* state, SRE_CODE* pattern) +sre_match(SRE_STATE* state, SRE_CODE* pattern, int match_all) { if (state->charsize == 1) - return sre_ucs1_match(state, pattern); + return sre_ucs1_match(state, pattern, match_all); if (state->charsize == 2) - return sre_ucs2_match(state, pattern); + return sre_ucs2_match(state, pattern, match_all); assert(state->charsize == 4); - return sre_ucs4_match(state, pattern); + return sre_ucs4_match(state, pattern, match_all); } LOCAL(Py_ssize_t) @@ -576,7 +576,7 @@ TRACE(("|%p|%p|MATCH\n", PatternObject_GetCode(self), state.ptr)); - status = sre_match(&state, PatternObject_GetCode(self)); + status = sre_match(&state, PatternObject_GetCode(self), 0); TRACE(("|%p|%p|END\n", PatternObject_GetCode(self), state.ptr)); if (PyErr_Occurred()) @@ -609,12 +609,11 @@ if (!string) return NULL; - state.match_all = 1; state.ptr = state.start; TRACE(("|%p|%p|FULLMATCH\n", PatternObject_GetCode(self), state.ptr)); - status = sre_match(&state, PatternObject_GetCode(self)); + status = sre_match(&state, PatternObject_GetCode(self), 1); TRACE(("|%p|%p|END\n", PatternObject_GetCode(self), state.ptr)); if (PyErr_Occurred()) @@ -2572,7 +2571,7 @@ state->ptr = state->start; - status = sre_match(state, PatternObject_GetCode(self->pattern)); + status = sre_match(state, PatternObject_GetCode(self->pattern), 0); if (PyErr_Occurred()) return NULL; diff -r f86504da2fcc Modules/sre.h --- a/Modules/sre.h Sun Apr 13 17:08:51 2014 +0300 +++ b/Modules/sre.h Sun Apr 13 18:23:53 2014 +0300 @@ -86,7 +86,6 @@ SRE_REPEAT *repeat; /* hooks */ SRE_TOLOWER_HOOK lower; - int match_all; } SRE_STATE; typedef struct { diff -r f86504da2fcc Modules/sre_lib.h --- a/Modules/sre_lib.h Sun Apr 13 17:08:51 2014 +0300 +++ b/Modules/sre_lib.h Sun Apr 13 18:23:53 2014 +0300 @@ -173,7 +173,7 @@ } } -LOCAL(Py_ssize_t) SRE(match)(SRE_STATE* state, SRE_CODE* pattern); +LOCAL(Py_ssize_t) SRE(match)(SRE_STATE* state, SRE_CODE* pattern, int match_all); LOCAL(Py_ssize_t) SRE(count)(SRE_STATE* state, SRE_CODE* pattern, Py_ssize_t maxcount) @@ -259,7 +259,7 @@ /* repeated single character pattern */ TRACE(("|%p|%p|COUNT SUBPATTERN\n", pattern, ptr)); while ((SRE_CHAR*) state->ptr < end) { - i = SRE(match)(state, pattern); + i = SRE(match)(state, pattern, 0); if (i < 0) return i; if (!i) @@ -490,7 +490,7 @@ /* check if string matches the given pattern. returns <0 for error, 0 for failure, and 1 for success */ LOCAL(Py_ssize_t) -SRE(match)(SRE_STATE* state, SRE_CODE* pattern) +SRE(match)(SRE_STATE* state, SRE_CODE* pattern, int match_all) { SRE_CHAR* end = (SRE_CHAR *)state->end; Py_ssize_t alloc_pos, ctx_pos = -1; @@ -507,7 +507,7 @@ ctx->last_ctx_pos = -1; ctx->jump = JUMP_NONE; ctx->pattern = pattern; - ctx->match_all = state->match_all; + ctx->match_all = match_all; ctx_pos = alloc_pos; entrance: @@ -824,7 +824,7 @@ } if (ctx->pattern[ctx->pattern[0]] == SRE_OP_SUCCESS && - (!ctx->match_all || ctx->ptr == state->end)) { + (!match_all || ctx->ptr == state->end)) { /* tail is empty. we're finished */ state->ptr = ctx->ptr; RETURN_SUCCESS; @@ -1269,7 +1269,7 @@ state->ptr = ptr - (prefix_len - prefix_skip - 1); if (flags & SRE_INFO_LITERAL) return 1; /* we got all of it */ - status = SRE(match)(state, pattern + 2*prefix_skip); + status = SRE(match)(state, pattern + 2*prefix_skip, 0); if (status != 0) return status; /* close but no cigar -- try again */ @@ -1302,7 +1302,7 @@ state->ptr = ++ptr; if (flags & SRE_INFO_LITERAL) return 1; /* we got all of it */ - status = SRE(match)(state, pattern + 2); + status = SRE(match)(state, pattern + 2, 0); if (status != 0) break; } @@ -1317,7 +1317,7 @@ TRACE(("|%p|%p|SEARCH CHARSET\n", pattern, ptr)); state->start = ptr; state->ptr = ptr; - status = SRE(match)(state, pattern); + status = SRE(match)(state, pattern, 0); if (status != 0) break; ptr++; @@ -1327,7 +1327,7 @@ while (ptr <= end) { TRACE(("|%p|%p|SEARCH\n", pattern, ptr)); state->start = state->ptr = ptr++; - status = SRE(match)(state, pattern); + status = SRE(match)(state, pattern, 0); if (status != 0) break; } From report at bugs.python.org Sun Apr 13 17:29:57 2014 From: report at bugs.python.org (Paul Sokolovsky) Date: Sun, 13 Apr 2014 15:29:57 +0000 Subject: [issue21180] Cannot efficiently create empty array.array of given size, inconsistency with bytearray In-Reply-To: <1396963926.18.0.0845457465299.issue21180@psf.upfronthosting.co.za> Message-ID: <1397402997.32.0.170811698578.issue21180@psf.upfronthosting.co.za> Paul Sokolovsky added the comment: @Terry J. Reedy: Thanks for the pointer. My inital response is , another bloating of namespace. But I'm adjusting. But that PEP shows the issue with all that activity: CPython stdlib got so big and bloated, that it lives its own life and people consider it normal. So, there're PEPs to perfectalize bytearray, without paying attention to the fact that array.array('B') is pretty much the same thing, but apirots (cf. bitrot) behind it. So, following PEP467, this request should be updated to call for array.array.zero(typecode, size) factory method. Note that it would need to take 2 arguments to follow array.array API. Is that good or bad? IMHO, not much worse than introducing separate factory method at all. But again, author of PEP467 should rather consider how those proposals extend to other related types. If you participate in the discussion of the PEP, I'd appreciate if shared there link to this ticket - I'm not in loop of general CPython development and have limited resources to learn/follow them. Thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 17:38:49 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 13 Apr 2014 15:38:49 +0000 Subject: [issue21180] Cannot efficiently create empty array.array of given size, inconsistency with bytearray In-Reply-To: <1396963926.18.0.0845457465299.issue21180@psf.upfronthosting.co.za> Message-ID: <1397403529.49.0.0647219024657.issue21180@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Paul: Discussion of the PEP is out of the scope of this issue. The primary point of the PEP process is that it steers discussion. So if you object to the PEP, contact the PEP author and ask for your objection to be considered, and if not that, at least be recorded. I feel that your proposed change is highly confusing. People might expect that array.array('i', 3) creates an array with the single value 3 (just as they factually do expect that for bytes). Keyword-only parameters might clear that ambiguity, e.g. array.array('i', len=3) array.array(type='i', len=3, value=0) In any case, it is unlikely that anything will be done with this issue unless you provide a patch (and that still would be no guarantee that somebody accepts it). ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 17:50:27 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 13 Apr 2014 15:50:27 +0000 Subject: [issue20998] fullmatch isn't matching correctly under re.IGNORECASE In-Reply-To: <1395340840.43.0.0546340493094.issue20998@psf.upfronthosting.co.za> Message-ID: <1397404227.49.0.656768510513.issue20998@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Gareth, this is unrelated issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 17:53:49 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 13 Apr 2014 15:53:49 +0000 Subject: [issue21199] Python on 64-bit Windows uses signed 32-bit type for read length In-Reply-To: <1397149133.44.0.946556558932.issue21199@psf.upfronthosting.co.za> Message-ID: <1397404429.12.0.0328405224158.issue21199@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Josh: it's not as simple as just changing the type code and variable type. Systems used to require all kinds of types in the length parameter of read(2) and fread(3), including int, long, and size_t. If it was int, passing size_t would lead to silent truncation. So at a minimum, a careful review of the further processing, and a test case is necessary. I'm personally not interested in Python 2.7 anymore, so I certainly won't work on this. As for why this isn't reported frequently, I guess a number of causes: a) people don't use Python on Windows that much to process large files b) when they do and run into this problem, they feel guilty for actually asking for a such large chunk, which could well exhaust the memory of the system. c) there is a straight-forward work-around d) people that do read large files typically either read them at once, or in much smaller chunks So it may well be that this remains the only report of this for the rest of Python 2.7's life. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 18:08:58 2014 From: report at bugs.python.org (Quentin Pradet) Date: Sun, 13 Apr 2014 16:08:58 +0000 Subject: [issue18983] Specify time unit for timeit CLI In-Reply-To: <1378674956.86.0.740860392271.issue18983@psf.upfronthosting.co.za> Message-ID: <1397405338.02.0.759987431802.issue18983@psf.upfronthosting.co.za> Quentin Pradet added the comment: The branch appears to exist now. ---------- nosy: +Quentin.Pradet _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 18:17:33 2014 From: report at bugs.python.org (Paul Sokolovsky) Date: Sun, 13 Apr 2014 16:17:33 +0000 Subject: [issue21180] Cannot efficiently create empty array.array of given size, inconsistency with bytearray In-Reply-To: <1396963926.18.0.0845457465299.issue21180@psf.upfronthosting.co.za> Message-ID: <1397405853.13.0.255634659317.issue21180@psf.upfronthosting.co.za> Paul Sokolovsky added the comment: Martin: > People might expect that array.array('i', 3) creates an array with the single value 3. I don't know which people would expect that. Personally I recognize the need to create an empty array of of given size, and have read the docs for builtin "bytearray" type, and expect extension type array.array to work the same. I'd even say that I found any other expectations ungrounded, in particular, a way to create an array of single int is obviously bytearray([3]) or array.array('i', [3]). Anyway, as I say in "2014-04-13 15:29" comment, I'm only glad to follow with PEP467 changes. Unfortunately, I don't seem to be able to update initial ticket description with updated proposal. > array.array('i', len=3) The whole scope of this ticket is to have consistent API between bytearray and array.array. So, the only way I could suggest (or back) the above is if PEP467 was changed too, and as you suggest, I don't do that. (I personally also dislike overuse of keyword args.) > In any case, it is unlikely that anything will be done with this issue unless you provide a patch (and that still would be no guarantee that somebody accepts it). The ending is the saddest. As I mentioned, the best outcome I could imagine of such reports is that people who consider changing builtin types to also consider obvious stdlib counterparts too. (There's another issue - stdlib is indeed enormous, so it would be nice to separate it (speculatively) into ["builtin types/lib"], "core stdlib", and "extended stdlib". There's clear difference between array module and for example unittest or logging. Thanks for hint re: mailing Nick Coghlan - nice to know that's acceptable, that's certainly easier than figuring out which mailing list to use and then to follow it. (I see that Nick is in noselist of this ticket, but I guess I'll mail him anyway to have my conscience clear that I did everything to make Python better (== more consistent)). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 18:43:45 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 13 Apr 2014 16:43:45 +0000 Subject: [issue21199] Python on 64-bit Windows uses signed 32-bit type for read length In-Reply-To: <1397149133.44.0.946556558932.issue21199@psf.upfronthosting.co.za> Message-ID: <1397407425.3.0.630526037792.issue21199@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Antoine: Inability to perform a 2GB+ read properly is not something > that should be worked around on a case by case basis. Really we are talking about Python 2.7 here. Anyone having this problem *has* to work it around in order for their code to work on published versions. The benefit of fixing this in the next 2.7.x iteration is small compared to the cost of a potential regression in the core I/O implementation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 18:55:27 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 13 Apr 2014 16:55:27 +0000 Subject: [issue20635] Fix the grid geometry manager and add tests for geometry managers In-Reply-To: <1392464302.58.0.168858938069.issue20635@psf.upfronthosting.co.za> Message-ID: <3g6Jx96Vhbz7LjY@mail.python.org> Roundup Robot added the comment: New changeset e8c184d8407d by Serhiy Storchaka in branch '3.4': Issue #20635: Added tests for Tk geometry managers. http://hg.python.org/cpython/rev/e8c184d8407d New changeset e8acef4f8567 by Serhiy Storchaka in branch 'default': Issue #20635: Added tests for Tk geometry managers. http://hg.python.org/cpython/rev/e8acef4f8567 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 19:06:45 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 13 Apr 2014 17:06:45 +0000 Subject: [issue20635] Fix the grid geometry manager and add tests for geometry managers In-Reply-To: <1392464302.58.0.168858938069.issue20635@psf.upfronthosting.co.za> Message-ID: <1397408805.06.0.562736877323.issue20635@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch for 2.7. ---------- Added file: http://bugs.python.org/file34800/test_geometry_managers_2-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 19:57:00 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 13 Apr 2014 17:57:00 +0000 Subject: [issue20635] Fix the grid geometry manager and add tests for geometry managers In-Reply-To: <1392464302.58.0.168858938069.issue20635@psf.upfronthosting.co.za> Message-ID: <1397411820.65.0.216469685191.issue20635@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 19:57:17 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 13 Apr 2014 17:57:17 +0000 Subject: [issue20998] fullmatch isn't matching correctly under re.IGNORECASE In-Reply-To: <1395340840.43.0.0546340493094.issue20998@psf.upfronthosting.co.za> Message-ID: <1397411837.04.0.673189584805.issue20998@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 20:03:11 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 13 Apr 2014 18:03:11 +0000 Subject: [issue20636] Better repr for tkinter widgets In-Reply-To: <1392465181.79.0.530455860021.issue20636@psf.upfronthosting.co.za> Message-ID: <1397412191.18.0.72657035328.issue20636@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 20:58:02 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 13 Apr 2014 18:58:02 +0000 Subject: [issue21180] Efficiently create empty array.array, consistent with bytearray In-Reply-To: <1396963926.18.0.0845457465299.issue21180@psf.upfronthosting.co.za> Message-ID: <1397415482.91.0.80676206048.issue21180@psf.upfronthosting.co.za> Terry J. Reedy added the comment: A few notes: This issue depends on PEP467, but there is no corresponding tracker issue yet to put in the dependency box. Title and other headers can be edited. Messages and uploaded files can be unlinked from the issue but not edited (or deleted from the database). Nick and other developers are busy with PyCon, so please be patient. Why this issue depends on the PEP: There is a general feeling that a default class constructor can be overloaded too far, and that a separate constructor method is sometimes better. Many people think that byte(s/array) is the worst stdlib example of 'too much'. In particular, few seem to like the 0 initializaiton and many dislike it. Changing it is the motivation for the PEP. From Guido's comments, I expect that some version of this change will be accepted even if other parts of the PEP are rejected and eliminated (as some already have been). In summary, while Martin and I agree that 'copy the existing bytearray api' should be rejected, we also think that 'copy the new api' can be considered if and when there is one. ---------- stage: -> test needed title: Cannot efficiently create empty array.array of given size, inconsistency with bytearray -> Efficiently create empty array.array, consistent with bytearray type: performance -> enhancement versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 21:00:44 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Sun, 13 Apr 2014 19:00:44 +0000 Subject: [issue1738] Add match parameter to filecmp.dircmp to ignore using patterns In-Reply-To: <1199482445.72.0.241275927673.issue1738@psf.upfronthosting.co.za> Message-ID: <1397415644.48.0.247120041521.issue1738@psf.upfronthosting.co.za> Nikolaus Rath added the comment: Updated patch to acknowledge original authors in Misc/ACKS. ---------- Added file: http://bugs.python.org/file34801/issue1738_r3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 21:10:37 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Sun, 13 Apr 2014 19:10:37 +0000 Subject: [issue7776] http.client.HTTPConnection tunneling is broken In-Reply-To: <1264394042.86.0.571652227077.issue7776@psf.upfronthosting.co.za> Message-ID: <1397416237.58.0.182108724838.issue7776@psf.upfronthosting.co.za> Nikolaus Rath added the comment: Refreshed patch. ---------- Added file: http://bugs.python.org/file34802/issue7776_r7_Py3.4.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 21:10:51 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Sun, 13 Apr 2014 19:10:51 +0000 Subject: [issue7776] http.client.HTTPConnection tunneling is broken In-Reply-To: <1264394042.86.0.571652227077.issue7776@psf.upfronthosting.co.za> Message-ID: <1397416251.74.0.887851544842.issue7776@psf.upfronthosting.co.za> Changes by Nikolaus Rath : Added file: http://bugs.python.org/file34803/issue7776_r7_Py3.5.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 21:18:06 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Sun, 13 Apr 2014 19:18:06 +0000 Subject: [issue19414] iter(ordered_dict) yields keys not in dict in some circumstances In-Reply-To: <1382844474.66.0.775956254592.issue19414@psf.upfronthosting.co.za> Message-ID: <1397416686.35.0.912573423987.issue19414@psf.upfronthosting.co.za> Nikolaus Rath added the comment: The patch applies cleanly to 3.4 and 3.5, not sure why the review link does not show up. I'm attaching the file again, maybe that helps. ---------- Added file: http://bugs.python.org/file34804/issue19414_r2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 22:12:38 2014 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 13 Apr 2014 20:12:38 +0000 Subject: [issue21161] list comprehensions don't see local variables in pdb in python3 In-Reply-To: <1396698943.39.0.489151150852.issue21161@psf.upfronthosting.co.za> Message-ID: <1397419958.53.0.652966869394.issue21161@psf.upfronthosting.co.za> Xavier de Gaye added the comment: The NameError exception occuring on a generator expression referencing a local variable when the generator is called within exec() is the object of multiple entries in the bug tracker, see issue 13557. msg 149096 in this issue suggests using exec(code, locals()) to fix the problem. It seems that what does currently the do_interact() method, and what is proposed in the patch is the recommended practice to handle this problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 22:32:00 2014 From: report at bugs.python.org (Ned Deily) Date: Sun, 13 Apr 2014 20:32:00 +0000 Subject: [issue20635] Fix the grid geometry manager and add tests for geometry managers In-Reply-To: <1392464302.58.0.168858938069.issue20635@psf.upfronthosting.co.za> Message-ID: <1397421120.12.0.31646068009.issue20635@psf.upfronthosting.co.za> Ned Deily added the comment: test_tk with test_geometry_managers_2-2.7.patch applied passed on OS X 10.9 linked with Carbon Tk 8.4.20, Cocoa 8.5.15, Cocoa 8.6.1, and X11 8.6.1. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 22:43:35 2014 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 13 Apr 2014 20:43:35 +0000 Subject: [issue21209] q.put(some_tuple) fails when PYTHONASYNCIODEBUG=1 In-Reply-To: <1397351442.01.0.248805040826.issue21209@psf.upfronthosting.co.za> Message-ID: <1397421815.17.0.859832332242.issue21209@psf.upfronthosting.co.za> Guido van Rossum added the comment: I'll be darned. It appears that generator's send() method uses METH_O, which means that it really expects a single argument, but if you pass it a tuple, it assumes that you meant each item in the tuple as a separate argument. I think a more correct fix is attached -- don't add a dummy *args to the send() method, but call self.gen.send((value,)). I'd like to fix this upstream and add some tests first; also see http://code.google.com/p/tulip/issues/detail?id=163 (which touches upon a different problem in CoroWrapper not emulating the real generator object well enough). ---------- assignee: -> gvanrossum keywords: +patch Added file: http://bugs.python.org/file34805/gen_send.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 22:51:45 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 13 Apr 2014 20:51:45 +0000 Subject: [issue7951] Should str.format allow negative indexes when used for __getitem__ access? In-Reply-To: <1266450859.13.0.906832569526.issue7951@psf.upfronthosting.co.za> Message-ID: <1397422305.95.0.462894709045.issue7951@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- assignee: docs at python -> terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 13 23:00:17 2014 From: report at bugs.python.org (Eduardo Robles Elvira) Date: Sun, 13 Apr 2014 21:00:17 +0000 Subject: [issue18321] Multivolume support in tarfile module In-Reply-To: <1372406777.07.0.523288075904.issue18321@psf.upfronthosting.co.za> Message-ID: <1397422817.01.0.0536325908073.issue18321@psf.upfronthosting.co.za> Eduardo Robles Elvira added the comment: >> [...] but remember, we split a volume only in the middle of a big file, not in any other case (AFAIK). Hopefully you don't get huge pax headers or anything strange. [...] > Hopefully? Sorry, but have you tested this? I did. I let GNU tar create a two volume archive that is split exactly between the two blocks of an XHDTYPE pax header. > > The result is terrifying. At the beginning of the second volume GNU tar creates an XGLTYPE header as the pax replacement for a GNUTYPE_MULTIVOL header, followed by an XHDTYPE header ("GNUFileParts") that somehow decorates the following REGTYPE(!) tar header that contains the continuation of the split XHDTYPE header data from the previous volume. After that comes the REGTYPE file that the split XHDTYPE header was actually meant for as decoration. > > I attached the archive to this issue. > > What happens if a GNUTYPE_LONGNAME header is split in two? I don't wanna know... > >> write() will need to take into account blocks (BLOCKSIZE), just to be able to split the volumes correctly. > > It is mandatory to do the split on a block boundary (a multiple of 512). >>> BTW, my version of GNU tar refuses to create compressed multiple-volume archives which is why I doubt the usefulness of this feature overall. >> But it has multivolume support right? Which is what I am proposing here. Also, you can gzip (or encrypt or anything) the volumes after creating the volumes.. > > Yeah, it has multivolume support, but a very limited one that is not only weird but isn't even usable together with compression. And sure, I can compress and encrypt the volumes afterward, but I can also create a compressed archive and pipe it through split(1) to split it into parts. Both ways create tar archives that are not readable by GNU tar because they're non-standard. So what? > > Please tell me, what is your actual personal use-case for this feature? I'm willing modify the patch to remove the "weirdness" you refer to. I differ on that it's not usable: it might not be useful to you, but it's certainly a feature that covers part of the functionality of GNU tar. Actually, some of the unit tests are like this: use GNU Tar to compress, then extract with tarfile - and viceversa. Of course you can use split. And I could use Ruby or Perl, but I'm using python and tarfile, and this is a GNU tar feature that is just not supported in python tarfile upstream, and I'm just trying to contribute this feature, if possible :-). BTW, If I create a multivol tar file and then compress the volumes, that does not make it "non-standard", in the same way that if I create a PNG file and then compress it and then store it in EXTFS, it doesn't make it non-standard. I'm just using multiple layers of standards. I'm a contractor, and I have been asked by a client to develop a python-based backup tool. The client is technical and had already an idea of what he wanted to do: use python-tarfile and add support to multivolume and some other goodies, and the client also wanted to try to push the changes upstream as we believe it is the correct thing to do. BTW, when we designed the backup tool, we ruled out the possibility of using split because split wouldn't allow to correctly list all the files in each file-slice separately. We wanted to be able to recover all the files of each "volume" so that if we lose other volumes, we can still recover all the data from the volumes we have. Anyway, if you are the maintainer of tarfile and you think it's not possible to push tar-multivolume support upstream in python tarfile for whatever reason, please tell me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 00:43:52 2014 From: report at bugs.python.org (Matt Chaput) Date: Sun, 13 Apr 2014 22:43:52 +0000 Subject: [issue6623] Lib/ftplib.py Netrc class should be removed. In-Reply-To: <1249165781.68.0.418938928921.issue6623@psf.upfronthosting.co.za> Message-ID: <1397429032.51.0.678693688873.issue6623@psf.upfronthosting.co.za> Matt Chaput added the comment: Created patch to remove the Netrc class and its unit tests (for Python 3.5). ---------- nosy: +maatt Added file: http://bugs.python.org/file34806/remove_Netrc_class.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 01:43:30 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 13 Apr 2014 23:43:30 +0000 Subject: [issue7951] Should str.format allow negative indexes when used for __getitem__ access? In-Reply-To: <1266450859.13.0.906832569526.issue7951@psf.upfronthosting.co.za> Message-ID: <1397432610.84.0.465837716319.issue7951@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The doc bug is that the grammar block uses 'integer' (linked to https://docs.python.org/3/reference/lexical_analysis.html#grammar-token-integer) in arg_name ::= [identifier | integer] element_index ::= integer | index_string when it should use 'decimalinteger' or even more exactly 'digit+'. The int() builtin uses the same relaxed rule when no base is given. >>> 011 SyntaxError: invalid token >>> int('011') 11 >>> '{[011]}'.format('abcdefghijlmn') 'm' One possibity is to replace 'integer' in the grammar block with 'digit+' and perhaps leave the text alone. Another is to replace 'integer' with 'index_number', to go with 'index_string, and add the production "index_number ::= digit+". My though for the latter is that 'index_number' would connect better with 'number' as used in the text. A further option would be to actually replace 'number' in the text with 'index_number'. PS to Todd. As much as possible, doc content changes should be separated from re-formatting. I believe the first block of your patch is purely a re-format ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 01:52:25 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 13 Apr 2014 23:52:25 +0000 Subject: [issue21210] Warnings in Doc/library/json.rst In-Reply-To: <1397384367.1.0.38760092166.issue21210@psf.upfronthosting.co.za> Message-ID: <3g6VBJ40N1z7LjX@mail.python.org> Roundup Robot added the comment: New changeset 399bf1638911 by Benjamin Peterson in branch 'default': correct sphinx mark up for cmdline options (closes #21210) http://hg.python.org/cpython/rev/399bf1638911 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 02:06:01 2014 From: report at bugs.python.org (Karl Richter) Date: Mon, 14 Apr 2014 00:06:01 +0000 Subject: [issue21208] Change default behavior of arguments with type bool when options are specified In-Reply-To: <1397339884.4.0.416428545862.issue21208@psf.upfronthosting.co.za> Message-ID: <1397433961.62.0.903491902684.issue21208@psf.upfronthosting.co.za> Karl Richter added the comment: That's a pity, I still think it's confusing. Thanks for your feedback! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 02:58:37 2014 From: report at bugs.python.org (Kushal Das) Date: Mon, 14 Apr 2014 00:58:37 +0000 Subject: [issue21169] getpass.getpass() fails with non-ASCII characters in prompt In-Reply-To: <1396869835.69.0.462900859226.issue21169@psf.upfronthosting.co.za> Message-ID: <1397437117.56.0.00970658713451.issue21169@psf.upfronthosting.co.za> Kushal Das added the comment: Here is a new patch which uses stream.encoding instead getting the encoding from the locale as suggested by David. It also contains the new test. ---------- Added file: http://bugs.python.org/file34807/issue21169_v5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 03:00:47 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 14 Apr 2014 01:00:47 +0000 Subject: [issue6623] Lib/ftplib.py Netrc class should be removed. In-Reply-To: <1249165781.68.0.418938928921.issue6623@psf.upfronthosting.co.za> Message-ID: <1397437247.92.0.0909866193096.issue6623@psf.upfronthosting.co.za> R. David Murray added the comment: This looks good, except that if we are not going to delete that test routine (and we aren't because we didn't deprecate it :) I think we should instead replace the usage of Netrc with the netrc module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 03:16:55 2014 From: report at bugs.python.org (Eric Snow) Date: Mon, 14 Apr 2014 01:16:55 +0000 Subject: [issue21200] pkgutil.get_loader() fails on "__main__" In-Reply-To: <1397225255.72.0.022634576387.issue21200@psf.upfronthosting.co.za> Message-ID: <1397438215.8.0.865725315826.issue21200@psf.upfronthosting.co.za> Eric Snow added the comment: Here's a patch that checks for modules that don't have __spec__ set. The patch will fix the problem. However note that the docs and docstring imply (to me) that we should turn any ImportError coming out of the find_loader() call into returning None. Fixing that will also fix this bug, so this patch may be unnecessary. ---------- keywords: +patch stage: test needed -> patch review Added file: http://bugs.python.org/file34808/issue21200-pkgutil-main.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 03:23:03 2014 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 14 Apr 2014 01:23:03 +0000 Subject: [issue21209] q.put(some_tuple) fails when PYTHONASYNCIODEBUG=1 In-Reply-To: <1397351442.01.0.248805040826.issue21209@psf.upfronthosting.co.za> Message-ID: <1397438583.39.0.106387316167.issue21209@psf.upfronthosting.co.za> Guido van Rossum added the comment: Heh. METH_O was *also* a red herring. But upstream (Tulip) issue 163 *was* a good clue. I now believe that the real bug is that CoroWrapper.__iter__() has "return self" rather than "return iter(self.gen)". That fix is in the 2nd attachment. ---------- Added file: http://bugs.python.org/file34809/gen_send_2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 03:33:15 2014 From: report at bugs.python.org (Kushal Das) Date: Mon, 14 Apr 2014 01:33:15 +0000 Subject: [issue21169] getpass.getpass() fails with non-ASCII characters in prompt In-Reply-To: <1396869835.69.0.462900859226.issue21169@psf.upfronthosting.co.za> Message-ID: <1397439195.57.0.744342619421.issue21169@psf.upfronthosting.co.za> Kushal Das added the comment: New patchset with updated test, now sending ascii stream into the call as argument. ---------- Added file: http://bugs.python.org/file34810/issue21169_v6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 03:45:52 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Mon, 14 Apr 2014 01:45:52 +0000 Subject: [issue7776] http.client.HTTPConnection tunneling is broken In-Reply-To: <1264394042.86.0.571652227077.issue7776@psf.upfronthosting.co.za> Message-ID: <1397439952.32.0.873457777817.issue7776@psf.upfronthosting.co.za> Senthil Kumaran added the comment: I am reviewing this patch right now and you will see my action soon. It is completely and I am reviewing to validating the technical details/fix. Thanks for patch, Nikolaus. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 03:48:18 2014 From: report at bugs.python.org (Eric Snow) Date: Mon, 14 Apr 2014 01:48:18 +0000 Subject: [issue21211] pkgutil.find_loader() raises ImportError instead of returning None Message-ID: <1397440098.66.0.10150246835.issue21211@psf.upfronthosting.co.za> New submission from Eric Snow: In 3987667bf98f pkgutil.find_loader() switched from using pkgutil.iter_importers() to importlib.find_module(). importlib.find_module() checks the module's __loader__ (and raises ImportError when invalid) whereas iter_importers() does no such check. In 3.4 pkgutil.find_loader() switched over to importlib.util.find_spec(), but the same issue remains. The documentation (and the previous behavior) implies that the ImportError case coming out of find_spec() should result in pkgutil.find_loader() returning None rather than propagating the ImportError. However, it may make more sense to do an explicit check for module.__spec__ before calling find_spec(). ---------- components: Library (Lib) keywords: 3.3regression messages: 216047 nosy: brett.cannon, eric.snow, ncoghlan priority: high severity: normal stage: test needed status: open title: pkgutil.find_loader() raises ImportError instead of returning None type: behavior versions: Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 03:49:36 2014 From: report at bugs.python.org (Eric Snow) Date: Mon, 14 Apr 2014 01:49:36 +0000 Subject: [issue21200] pkgutil.get_loader() fails on "__main__" In-Reply-To: <1397225255.72.0.022634576387.issue21200@psf.upfronthosting.co.za> Message-ID: <1397440176.6.0.417798167883.issue21200@psf.upfronthosting.co.za> Eric Snow added the comment: I've opened #21211 to more directly address the find_loader() issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 03:58:19 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Mon, 14 Apr 2014 01:58:19 +0000 Subject: [issue20578] BufferedIOBase.readinto1 is missing In-Reply-To: <1391991229.05.0.363628736117.issue20578@psf.upfronthosting.co.za> Message-ID: <1397440699.57.0.98610155682.issue20578@psf.upfronthosting.co.za> Nikolaus Rath added the comment: Here's a little script to estimate the performance difference between using read1 and readinto1 to read large amounts of data. On my system, I get: C readinto1: 4.960e-01 seconds C read1: 4.055e-01 seconds Python readinto1: 1.066e+00 seconds Python read1: 2.565e+00 seconds In other words, _pyio.BufferedReader.readinto1 is more than a factor of 2 faster than _pyio.BufferedReader.read1 and io.readinto1 is faster than io.read1 by about 20%. On its own, I think this would justify keeping an implementation of readinto1 in _pyio.BufferedReader instead of falling back on the default (that is implemented using read1). However, I believe that people who need performance are probably not using _pyio but io, so *my* argument for keeping it implemented in _pyio is to keep the implementations similiar. I found studying _pyio very helpful to understand the C code in io. If we implement BufferedReader.readinto1 in io, but not in _pyio.BufferedReader, this advantage would be reduced. That said, I am primary interested in getting readinto1 into io. So I'm happy to either extend the patch to also provide a fast readinto implementation for _pyio (to align it with io), or to remove the readinto1 implementation in _pyio. ---------- Added file: http://bugs.python.org/file34811/benchmark.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 03:58:41 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 14 Apr 2014 01:58:41 +0000 Subject: [issue21169] getpass.getpass() fails with non-ASCII characters in prompt In-Reply-To: <1396869835.69.0.462900859226.issue21169@psf.upfronthosting.co.za> Message-ID: <1397440721.42.0.170775098389.issue21169@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Arfrever: If you set the locale to C, the device does *not* (anymore) support the character. The terminal application you are using may, but the "system" does not. It only supports the characters available in the locale, which your character is not. There simply is no way in which Python *could* encode the character. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 04:09:45 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 14 Apr 2014 02:09:45 +0000 Subject: [issue21169] getpass.getpass() fails with non-ASCII characters in prompt In-Reply-To: <1396869835.69.0.462900859226.issue21169@psf.upfronthosting.co.za> Message-ID: <3g6YDm5Fxdz7LjR@mail.python.org> Roundup Robot added the comment: New changeset f430fdd1628e by R David Murray in branch '3.4': #21169: fix getpass to use replace error handler on UnicodeEncodeError. http://hg.python.org/cpython/rev/f430fdd1628e New changeset 461f5863f2aa by R David Murray in branch 'default': Mierge #21169: fix getpass to use replace error handler on UnicodeEncodeError. http://hg.python.org/cpython/rev/461f5863f2aa ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 04:14:14 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 14 Apr 2014 02:14:14 +0000 Subject: [issue21169] getpass.getpass() fails with non-ASCII characters in prompt In-Reply-To: <1396869835.69.0.462900859226.issue21169@psf.upfronthosting.co.za> Message-ID: <1397441654.06.0.884951872188.issue21169@psf.upfronthosting.co.za> R. David Murray added the comment: Since we don't want the prompting for the password to fail, what we do in the patch is use the replace error handler so that you get as much as could be encoded of the prompt. (Note: this approach was reviewed by both Toshio and Marc Andre.) Thanks for the patch, Kushal. ---------- resolution: -> fixed status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 04:16:51 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 14 Apr 2014 02:16:51 +0000 Subject: [issue20578] BufferedIOBase.readinto1 is missing In-Reply-To: <1391991229.05.0.363628736117.issue20578@psf.upfronthosting.co.za> Message-ID: <1397441811.71.0.0832614745164.issue20578@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Can you please extend your benchmark to also measure read and readinto? I'm puzzled why you are treating readinto1 differently from readinto. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 04:19:23 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 14 Apr 2014 02:19:23 +0000 Subject: [issue21169] getpass.getpass() fails with non-ASCII characters in prompt In-Reply-To: <1396869835.69.0.462900859226.issue21169@psf.upfronthosting.co.za> Message-ID: <1397441963.22.0.886157863823.issue21169@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Ok. I wish the patch had a comment saying that, or better even a documentation change pointing out that feature. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 04:19:52 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Mon, 14 Apr 2014 02:19:52 +0000 Subject: [issue20578] BufferedIOBase.readinto1 is missing In-Reply-To: <1391991229.05.0.363628736117.issue20578@psf.upfronthosting.co.za> Message-ID: <1397441992.4.0.541816251376.issue20578@psf.upfronthosting.co.za> Nikolaus Rath added the comment: (Rietveld is giving me errors, so I'm replying here) On 2014/04/13 02:22:23, loewis wrote: >>> Again, why a separate implementation here? >> >> For performance reasons. Relying on the default implementation >> would fall back to using read1(), which means a new bytes object >> is created first. > > Hmm. > a) if performance was relevant, it should apply to readinto() as well. I didn't even notice the readinto implementation was missing. But I agree, if we keep readinto1(), we should also add readinto(). > b) if the code is duplicated for performance only, a comment should > state that explicitly. I'm very sorry, but I still don't see which code in readinto1() is duplicate. You don't mean duplicate between io and _pyio, do you? > c) to justify a performance argument, you should really provide hard > numbers that demonstrate a performance gain justifying the code > duplication. I posted a small benchmark to the issue tracker. Personally, I think the more important argument is to keep the Python and C implementations similar. It's really nice if you can look at _pyio to find out at least roughly what happens in io. (Yes, I did put performance first in my last reply, but only because I thought you were asking about readinto1 in general, rather than the additional Python implementation in _pyio.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 04:26:37 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Mon, 14 Apr 2014 02:26:37 +0000 Subject: [issue20578] BufferedIOBase.readinto1 is missing In-Reply-To: <1391991229.05.0.363628736117.issue20578@psf.upfronthosting.co.za> Message-ID: <1397442397.35.0.120615304836.issue20578@psf.upfronthosting.co.za> Nikolaus Rath added the comment: > Can you please extend your benchmark to also measure read and readinto? Yes - but I don't quite understand why it matters (if you need read1/readinto1, you cannot just use read/readinto instead). C readinto1: 4.638e-01 seconds C read1: 4.026e-01 seconds C readinto: 4.655e-01 seconds C read: 4.028e-01 seconds Python readinto1: 1.056e+00 seconds Python read1: 2.429e+00 seconds Python readinto: 1.895e+00 seconds Python read: 1.218e+00 seconds That shows that the Python readinto is definetely not up-to-par and could use improvement as well. Is that what you're getting at? > I'm puzzled why you are treating readinto1 differently from readinto. Maybe this is why we seem to be talking past each other :-). I did not look or work on readinto at all. All I noticed is that there is a read1, but no readinto1. So I implemented a readinto1 as well as I could. ---------- Added file: http://bugs.python.org/file34812/benchmark.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 04:39:41 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 14 Apr 2014 02:39:41 +0000 Subject: [issue21209] q.put(some_tuple) fails when PYTHONASYNCIODEBUG=1 In-Reply-To: <1397351442.01.0.248805040826.issue21209@psf.upfronthosting.co.za> Message-ID: <1397443181.32.0.50608263777.issue21209@psf.upfronthosting.co.za> STINNER Victor added the comment: The error occurs at line "v = yield from q.get()": Traceback (most recent call last): File "/home/haypo/prog/python/default/Lib/asyncio/events.py", line 39, in _run self._callback(*self._args) File "/home/haypo/prog/python/default/Lib/asyncio/tasks.py", line 357, in _wakeup self._step(value, None) File "/home/haypo/prog/python/default/Lib/asyncio/tasks.py", line 309, in _step self.set_exception(exc) File "/home/haypo/prog/python/default/Lib/asyncio/tasks.py", line 301, in _step result = coro.send(value) File "put_get_bug.py", line 23, in t2 v = yield from q.get() TypeError: send() takes 2 positional arguments but 7 were given Task._step() is called with value=(0, 1, 2, 3, 4, 5) (and exc is None). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 04:40:22 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 14 Apr 2014 02:40:22 +0000 Subject: [issue21209] q.put(some_tuple) fails when PYTHONASYNCIODEBUG=1 In-Reply-To: <1397351442.01.0.248805040826.issue21209@psf.upfronthosting.co.za> Message-ID: <1397443222.67.0.391299293093.issue21209@psf.upfronthosting.co.za> STINNER Victor added the comment: gen_send.diff doesn't look like a fix but a workaround. gen_send_2.diff lacks a unit test. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 04:55:24 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 14 Apr 2014 02:55:24 +0000 Subject: [issue20578] BufferedIOBase.readinto1 is missing In-Reply-To: <1391991229.05.0.363628736117.issue20578@psf.upfronthosting.co.za> Message-ID: <1397444124.76.0.57424081707.issue20578@psf.upfronthosting.co.za> Martin v. L?wis added the comment: > I didn't even notice the readinto implementation was missing. But I > agree, if we keep readinto1(), we should also add readinto(). [...] > Maybe this is why we seem to be talking past each other :-). I did not > look or work on readinto at all. All I noticed is that there is a read1, > but no readinto1. So I implemented a readinto1 as well as I could. I see. It's not actually true that there is no readinto - it's inherited from the base class. I think it is more important that the implementation is consistent than that it is performant (but achieving both should be possible). Whether or not _pyio needs to be performant, I don't know. Having it consistent with _io would be desirable, but might not be possible. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 05:00:25 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 14 Apr 2014 03:00:25 +0000 Subject: [issue21209] q.put(some_tuple) fails when PYTHONASYNCIODEBUG=1 In-Reply-To: <1397351442.01.0.248805040826.issue21209@psf.upfronthosting.co.za> Message-ID: <1397444425.4.0.693772150108.issue21209@psf.upfronthosting.co.za> STINNER Victor added the comment: I don't think that the bug comes from asyncio, but it looks like a bug in the implementation of "yield from" in CPython directly! Try with ceval.patch. ceval.c has a fast path if the object is a generator. With PYTHONASYNCIODEBUG=1, the object is a CoroWrapper, not a generator. In this case, the slow path is used: retval = _PyObject_CallMethodId(reciever, &PyId_send, "O", v); This line comes from the initial commit introducing yield-from: --- changeset: 74356:d64ac9ab4cd0 user: Nick Coghlan date: Fri Jan 13 21:43:40 2012 +1000 files: Doc/library/dis.rst Doc/library/exceptions.rst Doc/reference/expressions.rst Doc/reference/simple_stmts.rst Doc/whatsnew/3. description: Implement PEP 380 - 'yield from' (closes #11682) --- (The exact line changed and the line was moved, but "O" format didn't change.) Still no unit test, I'm too tired to write one, and I'm not sure that it's a bug in ceval.c. ---------- nosy: +ncoghlan Added file: http://bugs.python.org/file34813/ceval.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 05:17:19 2014 From: report at bugs.python.org (Gene Wood) Date: Mon, 14 Apr 2014 03:17:19 +0000 Subject: [issue17088] ElementTree incorrectly refuses to write attributes without namespaces when default_namespace is used In-Reply-To: <1359599707.26.0.771342463799.issue17088@psf.upfronthosting.co.za> Message-ID: <1397445439.09.0.102741416779.issue17088@psf.upfronthosting.co.za> Gene Wood added the comment: One workaround to this is described here : http://stackoverflow.com/a/4999510/168874 It involves prefixing all of the elements with the namespace like this : from xml.etree import ElementTree as ET # build a tree structure root = ET.Element("{http://www.company.com}STUFF") body = ET.SubElement(root, "{http://www.company.com}MORE_STUFF") body.text = "STUFF EVERYWHERE!" # wrap it in an ElementTree instance, and save as XML tree = ET.ElementTree(root) tree.write("page.xml", xml_declaration=True,encoding='utf-8', method="xml",default_namespace='http://www.company.com') ---------- nosy: +gene_wood _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 05:19:11 2014 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 14 Apr 2014 03:19:11 +0000 Subject: [issue21209] q.put(some_tuple) fails when PYTHONASYNCIODEBUG=1 In-Reply-To: <1397351442.01.0.248805040826.issue21209@psf.upfronthosting.co.za> Message-ID: <1397445551.43.0.706612870453.issue21209@psf.upfronthosting.co.za> Guido van Rossum added the comment: Wow. So many fixes! :-) Are you going to be at the CPython sprint tomorrow? I'll be there in the morning but my plane leaves in the afternoon. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 05:28:21 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 14 Apr 2014 03:28:21 +0000 Subject: [issue21209] q.put(some_tuple) fails when PYTHONASYNCIODEBUG=1 In-Reply-To: <1397445551.43.0.706612870453.issue21209@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > Are you going to be at the CPython sprint tomorrow? I'll be there in the morning but my plane leaves in the afternoon. I organize a "Port OpenStack to Python3" sprint, but I may come also to the CPython sprint. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 05:52:53 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 14 Apr 2014 03:52:53 +0000 Subject: [issue21209] q.put(some_tuple) fails when PYTHONASYNCIODEBUG=1 In-Reply-To: <1397351442.01.0.248805040826.issue21209@psf.upfronthosting.co.za> Message-ID: <3g6bWm38RTz7LjS@mail.python.org> Roundup Robot added the comment: New changeset 05b3a23b3836 by Benjamin Peterson in branch '3.4': fix sending tuples to custom generator objects with yield from (closes #21209) http://hg.python.org/cpython/rev/05b3a23b3836 New changeset d1eba2645b80 by Benjamin Peterson in branch 'default': merge 3.4 (#21209) http://hg.python.org/cpython/rev/d1eba2645b80 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 05:58:01 2014 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 14 Apr 2014 03:58:01 +0000 Subject: [issue21209] q.put(some_tuple) fails when PYTHONASYNCIODEBUG=1 In-Reply-To: <1397351442.01.0.248805040826.issue21209@psf.upfronthosting.co.za> Message-ID: <1397447881.89.0.473369406187.issue21209@psf.upfronthosting.co.za> Yury Selivanov added the comment: Hm... Can we also commit this to 3.3? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 06:05:29 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 14 Apr 2014 04:05:29 +0000 Subject: [issue21191] os.fdopen() may eat file descriptor and still raise exception In-Reply-To: <1397209220.11.0.00351625682393.issue21191@psf.upfronthosting.co.za> Message-ID: <1397448327.30888.106122481.2D34C162@webmail.messagingengine.com> Benjamin Peterson added the comment: Feel free to submit a patch. On Fri, Apr 11, 2014, at 2:40, Dima Tisnek wrote: > > Dima Tisnek added the comment: > > I think consistency between Python versions is just as important as > consistency between fd types. > > Here's my hack quickfix outline: > > fd = os.open(...) > try: > if not stat.S_ISREG(os.fstat(fd).st_mode): > raise OSError(None, "Not a regular file", ...) > f = os.fdopen(fd, ...) > except EnvironmentError: > os.close(fd) > > Can something like this be implemented in os.py > There's already a check `if not isinstance(fd, int): raise ...` > > Granted we'd have to get fd type check exactly right. Well, you just have check exactly what it's checking now, which seems to be !S_ISDIR. > fdopen should probably succeed for regular files, pipes, char devices, > block device, ptry's ... > fdopen should fail where underlying implementation fails, i.e. > directories, sockets(?), epoll(?), timerfd(?) > > There's a list at http://en.wikipedia.org/wiki/File_descriptor > I'm not sure about some types. > > P.S. I wish there was a way to rescue fd from FILE*, but nothing like > that seems to exist... Yes, this is one of the main problems. > > P.P.S. another option is to always use dup(), but that may break existing > programs is they expect fd == fdopen(fd).fileno() ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 08:00:43 2014 From: report at bugs.python.org (Stefan Behnel) Date: Mon, 14 Apr 2014 06:00:43 +0000 Subject: [issue17088] ElementTree incorrectly refuses to write attributes without namespaces when default_namespace is used In-Reply-To: <1359599707.26.0.771342463799.issue17088@psf.upfronthosting.co.za> Message-ID: <1397455243.28.0.771018697869.issue17088@psf.upfronthosting.co.za> Stefan Behnel added the comment: @gene_wood: that's unrelated. This ticket is about attributes being rejected incorrectly. Fixing the example of the OP: >>> from xml.etree.ElementTree import * >>> svg = ElementTree(XML(""" ... ... ... ... """)) >>> tostring(svg.getroot()) # formatting is mine b'\n \n ' >>> svg.write('simple_new.svg',encoding='UTF-8',default_namespace='http://www.w3.org/2000/svg') Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.3/xml/etree/ElementTree.py", line 826, in write qnames, namespaces = _namespaces(self._root, default_namespace) File "/usr/lib/python3.3/xml/etree/ElementTree.py", line 942, in _namespaces add_qname(key) File "/usr/lib/python3.3/xml/etree/ElementTree.py", line 920, in add_qname "cannot use non-qualified names with " ValueError: cannot use non-qualified names with default_namespace option >>> svg.write('simple_new.svg',encoding='UTF-8') >>> So, it works without namespace defaulting and fails with an incorrect error when a default namespace is provided. Clearly a bug. Regarding the proposed patch: it looks like the right thing to do in general, but it has a relatively high code impact. I would prefer a patch with lower churn. One thing that could be tried is to use only one tag cache dict and extend the key from the plain tag to (tag, is_attribute). Might have a performance impact on the already slow serialiser, though. In any case, both approaches are quite wasteful, because they duplicate the entire namespace-prefix mapping just because there might be a single namespace that behaves differently for atributes. An alternative could be to split the *value* of the mapping in two: (element_prefix, attribute_prefix). This would keep the overhead at serialisation low, with only slightly more work when building the mapping. At first sight, I like that idea better. This code returns a list in one case and a set-like view in another (Py3): + if default_namespace: + prefixes_list = [ (default_namespace, "") ] + prefixes_list.extend(namespaces.items()) + else: + prefixes_list = namespaces.items() I can't see the need for this change. Why can't the default namespace be stored in the namespaces dict right from the start, as it was before? As a minor nitpick, this lambda based sort key: key=lambda x: x[1]): # sort on prefix is better expressed using operator.itemgetter(1). I'd also rename the "defaultable" flag to "is_attribute" and pass it as keyword argument (bare boolean parameters are unreadable in function calls). Given the impact of this change, I'd also suggest not applying it to Py2.x anymore. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 08:48:45 2014 From: report at bugs.python.org (Chandan Kumar) Date: Mon, 14 Apr 2014 06:48:45 +0000 Subject: [issue21196] Name mangling example in Python tutorial In-Reply-To: <1397133080.37.0.870141660622.issue21196@psf.upfronthosting.co.za> Message-ID: <1397458125.27.0.484689314626.issue21196@psf.upfronthosting.co.za> Chandan Kumar added the comment: Uploading the patch for the improvement to the name mangling section of the Python tutorial. Please note that the modification is much smaller than I proposed earlier. ---------- keywords: +patch Added file: http://bugs.python.org/file34814/docs_name_mangling.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 12:27:52 2014 From: report at bugs.python.org (Bill) Date: Mon, 14 Apr 2014 10:27:52 +0000 Subject: [issue21212] Documentation of octal representation Message-ID: <1397471272.26.0.476582477816.issue21212@psf.upfronthosting.co.za> New submission from Bill: This documentation section: https://docs.python.org/3/faq/programming.html?highlight=octal#how-do-i-convert-a-string-to-a-number seems still to refer to Python 2 octal representation rules. So I think it needs updating. ---------- assignee: docs at python components: Documentation messages: 216069 nosy: docs at python, ees1wc priority: normal severity: normal status: open title: Documentation of octal representation versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 12:37:32 2014 From: report at bugs.python.org (Artur) Date: Mon, 14 Apr 2014 10:37:32 +0000 Subject: [issue1484] logging: callHandlers tests handler levels instead of logger levels? In-Reply-To: <1195684877.23.0.0511912191493.issue1484@psf.upfronthosting.co.za> Message-ID: <1397471852.15.0.0162438591388.issue1484@psf.upfronthosting.co.za> Artur added the comment: So what is logger level for if it's not used on calling handlers? ---------- nosy: +artur.ambroziak versions: +Python 2.7 -Python 2.4, Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 12:56:20 2014 From: report at bugs.python.org (saaj) Date: Mon, 14 Apr 2014 10:56:20 +0000 Subject: [issue21213] Memory bomb by incorrect custom serializer to json.dumps Message-ID: <1397472980.58.0.747239124099.issue21213@psf.upfronthosting.co.za> New submission from saaj: I was chaning an implementation of the function that is passed to json.dumps to extend serializable types. By a mistake (**return** instead of **raise**) it turned into, which at its minum can be expressed as:: def d(obj): return TypeError(repr(obj)) json.dumps(1j, default = d) After a few moments by laptop froze, though after a minute I could open shell in separate session, and top command showed that python interpretter is consuming about 4GiB of memory and 50% of 4 logical cores. Worst about it it doesn't end with any exception, it just keeps running. Without ``repr`` it ends up with somewhat expected ``RuntimeError: maximum recursion depth exceeded while getting the str of an object``. The same behaviour is on python3, where it just consumes memory with less speed. OS: Linux Mint 15 Olivia Linux 3.8.0-31-generic #46-Ubuntu SMP Tue Sep 10 20:03:44 UTC 2013 x86_64 Packages are last available: python 2.7.4-0ubuntu1 python3 3.3.1-0ubuntu1 P.S. Sorry for confirming on console at python.org. ---------- components: Library (Lib) messages: 216071 nosy: saaj priority: normal severity: normal status: open title: Memory bomb by incorrect custom serializer to json.dumps versions: Python 2.7, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 12:56:48 2014 From: report at bugs.python.org (Max) Date: Mon, 14 Apr 2014 10:56:48 +0000 Subject: [issue21214] PEP8 doesn't verifies last line. Message-ID: <1397473008.16.0.589712563866.issue21214@psf.upfronthosting.co.za> New submission from Max: PEP8 doesn't verifies last line at all. Also W292 will never be checked. Reproducible on PEP8 >= 1.5.0 ---------- messages: 216072 nosy: f1ashhimself priority: normal severity: normal status: open title: PEP8 doesn't verifies last line. type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 13:20:09 2014 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Mon, 14 Apr 2014 11:20:09 +0000 Subject: [issue18321] Multivolume support in tarfile module In-Reply-To: <1372406777.07.0.523288075904.issue18321@psf.upfronthosting.co.za> Message-ID: <1397474409.44.0.835169918743.issue18321@psf.upfronthosting.co.za> Lars Gust?bel added the comment: Okay, let me tell you why I reject your contribution at this point. The patch you submitted may be well-suited for your purposes but it does not meet the requirements of a standard library implementation because it is not generic and comprehensive enough. It contains duplicate code, spelling mistakes and needless code changes e.g. in test_tarfile.py. It does not expose one set of volumes as one tar archive to the user. It is not possible to iterate over all members of all volumes in one go. It does not allow random-access. Actually, it does not implement complete multivolume support but only the "easy" parts. For example, it fails to read GNU tar archives that are split in the middle of a pax header block sequence. The other way around, when writing it makes a split only when it is inside the data part of a member. Hence, it is possible that a volume turns out smaller than max_volume_size which is not only inaccurate but also bad on a tape device. If you decide that you still want multivolume support in tarfile, feel free to reopen this issue with a new and significantly better patch. I gave you a number of clues on what I think is required. ---------- assignee: -> lars.gustaebel resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 13:45:22 2014 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 14 Apr 2014 11:45:22 +0000 Subject: [issue21214] PEP8 doesn't verifies last line. In-Reply-To: <1397473008.16.0.589712563866.issue21214@psf.upfronthosting.co.za> Message-ID: <1397475922.51.0.0217411435278.issue21214@psf.upfronthosting.co.za> Mark Dickinson added the comment: The pep8 tool is a third-party package: it isn't part of the core Python project. You probably want to report this at the pep8 bugtracker: http://github.com/jcrocholl/pep8/issues ---------- nosy: +mark.dickinson resolution: -> 3rd party status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 13:46:45 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 14 Apr 2014 11:46:45 +0000 Subject: [issue21212] Documentation of octal representation In-Reply-To: <1397471272.26.0.476582477816.issue21212@psf.upfronthosting.co.za> Message-ID: <3g6p2Y0l1qz7LjN@mail.python.org> Roundup Robot added the comment: New changeset fb7bc8fe0d49 by Eric V. Smith in branch '3.4': Fix text about int() with octal numbers. Closes #21212. http://hg.python.org/cpython/rev/fb7bc8fe0d49 New changeset 6107a727c60a by Eric V. Smith in branch 'default': Merge 3.4: Fix text about int() with octal numbers. Closes #21212. http://hg.python.org/cpython/rev/6107a727c60a ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 13:47:23 2014 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 14 Apr 2014 11:47:23 +0000 Subject: [issue21212] Documentation of octal representation In-Reply-To: <1397471272.26.0.476582477816.issue21212@psf.upfronthosting.co.za> Message-ID: <1397476043.24.0.292131297627.issue21212@psf.upfronthosting.co.za> Eric V. Smith added the comment: Fixed. Thanks! ---------- nosy: +eric.smith resolution: fixed -> stage: committed/rejected -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 14:11:27 2014 From: report at bugs.python.org (Berker Peksag) Date: Mon, 14 Apr 2014 12:11:27 +0000 Subject: [issue21212] Documentation of octal representation In-Reply-To: <1397471272.26.0.476582477816.issue21212@psf.upfronthosting.co.za> Message-ID: <1397477487.66.0.778032101009.issue21212@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 14:21:04 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 14 Apr 2014 12:21:04 +0000 Subject: [issue21169] getpass.getpass() fails with non-ASCII characters in prompt In-Reply-To: <1396869835.69.0.462900859226.issue21169@psf.upfronthosting.co.za> Message-ID: <1397478064.36.0.261979042708.issue21169@psf.upfronthosting.co.za> R. David Murray added the comment: Ok, I'll reopen the issue to do that. ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 15:49:16 2014 From: report at bugs.python.org (Kushal Das) Date: Mon, 14 Apr 2014 13:49:16 +0000 Subject: [issue21169] getpass.getpass() fails with non-ASCII characters in prompt In-Reply-To: <1396869835.69.0.462900859226.issue21169@psf.upfronthosting.co.za> Message-ID: <1397483356.94.0.0652316104999.issue21169@psf.upfronthosting.co.za> Kushal Das added the comment: Another patch with docs update and one line code comment. ---------- Added file: http://bugs.python.org/file34815/issue21169_v7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 15:52:40 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 14 Apr 2014 13:52:40 +0000 Subject: [issue20077] Format of TypeError differs between comparison and arithmetic operators In-Reply-To: <1388106970.8.0.6745803605.issue20077@psf.upfronthosting.co.za> Message-ID: <1397483560.22.0.0647133885997.issue20077@psf.upfronthosting.co.za> R. David Murray added the comment: I think 'please review' was directed at anyone, and yes, using the review link is one way to do a review, but when there isn't enough line-by-line commenting to make the code review tool worth using you can just post on the issue. (And when you do use the review link, it is helpful to post a message here that you did, since one doesn't appear automatically...which is something we need to fix.) ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 16:18:49 2014 From: report at bugs.python.org (Glenn Jones) Date: Mon, 14 Apr 2014 14:18:49 +0000 Subject: [issue21215] build-deps instructions for Ubuntu Message-ID: <1397485129.87.0.0518806030798.issue21215@psf.upfronthosting.co.za> New submission from Glenn Jones: The package listed in the dev guide may not exist depending on the version of Ubuntu. It may be necessary to use python3.3 or python3.4. ---------- components: Devguide messages: 216080 nosy: Glenn.Jones, ezio.melotti priority: normal severity: normal status: open title: build-deps instructions for Ubuntu _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 16:31:08 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 14 Apr 2014 14:31:08 +0000 Subject: [issue21169] getpass.getpass() fails with non-ASCII characters in prompt In-Reply-To: <1396869835.69.0.462900859226.issue21169@psf.upfronthosting.co.za> Message-ID: <3g6shC4f0Hz7LjP@mail.python.org> Roundup Robot added the comment: New changeset bdde36cd9048 by R David Murray in branch '3.4': #21169: add comment and doc update for getpass change. http://hg.python.org/cpython/rev/bdde36cd9048 New changeset fe532dccf8f6 by R David Murray in branch 'default': Merge: #21169: add comment and doc update for getpass change. http://hg.python.org/cpython/rev/fe532dccf8f6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 16:32:58 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 14 Apr 2014 14:32:58 +0000 Subject: [issue21169] getpass.getpass() fails with non-ASCII characters in prompt In-Reply-To: <1396869835.69.0.462900859226.issue21169@psf.upfronthosting.co.za> Message-ID: <1397485978.71.0.192814553713.issue21169@psf.upfronthosting.co.za> R. David Murray added the comment: I decided to tweak the language slightly, Kushal. If this isn't what you were looking for, Martin, let me know. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 16:39:36 2014 From: report at bugs.python.org (Eric Snow) Date: Mon, 14 Apr 2014 14:39:36 +0000 Subject: [issue20434] Process crashes if not enough memory to import module In-Reply-To: <1390984600.38.0.476358983499.issue20434@psf.upfronthosting.co.za> Message-ID: <1397486376.07.0.683416666611.issue20434@psf.upfronthosting.co.za> Eric Snow added the comment: I was going to say we should consider changing the API of _PyBytes_Resize() and _PyString_Resize(). However, having looked at the two functions, I guess it makes sense. Looking at the patch, I'd argue that we still need to set the string to NULL in the error case. Only in the out-of-memory case do the two functions change it to NULL for you. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 16:43:48 2014 From: report at bugs.python.org (Jessica McKellar) Date: Mon, 14 Apr 2014 14:43:48 +0000 Subject: [issue19980] Improve help('non-topic') response In-Reply-To: <1386984892.27.0.919528696836.issue19980@psf.upfronthosting.co.za> Message-ID: <1397486628.48.0.807014364675.issue19980@psf.upfronthosting.co.za> Jessica McKellar added the comment: Elias, thanks for your patch! I think it's important to add the second part of Terry's suggestion which gives the user a specific next step to take, namely: > Try help('help') for information on recognized strings or help(str) for help on the str class. Can you add that to your patch? Additionally, we'll want to make sure we don't accidentally break this new functionality. Can you add a few test cases, for example what happens when you run help on a module (e.g. help("os"), 2) help on an instance of a class (e.g. help(1)), and help on a string that doesn't have a special meaning, (e.g. help("abcxyz"))? I don't see any existing tests for help(), but it is an instance of site._Helper (as reported by type(help)), and site tests live in Lib/test/test_site.py. It also gets loaded into builtins, so tests could also live in Lib/test/test_builtins.py. ---------- nosy: +Jessica.McKellar, jesstess _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 16:48:21 2014 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 14 Apr 2014 14:48:21 +0000 Subject: [issue21209] q.put(some_tuple) fails when PYTHONASYNCIODEBUG=1 In-Reply-To: <1397447881.89.0.473369406187.issue21209@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: This is nice (a backport 3.3 would be even nicer) but at least for the PyPI repo version of Tulip I'd like to have work-around so people won't run into this when they are using a slightly outdated Python version. I'll think about which of my work-arounds is safe for that while not breaking the intended functionality of CoroWrapper (i.e. that it prints a warning when destructed before it has reached the end). That may require setting an additional flag. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 16:49:16 2014 From: report at bugs.python.org (Glenn Jones) Date: Mon, 14 Apr 2014 14:49:16 +0000 Subject: [issue21215] build-deps instructions for Ubuntu In-Reply-To: <1397485129.87.0.0518806030798.issue21215@psf.upfronthosting.co.za> Message-ID: <1397486956.53.0.463459042574.issue21215@psf.upfronthosting.co.za> Changes by Glenn Jones : ---------- keywords: +patch Added file: http://bugs.python.org/file34816/ubuntu-build-dep.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 16:52:30 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 14 Apr 2014 14:52:30 +0000 Subject: [issue21215] build-deps instructions for Ubuntu In-Reply-To: <1397485129.87.0.0518806030798.issue21215@psf.upfronthosting.co.za> Message-ID: <1397487150.93.0.829824309327.issue21215@psf.upfronthosting.co.za> R. David Murray added the comment: Since you are saying that it is "sometimes" necessary to use a different package, perhaps we should be saying that in the devguide? And providing the possible names. ---------- nosy: +barry, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 16:57:56 2014 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Mon, 14 Apr 2014 14:57:56 +0000 Subject: [issue20434] Process crashes if not enough memory to import module In-Reply-To: <1390984600.38.0.476358983499.issue20434@psf.upfronthosting.co.za> Message-ID: <1397487476.85.0.146049875892.issue20434@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: I would also advocate for a better api, that leaves it up to the caller what to do, much like realloc() does. A convenience macro that frees the block on error could then be provided. But this is 2.7 and we don't change stuff there :) Can you elaborate on your second comment? Is there some place where I forgot to clear the object? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 17:04:17 2014 From: report at bugs.python.org (Glenn Jones) Date: Mon, 14 Apr 2014 15:04:17 +0000 Subject: [issue21215] build-deps instructions for Ubuntu In-Reply-To: <1397485129.87.0.0518806030798.issue21215@psf.upfronthosting.co.za> Message-ID: <1397487857.74.0.962882553652.issue21215@psf.upfronthosting.co.za> Glenn Jones added the comment: On Ubuntu 13.10, using python3 did not install the dependencies (apt reported using the python3-defaults source package instead of python3). The python3.4, package does not exist, but the python3.3 package did work. This may be that we're specifying the wrong package or that the upstream Ubuntu package has a bug or maybe we just need to use the specific package depending on what's available in the ubuntu version. barry, what do you think? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 17:07:22 2014 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 14 Apr 2014 15:07:22 +0000 Subject: [issue12546] builtin __format__ methods cannot fill with \x00 char In-Reply-To: <1310540286.71.0.346156272109.issue12546@psf.upfronthosting.co.za> Message-ID: <1397488042.81.0.278124406161.issue12546@psf.upfronthosting.co.za> Changes by Eric V. Smith : ---------- type: enhancement -> behavior versions: +Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 17:19:54 2014 From: report at bugs.python.org (Kushal Das) Date: Mon, 14 Apr 2014 15:19:54 +0000 Subject: [issue17498] error responses from server are masked in smtplib when server closes connection In-Reply-To: <1363812510.09.0.989538319205.issue17498@psf.upfronthosting.co.za> Message-ID: <1397488794.29.0.573090404023.issue17498@psf.upfronthosting.co.za> Kushal Das added the comment: New version of the patch which can be successfully applied to tip. ---------- Added file: http://bugs.python.org/file34817/issue17498_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 17:20:59 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 14 Apr 2014 15:20:59 +0000 Subject: [issue20624] Clarify recommendation to inherit from Exception In-Reply-To: <1392377489.91.0.767550317256.issue20624@psf.upfronthosting.co.za> Message-ID: <3g6tnk5sgkzQ5y@mail.python.org> Roundup Robot added the comment: New changeset 8dc1b45bd467 by Mark Dickinson in branch '3.4': Issue #20624: Exception docs wording tweak - clarify that it's okay to inherit from a subclass of Exception. http://hg.python.org/cpython/rev/8dc1b45bd467 New changeset 262204877004 by Mark Dickinson in branch 'default': Issue #20624: Merge exception docs tweak from 3.4 branch. http://hg.python.org/cpython/rev/262204877004 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 17:21:21 2014 From: report at bugs.python.org (Eric Snow) Date: Mon, 14 Apr 2014 15:21:21 +0000 Subject: [issue20434] Process crashes if not enough memory to import module In-Reply-To: <1390984600.38.0.476358983499.issue20434@psf.upfronthosting.co.za> Message-ID: <1397488881.86.0.238150849994.issue20434@psf.upfronthosting.co.za> Eric Snow added the comment: For example, in the patch binascii_b2a_uu() in Modules/binascii.c no longer sets rv to NULL even though in one of the _PyString_Resize() error cases rv is not automatically set to NULL. And simply setting rv to NULL would be backward-incompatible as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 17:23:28 2014 From: report at bugs.python.org (Matt Chaput) Date: Mon, 14 Apr 2014 15:23:28 +0000 Subject: [issue6623] Lib/ftplib.py Netrc class should be removed. In-Reply-To: <1249165781.68.0.418938928921.issue6623@psf.upfronthosting.co.za> Message-ID: <1397489008.57.0.41012382255.issue6623@psf.upfronthosting.co.za> Matt Chaput added the comment: This patch is the same as my previous one, except instead of removing Netrc usage from the ftplib.test() function, it replaces it with the netrc.netrc object. Note that there are no existing tests for the ftplib.test() function. Also did some very minor cleanups (bare raise is no longer valid) to get rid of warnings/errors in static analyzer. ---------- Added file: http://bugs.python.org/file34818/remove_Netrc_class2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 17:25:25 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 14 Apr 2014 15:25:25 +0000 Subject: [issue12546] builtin __format__ methods cannot fill with \x00 char In-Reply-To: <1310540286.71.0.346156272109.issue12546@psf.upfronthosting.co.za> Message-ID: <3g6tts0YlJzQ5y@mail.python.org> Roundup Robot added the comment: New changeset 520ce42ba2b8 by Eric V. Smith in branch '2.7': Issue #12546: Allow \x00 as a fill character for builtin type __format__ methods. http://hg.python.org/cpython/rev/520ce42ba2b8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 17:27:04 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 14 Apr 2014 15:27:04 +0000 Subject: [issue20968] mock.MagicMock does not mock __truediv__ In-Reply-To: <1395152014.45.0.112877741.issue20968@psf.upfronthosting.co.za> Message-ID: <3g6twl3lYwzQ5y@mail.python.org> Roundup Robot added the comment: New changeset 445ef3b58109 by Michael Foord in branch '3.4': Issue 20968. unittest.mock.MagicMock now supports division http://hg.python.org/cpython/rev/445ef3b58109 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 17:30:41 2014 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Mon, 14 Apr 2014 15:30:41 +0000 Subject: [issue20434] Process crashes if not enough memory to import module In-Reply-To: <1390984600.38.0.476358983499.issue20434@psf.upfronthosting.co.za> Message-ID: <1397489441.09.0.730477275405.issue20434@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: This is _PyString_Resize(). I don't immediatlly see an error case where the string isn't freed: int _PyString_Resize(PyObject **pv, Py_ssize_t newsize) { register PyObject *v; register PyStringObject *sv; v = *pv; if (!PyString_Check(v) || Py_REFCNT(v) != 1 || newsize < 0 || PyString_CHECK_INTERNED(v)) { *pv = 0; Py_DECREF(v); PyErr_BadInternalCall(); return -1; } /* XXX UNREF/NEWREF interface should be more symmetrical */ _Py_DEC_REFTOTAL; _Py_ForgetReference(v); *pv = (PyObject *) PyObject_REALLOC((char *)v, PyStringObject_SIZE + newsize); if (*pv == NULL) { PyObject_Del(v); PyErr_NoMemory(); return -1; } _Py_NewReference(*pv); sv = (PyStringObject *) *pv; Py_SIZE(sv) = newsize; sv->ob_sval[newsize] = '\0'; sv->ob_shash = -1; /* invalidate cached hash value */ return 0; } ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 17:34:04 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 14 Apr 2014 15:34:04 +0000 Subject: [issue20624] Clarify recommendation to inherit from Exception In-Reply-To: <1392377489.91.0.767550317256.issue20624@psf.upfronthosting.co.za> Message-ID: <3g6v4q3j5Pz7LjP@mail.python.org> Roundup Robot added the comment: New changeset f729a0e90c4f by Mark Dickinson in branch '2.7': Issue #20624: Merge exception docs tweak from 3.4 branch. http://hg.python.org/cpython/rev/f729a0e90c4f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 17:35:34 2014 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 14 Apr 2014 15:35:34 +0000 Subject: [issue20624] Clarify recommendation to inherit from Exception In-Reply-To: <1392377489.91.0.767550317256.issue20624@psf.upfronthosting.co.za> Message-ID: <1397489734.05.0.562219304177.issue20624@psf.upfronthosting.co.za> Mark Dickinson added the comment: Fixed. Closing. ---------- resolution: -> fixed status: open -> closed versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 17:39:04 2014 From: report at bugs.python.org (Michael Foord) Date: Mon, 14 Apr 2014 15:39:04 +0000 Subject: [issue17826] Setting a side_effect on mock from create_autospec doesn't work In-Reply-To: <1366797608.02.0.0150366437779.issue17826@psf.upfronthosting.co.za> Message-ID: <1397489944.95.0.697608444865.issue17826@psf.upfronthosting.co.za> Michael Foord added the comment: Can you explain why we need to check for the call_count here? I don't understand why this is needed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 17:39:57 2014 From: report at bugs.python.org (Marek Stepniowski) Date: Mon, 14 Apr 2014 15:39:57 +0000 Subject: [issue12220] minidom xmlns not handling spaces in xmlns attribute value field In-Reply-To: <1306789573.92.0.875996944294.issue12220@psf.upfronthosting.co.za> Message-ID: <1397489997.3.0.66906029375.issue12220@psf.upfronthosting.co.za> Marek Stepniowski added the comment: Added test to amathew's patch. ---------- nosy: +mstepniowski Added file: http://bugs.python.org/file34819/minidom_space_char_in_namespace_with_test.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 17:40:56 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Mon, 14 Apr 2014 15:40:56 +0000 Subject: [issue7776] http.client.HTTPConnection tunneling is broken In-Reply-To: <1264394042.86.0.571652227077.issue7776@psf.upfronthosting.co.za> Message-ID: <1397490056.07.0.842893223123.issue7776@psf.upfronthosting.co.za> Senthil Kumaran added the comment: I verified the patch and this indeed corrects a nasty bug in sending a wrong header when doing it a lower level HTTPSConnection to proxy and set_tunnel (bad term) to the end host..I was worried as why we did not observe this earlier and it seems to me that the advertised way to do HTTPS CONNECT is via Proxy Handler or urllib.request and when doing it via a ProxyHandler, these wierdly named action (set_tunnel) happen underneath, but the skip_hosts bit is set as we got headers from the higher level method. and the host header is carried transparently to the tunnel connection request and thus we escaped this. The patch fixes the problem and cleans up a bit. Thanks for that , Nikolaus. This code (http/client.py) will require more attention beyond this bug too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 17:44:42 2014 From: report at bugs.python.org (Michael Foord) Date: Mon, 14 Apr 2014 15:44:42 +0000 Subject: [issue20968] mock.MagicMock does not mock __truediv__ In-Reply-To: <1395152014.45.0.112877741.issue20968@psf.upfronthosting.co.za> Message-ID: <1397490282.21.0.263716272909.issue20968@psf.upfronthosting.co.za> Michael Foord added the comment: Thanks! ---------- assignee: -> michael.foord resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 17:46:08 2014 From: report at bugs.python.org (Sam Lucidi) Date: Mon, 14 Apr 2014 15:46:08 +0000 Subject: [issue15104] Unclear language in __main__ description In-Reply-To: <1340092965.02.0.675870286607.issue15104@psf.upfronthosting.co.za> Message-ID: <1397490368.2.0.288258037028.issue15104@psf.upfronthosting.co.za> Sam Lucidi added the comment: I've attempted to synthesize the ideas in this thread into a clearer explanation of __main__. What I've written doesn't attempt to explain anything else about module naming, but it does try to address the common package and module uses of __main__. ---------- keywords: +patch nosy: +mansam Added file: http://bugs.python.org/file34820/clarify-__main__-documentation.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 18:01:34 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 14 Apr 2014 16:01:34 +0000 Subject: [issue15104] Unclear language in __main__ description In-Reply-To: <1340092965.02.0.675870286607.issue15104@psf.upfronthosting.co.za> Message-ID: <1397491294.78.0.377454560177.issue15104@psf.upfronthosting.co.za> R. David Murray added the comment: I've made some review comments. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 18:01:54 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 14 Apr 2014 16:01:54 +0000 Subject: [issue15104] Unclear language in __main__ description In-Reply-To: <1340092965.02.0.675870286607.issue15104@psf.upfronthosting.co.za> Message-ID: <1397491314.88.0.534357393386.issue15104@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- stage: needs patch -> patch review versions: +Python 3.5 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 18:08:18 2014 From: report at bugs.python.org (Toshio Kuratomi) Date: Mon, 14 Apr 2014 16:08:18 +0000 Subject: [issue4963] mimetypes.guess_extension result changes after mimetypes.init() In-Reply-To: <1232107494.83.0.0570958889295.issue4963@psf.upfronthosting.co.za> Message-ID: <1397491698.31.0.403471422154.issue4963@psf.upfronthosting.co.za> Toshio Kuratomi added the comment: Took a look at this and was able to reproduce it on Fedora Linux 20 and current cpython head. It is somewhat random though. I'm able to get reasonably consistent failures using image/jpeg and iterating the test case about 20 times. Additionally, it looks like the data structure that mimetypes.guess_extensions() is reading its extensions from is a list so it doesn't have to do with dictionary sort order. It has something to do with the way the extensions are read in from the files and then given to add_type(). Talking to r.david.murray I think that this particular problem can be solved by simply sorting the list of extensions prior to guess_extension taking the first extension off of the list. The question of what to do when the first extension in the list isn't the best extension should be resolved in Issue1043134. I'll attach a patch with test case for this problem. ---------- nosy: +a.badger Added file: http://bugs.python.org/file34821/issue4963.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 18:08:28 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 14 Apr 2014 16:08:28 +0000 Subject: [issue12546] builtin __format__ methods cannot fill with \x00 char In-Reply-To: <1310540286.71.0.346156272109.issue12546@psf.upfronthosting.co.za> Message-ID: <3g6vrX2Vnkz7Ljn@mail.python.org> Roundup Robot added the comment: New changeset 7c484551bce1 by Eric V. Smith in branch '3.4': Issue #12546: Allow \x00 as a fill character for builtin type __format__ methods. http://hg.python.org/cpython/rev/7c484551bce1 New changeset bd90e68dc81f by Eric V. Smith in branch 'default': Closes issue #12546: Allow \x00 as a fill character for builtin type __format__ methods. http://hg.python.org/cpython/rev/bd90e68dc81f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 18:09:44 2014 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 14 Apr 2014 16:09:44 +0000 Subject: [issue12546] builtin __format__ methods cannot fill with \x00 char In-Reply-To: <1310540286.71.0.346156272109.issue12546@psf.upfronthosting.co.za> Message-ID: <1397491784.06.0.232059929351.issue12546@psf.upfronthosting.co.za> Eric V. Smith added the comment: Fixed in 2.7, 3.4, 3.5. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 18:10:55 2014 From: report at bugs.python.org (Sam Lucidi) Date: Mon, 14 Apr 2014 16:10:55 +0000 Subject: [issue15104] Unclear language in __main__ description In-Reply-To: <1340092965.02.0.675870286607.issue15104@psf.upfronthosting.co.za> Message-ID: <1397491855.28.0.213070014535.issue15104@psf.upfronthosting.co.za> Sam Lucidi added the comment: Thanks, I've revised the change based on your comments. ---------- Added file: http://bugs.python.org/file34822/clarify-__main__-documentation.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 18:20:27 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 14 Apr 2014 16:20:27 +0000 Subject: [issue15916] change doctest DocTestSuite not to raise ValueError if no docstrings In-Reply-To: <1347321295.19.0.66061447718.issue15916@psf.upfronthosting.co.za> Message-ID: <1397492427.72.0.629439670465.issue15916@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- Removed message: http://bugs.python.org/msg174145 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 18:20:36 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 14 Apr 2014 16:20:36 +0000 Subject: [issue15916] change doctest DocTestSuite not to raise ValueError if no docstrings In-Reply-To: <1347321295.19.0.66061447718.issue15916@psf.upfronthosting.co.za> Message-ID: <1397492436.16.0.932565128567.issue15916@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- Removed message: http://bugs.python.org/msg174146 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 18:49:34 2014 From: report at bugs.python.org (jonathan ferretti) Date: Mon, 14 Apr 2014 16:49:34 +0000 Subject: [issue18518] return-ing within code timed with timeit.timeit causes wrong return value of timeit.timeit In-Reply-To: <1374400020.0.0.45788018989.issue18518@psf.upfronthosting.co.za> Message-ID: <1397494174.89.0.815689373994.issue18518@psf.upfronthosting.co.za> jonathan ferretti added the comment: Added note to timeit function briefly explaining how to avoid it the issue and the cause ---------- keywords: +patch nosy: +jonathan.ferretti type: enhancement -> behavior Added file: http://bugs.python.org/file34823/timeit.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 18:53:09 2014 From: report at bugs.python.org (Matt Chaput) Date: Mon, 14 Apr 2014 16:53:09 +0000 Subject: [issue21198] Minor tarfile documentation bug In-Reply-To: <1397148227.41.0.631676560193.issue21198@psf.upfronthosting.co.za> Message-ID: <1397494389.36.0.588887654788.issue21198@psf.upfronthosting.co.za> Matt Chaput added the comment: Simple patch to remove the underscore in tarfile.rst. ---------- keywords: +patch nosy: +maatt Added file: http://bugs.python.org/file34824/issue21198.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 18:54:57 2014 From: report at bugs.python.org (Matt Chaput) Date: Mon, 14 Apr 2014 16:54:57 +0000 Subject: [issue21146] update gzip usage examples in docs In-Reply-To: <1396521606.53.0.161098821761.issue21146@psf.upfronthosting.co.za> Message-ID: <1397494497.22.0.444231942153.issue21146@psf.upfronthosting.co.za> Matt Chaput added the comment: The patch looks good to me. ---------- nosy: +maatt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 18:56:18 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 14 Apr 2014 16:56:18 +0000 Subject: [issue17009] "Thread Programming With Python" should be removed In-Reply-To: <1358799622.32.0.0901338309925.issue17009@psf.upfronthosting.co.za> Message-ID: <1397494578.74.0.496681015593.issue17009@psf.upfronthosting.co.za> R. David Murray added the comment: Well, with the new website the url now returns a 404, so I guess we can close this. If someone wants to see it restored as a historical document, that would be an issue for the web site bug tracker. But, since other essays exist, it looks like it was a conscious decision on someone's part to omit this one. ---------- nosy: +r.david.murray resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 18:58:30 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 14 Apr 2014 16:58:30 +0000 Subject: [issue20480] Add ipaddress property to get name of reverse DNS PTR record In-Reply-To: <1391304148.19.0.350065852039.issue20480@psf.upfronthosting.co.za> Message-ID: <3g6wyF3Cj7z7LjS@mail.python.org> Roundup Robot added the comment: New changeset 5992d2c9522c by Eric V. Smith in branch 'default': Issue #20480: Add ipaddress.reverse_pointer. Patch by Leon Weber. http://hg.python.org/cpython/rev/5992d2c9522c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 18:59:19 2014 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 14 Apr 2014 16:59:19 +0000 Subject: [issue20480] Add ipaddress property to get name of reverse DNS PTR record In-Reply-To: <1391304148.19.0.350065852039.issue20480@psf.upfronthosting.co.za> Message-ID: <1397494759.59.0.937223372053.issue20480@psf.upfronthosting.co.za> Changes by Eric V. Smith : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 19:07:41 2014 From: report at bugs.python.org (Kushal Das) Date: Mon, 14 Apr 2014 17:07:41 +0000 Subject: [issue17660] mock.patch could whitelist builtins to not need create=True In-Reply-To: <1365418089.99.0.0976801798706.issue17660@psf.upfronthosting.co.za> Message-ID: <1397495261.95.0.878169718807.issue17660@psf.upfronthosting.co.za> Kushal Das added the comment: Updated patch with builtins module. ---------- versions: +Python 3.4 -Python 3.5 Added file: http://bugs.python.org/file34825/issue17660_v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 19:10:27 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 14 Apr 2014 17:10:27 +0000 Subject: [issue7776] http.client.HTTPConnection tunneling is broken In-Reply-To: <1264394042.86.0.571652227077.issue7776@psf.upfronthosting.co.za> Message-ID: <3g6xD25Y1pz7Ljj@mail.python.org> Roundup Robot added the comment: New changeset 39ee3286d187 by Senthil Kumaran in branch '3.4': Issue #7776: Fix ``Host:'' header and reconnection when using http.client.HTTPConnection.set_tunnel(). http://hg.python.org/cpython/rev/39ee3286d187 New changeset 2c9af09ba7b8 by Senthil Kumaran in branch 'default': merge from 3.4 http://hg.python.org/cpython/rev/2c9af09ba7b8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 19:12:12 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 14 Apr 2014 17:12:12 +0000 Subject: [issue21215] build-deps instructions for Ubuntu In-Reply-To: <1397485129.87.0.0518806030798.issue21215@psf.upfronthosting.co.za> Message-ID: <1397495532.16.0.809052442239.issue21215@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: The `python3` binary package is a sort of meta package that brings in the interpreter (and some ancillary stuff) for all supported Python 3 versions. For Ubuntu 14.04 that will be just python3.4. But if you want to build the interpreter from source (e.g. an hg clone) on an Ubuntu system, you'll need to bring in the Build-Depends for the specific interpreter package you want. That would be python3.4 or python3.3, etc. It's generally okay to `sudo apt-get build-dep python3.3` on a-pre-14.04 Ubuntu to get all the build-deps for Python 3.4. There maybe something you'll need to install manually, but I can't think of what that is. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 19:12:34 2014 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 14 Apr 2014 17:12:34 +0000 Subject: [issue13598] string.Formatter doesn't support empty curly braces "{}" In-Reply-To: <1323835162.4.0.792542335688.issue13598@psf.upfronthosting.co.za> Message-ID: <1397495554.25.0.333288284188.issue13598@psf.upfronthosting.co.za> Changes by Eric V. Smith : ---------- versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 19:14:06 2014 From: report at bugs.python.org (Ned Deily) Date: Mon, 14 Apr 2014 17:14:06 +0000 Subject: [issue17009] "Thread Programming With Python" should be removed In-Reply-To: <1358799622.32.0.0901338309925.issue17009@psf.upfronthosting.co.za> Message-ID: <1397495646.21.0.098667350487.issue17009@psf.upfronthosting.co.za> Ned Deily added the comment: I don't think it was a conscious decision. Unlike most of the others, the link for this essay is to the 2.2 docs tree. I'm guessing there was a redirect there that has gone AWOL. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 19:14:23 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Mon, 14 Apr 2014 17:14:23 +0000 Subject: [issue7776] http.client.HTTPConnection tunneling is broken In-Reply-To: <1264394042.86.0.571652227077.issue7776@psf.upfronthosting.co.za> Message-ID: <1397495663.42.0.459991454772.issue7776@psf.upfronthosting.co.za> Senthil Kumaran added the comment: This is fixed in 3.4 and 3.5 (finally). I will port it to 2.7 as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 19:16:36 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 14 Apr 2014 17:16:36 +0000 Subject: [issue21209] q.put(some_tuple) fails when PYTHONASYNCIODEBUG=1 In-Reply-To: <1397351442.01.0.248805040826.issue21209@psf.upfronthosting.co.za> Message-ID: <1397495796.82.0.937495289753.issue21209@psf.upfronthosting.co.za> Benjamin Peterson added the comment: 3.3 is in security-fix only mode. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 19:19:39 2014 From: report at bugs.python.org (Eric Snow) Date: Mon, 14 Apr 2014 17:19:39 +0000 Subject: [issue20434] Process crashes if not enough memory to import module In-Reply-To: <1390984600.38.0.476358983499.issue20434@psf.upfronthosting.co.za> Message-ID: <1397495979.63.0.739671743361.issue20434@psf.upfronthosting.co.za> Eric Snow added the comment: Yeah, I missed the "*pv = 0;" line in the first error case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 19:20:05 2014 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 14 Apr 2014 17:20:05 +0000 Subject: [issue21209] q.put(some_tuple) fails when PYTHONASYNCIODEBUG=1 In-Reply-To: <1397351442.01.0.248805040826.issue21209@psf.upfronthosting.co.za> Message-ID: <1397496004.99.0.732803559545.issue21209@psf.upfronthosting.co.za> Yury Selivanov added the comment: > 3.3 is in security-fix only mode. Yeah, but this is a core language bug. I believe some people may be stuck on 3.3 with broken 'yield from' for whatever reason, which will cause hard to find bugs in 3.3 compatible libraries (like asyncio/tulip). I think we can lift the security-only restriction for this specific patch, no? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 19:21:43 2014 From: report at bugs.python.org (Julien Palard) Date: Mon, 14 Apr 2014 17:21:43 +0000 Subject: [issue21216] getaddrinfo is wrongly considered thread safe on linux Message-ID: <1397496103.55.0.0681287877532.issue21216@psf.upfronthosting.co.za> New submission from Julien Palard: I just found that python consider linux implementation of getaddrinfo thread safe : ./python2.6-2.6.8/Modules/socketmodule.c:180 /* On systems on which getaddrinfo() is believed to not be thread-safe, (this includes the getaddrinfo emulation) protect access with a lock. */ #if defined(WITH_THREAD) && (defined(__APPLE__) || \ (defined(__FreeBSD__) && __FreeBSD_version+0 < 503000) || \ defined(__OpenBSD__) || defined(__NetBSD__) || \ defined(__VMS) || !defined(HAVE_GETADDRINFO)) #define USE_GETADDRINFO_LOCK #endif Badly, it's wrong on my version of linux, and maybe others : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=722075 So for me, looping in three threads on getaddrinfo leads me to a rapid deadlock, while reading on a NETLINK socket, after another thread wrote a DNS query on it and trying to get a response on it. It may only be reproductible when your getaddrinfo use a NETLINK to get informations about your interfaces before doing the DNS query. ---------- messages: 216121 nosy: Julien.Palard priority: normal severity: normal status: open title: getaddrinfo is wrongly considered thread safe on linux _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 19:22:50 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 14 Apr 2014 17:22:50 +0000 Subject: [issue21209] q.put(some_tuple) fails when PYTHONASYNCIODEBUG=1 In-Reply-To: <1397496004.99.0.732803559545.issue21209@psf.upfronthosting.co.za> Message-ID: <1397496167.19222.106380065.6BAC0344@webmail.messagingengine.com> Benjamin Peterson added the comment: On Mon, Apr 14, 2014, at 10:20, Yury Selivanov wrote: > > Yury Selivanov added the comment: > > > 3.3 is in security-fix only mode. > > Yeah, but this is a core language bug. I believe some people may be stuck > on 3.3 with broken 'yield from' for whatever reason, which will cause > hard to find bugs in 3.3 compatible libraries (like asyncio/tulip). I > think we can lift the security-only restriction for this specific patch, > no? I don't really have an opinion on this nor is it my call; I'm just regurgitating policy. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 19:23:50 2014 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 14 Apr 2014 17:23:50 +0000 Subject: [issue17009] "Thread Programming With Python" should be removed In-Reply-To: <1358799622.32.0.0901338309925.issue17009@psf.upfronthosting.co.za> Message-ID: <1397496230.7.0.993140270864.issue17009@psf.upfronthosting.co.za> Changes by Guido van Rossum : ---------- nosy: -gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 19:25:00 2014 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 14 Apr 2014 17:25:00 +0000 Subject: [issue21015] support SSL_CTX_set_ecdh_auto on newer OpenSSLs In-Reply-To: <1395455671.92.0.144736574461.issue21015@psf.upfronthosting.co.za> Message-ID: <1397496300.14.0.976511282438.issue21015@psf.upfronthosting.co.za> Mark Dickinson added the comment: The docs[1] for SSL_set_ecdh_auto say: "These functions were first added to OpenSSL 1.0.2." From looking at Modules/_ssl.c, it looks as though we're trying to use them when the version is >= 0.9.8. [1] ftp://ftp.ulakbim.gov.tr/pub/openssl/docs/ssl/SSL_CTX_set1_curves.html ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 19:25:35 2014 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 14 Apr 2014 17:25:35 +0000 Subject: [issue21209] q.put(some_tuple) fails when PYTHONASYNCIODEBUG=1 In-Reply-To: <1397351442.01.0.248805040826.issue21209@psf.upfronthosting.co.za> Message-ID: <1397496335.34.0.353649536078.issue21209@psf.upfronthosting.co.za> Guido van Rossum added the comment: I think I have to add a work-around to Tulip anyway, because I don't want to have to tell people "you must upgrade your Python 3.3 otherwise this problem can happen" (if upgrading was easy for them they would be on 3.4 :-). So I don't care much if the 3.3 backport happens. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 19:25:44 2014 From: report at bugs.python.org (Sam Lucidi) Date: Mon, 14 Apr 2014 17:25:44 +0000 Subject: [issue18628] Better index entry for encoding declarations In-Reply-To: <1375418984.87.0.318628832877.issue18628@psf.upfronthosting.co.za> Message-ID: <1397496344.11.0.546657287462.issue18628@psf.upfronthosting.co.za> Sam Lucidi added the comment: Here's a patch which changes the entry in the index to "encoding declarations (source file)" per Terry's third point. ---------- keywords: +patch nosy: +mansam Added file: http://bugs.python.org/file34826/encoding-declarations-index.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 19:27:15 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 14 Apr 2014 17:27:15 +0000 Subject: [issue21015] support SSL_CTX_set_ecdh_auto on newer OpenSSLs In-Reply-To: <1397496300.14.0.976511282438.issue21015@psf.upfronthosting.co.za> Message-ID: <534C1A70.3020402@free.fr> Antoine Pitrou added the comment: > The docs[1] for SSL_set_ecdh_auto say: "These functions were first added to OpenSSL 1.0.2." From looking at Modules/_ssl.c, it looks as though we're trying to use them when the version is >= 0.9.8. If that was the issue at hand we would get a compile error, no? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 19:31:00 2014 From: report at bugs.python.org (Thomas Ballinger) Date: Mon, 14 Apr 2014 17:31:00 +0000 Subject: [issue21217] inspect.getsourcelines finds wrong lines when lambda used argument to decorator Message-ID: <1397496660.33.0.566497694968.issue21217@psf.upfronthosting.co.za> New submission from Thomas Ballinger: https://gist.github.com/thomasballinger/10666031 """ inspect.getsourcelines incorrectly guesses what lines correspond to the function foo see getblock in inspect.py once it finds a lambda, def or class it finishes it then stops so get getsourcelines returns only the first two noop decorator lines of bar, while normal behavior is to return all decorators as it does for foo """ import inspect from pprint import pprint def noop(arg): def inner(func): return func return inner @noop(1) @noop(2) def foo(): return 1 @noop(1) @noop(lambda: None) @noop(1) def bar(): return 1 pprint(inspect.getsourcelines(foo)) pprint(inspect.getsourcelines(bar)) ---------- components: Library (Lib) messages: 216127 nosy: ballingt priority: normal severity: normal status: open title: inspect.getsourcelines finds wrong lines when lambda used argument to decorator type: behavior versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 19:36:00 2014 From: report at bugs.python.org (Thomas Ballinger) Date: Mon, 14 Apr 2014 17:36:00 +0000 Subject: [issue21217] inspect.getsourcelines finds wrong lines when lambda used argument to decorator In-Reply-To: <1397496660.33.0.566497694968.issue21217@psf.upfronthosting.co.za> Message-ID: <1397496960.54.0.997146007377.issue21217@psf.upfronthosting.co.za> Thomas Ballinger added the comment: "The code object's co_lnotab is how inspect should be getting the sourcelines of the code, instead of looking for the first codeblock." I'm looking at this now, thanks to Yhg1s for the above. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 19:40:06 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 14 Apr 2014 17:40:06 +0000 Subject: [issue18518] return-ing within code timed with timeit.timeit causes wrong return value of timeit.timeit In-Reply-To: <1374400020.0.0.45788018989.issue18518@psf.upfronthosting.co.za> Message-ID: <3g6xtD4zqNz7LjQ@mail.python.org> Roundup Robot added the comment: New changeset 7e2708484ea5 by Andrew Kuchling in branch '3.4': #18518: mention that including a return statement changes/breaks the behaviour http://hg.python.org/cpython/rev/7e2708484ea5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 19:40:13 2014 From: report at bugs.python.org (Matt Chaput) Date: Mon, 14 Apr 2014 17:40:13 +0000 Subject: [issue20491] textwrap: Non-breaking space not honored In-Reply-To: <1391373997.78.0.616228125857.issue20491@psf.upfronthosting.co.za> Message-ID: <1397497213.23.0.206607869898.issue20491@psf.upfronthosting.co.za> Matt Chaput added the comment: Patch on top of dbudinova's that attempts to replace the concatenation of strings with a verbose regex. ---------- nosy: +maatt Added file: http://bugs.python.org/file34827/issue20491_verbose.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 19:40:18 2014 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 14 Apr 2014 17:40:18 +0000 Subject: [issue21015] support SSL_CTX_set_ecdh_auto on newer OpenSSLs In-Reply-To: <1395455671.92.0.144736574461.issue21015@psf.upfronthosting.co.za> Message-ID: <1397497218.72.0.535596058062.issue21015@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- Removed message: http://bugs.python.org/msg216123 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 19:40:40 2014 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 14 Apr 2014 17:40:40 +0000 Subject: [issue21015] support SSL_CTX_set_ecdh_auto on newer OpenSSLs In-Reply-To: <1395455671.92.0.144736574461.issue21015@psf.upfronthosting.co.za> Message-ID: <1397496300.14.0.976511282438.issue21015@psf.upfronthosting.co.za> Mark Dickinson added the comment: The docs[1] for SSL_set_ecdh_auto say: "These functions were first added to OpenSSL 1.0.2." From looking at Modules/_ssl.c, it looks as though we're trying to use them when the version is >= 0.9.8. [1] ftp://ftp.ulakbim.gov.tr/pub/openssl/docs/ssl/SSL_CTX_set1_curves.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 19:40:49 2014 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 14 Apr 2014 17:40:49 +0000 Subject: [issue21015] support SSL_CTX_set_ecdh_auto on newer OpenSSLs In-Reply-To: <1395455671.92.0.144736574461.issue21015@psf.upfronthosting.co.za> Message-ID: <1397497249.81.0.429259733212.issue21015@psf.upfronthosting.co.za> Mark Dickinson added the comment: Yep, true. Ignore me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 19:40:58 2014 From: report at bugs.python.org (Caelyn McAulay) Date: Mon, 14 Apr 2014 17:40:58 +0000 Subject: [issue11983] Inconsistent hash and comparison for code objects In-Reply-To: <1304388682.39.0.687842914438.issue11983@psf.upfronthosting.co.za> Message-ID: <1397497258.73.0.887225638953.issue11983@psf.upfronthosting.co.za> Caelyn McAulay added the comment: Here is a patch to add the requested documentation to code.h - I expanded it to specify (as per the conversation in this issue) that co_name is used in both hash and comparisons while co_firstlineno is used only in comparisons. I do not attempt explain the inconsistency; but let the comment reflect reality. ---------- keywords: +patch nosy: +math_foo Added file: http://bugs.python.org/file34828/comment11983.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 19:46:50 2014 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Mon, 14 Apr 2014 17:46:50 +0000 Subject: [issue20434] Process crashes if not enough memory to import module In-Reply-To: <1390984600.38.0.476358983499.issue20434@psf.upfronthosting.co.za> Message-ID: <1397497610.16.0.938077544655.issue20434@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Ok, are we good to go then? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 19:47:39 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 14 Apr 2014 17:47:39 +0000 Subject: [issue21215] build-deps instructions for Ubuntu In-Reply-To: <1397485129.87.0.0518806030798.issue21215@psf.upfronthosting.co.za> Message-ID: <1397497659.44.0.923281747785.issue21215@psf.upfronthosting.co.za> R. David Murray added the comment: OK, so the devguide currently has sudo apt-get build-dep python3 which did something on Glenn's machine, but did not enable him to build the optional packages. So the question is, what should we put in the devguide as the correct build-dep to install? Is it build-dep for the same version as the system python for that particular system? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 19:49:47 2014 From: report at bugs.python.org (jmaki) Date: Mon, 14 Apr 2014 17:49:47 +0000 Subject: [issue21204] published examples don't work In-Reply-To: <1397267440.3.0.253901505287.issue21204@psf.upfronthosting.co.za> Message-ID: <1397497787.7.0.397495327613.issue21204@psf.upfronthosting.co.za> jmaki added the comment: loewis, r.david.murray: Please proceed in terms of #3--"The specific example does not work on Windows". I am using python 2.7.6 on Windows 7. Below is the failing message that happens immediately on startup, specifically, when hitting this line: Process(target=serve_forever, args=(server,)).start() Thank you for the attention. ----- error message ----- Traceback (most recent call last): File "C:/Python27/httpthreadpool.py", line 75, in test() File "C:/Python27/httpthreadpool.py", line 70, in test runpool(ADDRESS, NUMBER_OF_PROCESSES) File "C:/Python27/httpthreadpool.py", line 51, in runpool Process(target=serve_forever, args=(server,)).start() File "C:\Python27\lib\multiprocessing\process.py", line 130, in start self._popen = Popen(self) File "C:\Python27\lib\multiprocessing\forking.py", line 277, in __init__ dump(process_obj, to_child, HIGHEST_PROTOCOL) File "C:\Python27\lib\multiprocessing\forking.py", line 199, in dump ForkingPickler(file, protocol).dump(obj) File "C:\Python27\lib\pickle.py", line 224, in dump self.save(obj) File "C:\Python27\lib\pickle.py", line 331, in save self.save_reduce(obj=obj, *rv) File "C:\Python27\lib\pickle.py", line 419, in save_reduce save(state) File "C:\Python27\lib\pickle.py", line 286, in save f(self, obj) # Call unbound method with explicit self File "C:\Python27\lib\pickle.py", line 649, in save_dict self._batch_setitems(obj.iteritems()) File "C:\Python27\lib\pickle.py", line 681, in _batch_setitems save(v) File "C:\Python27\lib\pickle.py", line 286, in save f(self, obj) # Call unbound method with explicit self File "C:\Python27\lib\pickle.py", line 548, in save_tuple save(element) File "C:\Python27\lib\pickle.py", line 286, in save f(self, obj) # Call unbound method with explicit self File "C:\Python27\lib\pickle.py", line 725, in save_inst save(stuff) File "C:\Python27\lib\pickle.py", line 286, in save f(self, obj) # Call unbound method with explicit self File "C:\Python27\lib\pickle.py", line 649, in save_dict self._batch_setitems(obj.iteritems()) File "C:\Python27\lib\pickle.py", line 681, in _batch_setitems save(v) File "C:\Python27\lib\pickle.py", line 331, in save self.save_reduce(obj=obj, *rv) File "C:\Python27\lib\pickle.py", line 419, in save_reduce save(state) File "C:\Python27\lib\pickle.py", line 286, in save f(self, obj) # Call unbound method with explicit self File "C:\Python27\lib\pickle.py", line 649, in save_dict self._batch_setitems(obj.iteritems()) File "C:\Python27\lib\pickle.py", line 681, in _batch_setitems save(v) File "C:\Python27\lib\pickle.py", line 331, in save self.save_reduce(obj=obj, *rv) File "C:\Python27\lib\pickle.py", line 419, in save_reduce save(state) File "C:\Python27\lib\pickle.py", line 286, in save f(self, obj) # Call unbound method with explicit self File "C:\Python27\lib\pickle.py", line 649, in save_dict self._batch_setitems(obj.iteritems()) File "C:\Python27\lib\pickle.py", line 681, in _batch_setitems save(v) File "C:\Python27\lib\pickle.py", line 331, in save self.save_reduce(obj=obj, *rv) File "C:\Python27\lib\pickle.py", line 396, in save_reduce save(cls) File "C:\Python27\lib\pickle.py", line 286, in save f(self, obj) # Call unbound method with explicit self File "C:\Python27\lib\pickle.py", line 748, in save_global (obj, module, name)) PicklingError: Can't pickle : it's not found as thread.lock ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 19:53:49 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 14 Apr 2014 17:53:49 +0000 Subject: [issue17660] mock.patch could whitelist builtins to not need create=True In-Reply-To: <1365418089.99.0.0976801798706.issue17660@psf.upfronthosting.co.za> Message-ID: <1397498029.76.0.065964624119.issue17660@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 19:54:39 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 14 Apr 2014 17:54:39 +0000 Subject: [issue18518] return-ing within code timed with timeit.timeit causes wrong return value of timeit.timeit In-Reply-To: <1374400020.0.0.45788018989.issue18518@psf.upfronthosting.co.za> Message-ID: <1397498079.22.0.0372480378871.issue18518@psf.upfronthosting.co.za> R. David Murray added the comment: The suggestion was to make this a footnote, not a note. Also, it should probably say that the stmt is executed inside a function, meaning that instead of being a syntax error it changes the return value of the internal timeit function. I understand Raymond's desire not to clutter the docs, but I consider the footnote worth it, not to pre-inform the user, but to let them know that it is not a bug if they check the docs *after* things don't work right. It may be naive of me to think that they would do so. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 19:57:04 2014 From: report at bugs.python.org (Christian Hudon) Date: Mon, 14 Apr 2014 17:57:04 +0000 Subject: [issue15370] test_runpy should include namespace package tests In-Reply-To: <1342448771.76.0.81603722524.issue15370@psf.upfronthosting.co.za> Message-ID: <1397498224.16.0.00522137000321.issue15370@psf.upfronthosting.co.za> Christian Hudon added the comment: As far as I can see, this is now tested by the following tests in test_runpy: test_run_module_in_namespace_package test_run_package_in_namespace_package test_run_namespace_package test_run_namespace_package_in_namespace_package (These new tests were in introduced in revision 87961, on Dec 15th, 2013.) Can someone who knows more about CPython's implementation confirm that these tests do cover what was intended with this bug report (and then close the bug), or if not, flesh out the bug report with what's missing, and I'll do my best to add the missing tests. ---------- nosy: +chrish42 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 19:57:20 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 14 Apr 2014 17:57:20 +0000 Subject: [issue21215] build-deps instructions for Ubuntu In-Reply-To: <1397485129.87.0.0518806030798.issue21215@psf.upfronthosting.co.za> Message-ID: <1397498240.12.0.780373978899.issue21215@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 19:57:48 2014 From: report at bugs.python.org (Jeff Ramnani) Date: Mon, 14 Apr 2014 17:57:48 +0000 Subject: [issue21218] Test failure for test_ssl.test_default_ecdh_curve on OS X Message-ID: <1397498268.54.0.53776547909.issue21218@psf.upfronthosting.co.za> New submission from Jeff Ramnani: The unittest, test_ssl.test_default_ecdh_curve, is failing on OS X (and FreeBSD 9). The test fails with the error message: """ ====================================================================== ERROR: test_default_ecdh_curve (test.test_ssl.ThreadedTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/jramnani/code/cpython/Lib/test/test_ssl.py", line 2596, in test_default_ecdh_curve context.set_ciphers("ECDH") ssl.SSLError: ('No cipher can be selected.',) ---------------------------------------------------------------------- """ It looks to be related to issue, #21015 (changesets 3b81d1b3f9d1 and 869277faf3dc). OS Info: * Version: OS X 10.9.2 * OpenSSL version: OpenSSL 0.9.8y 5 Feb 2013 The problem looks like OpenSSL on OS X is reporting that it has ECDH when it does not. Python 3.5.0a0 (default:8cf384852680, Apr 14 2014, 13:32:46) [GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.38)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import ssl >>> ssl.HAS_ECDH True ---------- components: Tests messages: 216138 nosy: jramnani priority: normal severity: normal status: open title: Test failure for test_ssl.test_default_ecdh_curve on OS X versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 19:59:31 2014 From: report at bugs.python.org (Ned Deily) Date: Mon, 14 Apr 2014 17:59:31 +0000 Subject: [issue21218] Test failure for test_ssl.test_default_ecdh_curve on OS X In-Reply-To: <1397498268.54.0.53776547909.issue21218@psf.upfronthosting.co.za> Message-ID: <1397498371.62.0.6097138623.issue21218@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks for the report. This is being tracked in Issue21015. ---------- nosy: +ned.deily resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> support SSL_CTX_set_ecdh_auto on newer OpenSSLs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 20:00:48 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 14 Apr 2014 18:00:48 +0000 Subject: [issue18628] Better index entry for encoding declarations In-Reply-To: <1375418984.87.0.318628832877.issue18628@psf.upfronthosting.co.za> Message-ID: <1397498448.52.0.894707510037.issue18628@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo stage: needs patch -> patch review versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 20:00:56 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Mon, 14 Apr 2014 18:00:56 +0000 Subject: [issue18518] return-ing within code timed with timeit.timeit causes wrong return value of timeit.timeit In-Reply-To: <1374400020.0.0.45788018989.issue18518@psf.upfronthosting.co.za> Message-ID: <1397498456.29.0.10445435325.issue18518@psf.upfronthosting.co.za> A.M. Kuchling added the comment: I dislike footnotes and prefer to put things in the text whenever possible. The text for this change struck as relevant enough -- it notes a property of the *stmt* parameter -- that it doesn't belong in a footnote. (I'd be happy to just make it a paragraph instead of a highlighted note: I dislike notes too!) ---------- nosy: +akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 20:01:13 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Mon, 14 Apr 2014 18:01:13 +0000 Subject: [issue18518] return-ing within code timed with timeit.timeit causes wrong return value of timeit.timeit In-Reply-To: <1374400020.0.0.45788018989.issue18518@psf.upfronthosting.co.za> Message-ID: <1397498473.95.0.149664197696.issue18518@psf.upfronthosting.co.za> A.M. Kuchling added the comment: BTW, this change is also relevant to 2.7. Previously I wouldn't have bothered to commit it to 2.7 since the branch was largely closed, but now we're talking about some corporate maintainer eventually going through and backporting fixes to the newly-extended 2.7 branch. So should I go ahead and apply it to 2.7? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 20:03:18 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 14 Apr 2014 18:03:18 +0000 Subject: [issue19980] Improve help('non-topic') response In-Reply-To: <1386984892.27.0.919528696836.issue19980@psf.upfronthosting.co.za> Message-ID: <1397498598.07.0.0981081234346.issue19980@psf.upfronthosting.co.za> Terry J. Reedy added the comment: help() uses lib/pydoc.py and pydoc tests are in test/test_pydoc.py I think tests for things help does that pydoc does not do (help on topics?) should be in site.py. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 20:07:06 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 14 Apr 2014 18:07:06 +0000 Subject: [issue21215] build-deps instructions for Ubuntu In-Reply-To: <1397497659.44.0.923281747785.issue21215@psf.upfronthosting.co.za> Message-ID: <20140414140609.7b704b10@anarchist.localdomain> Barry A. Warsaw added the comment: On Apr 14, 2014, at 05:47 PM, R. David Murray wrote: >OK, so the devguide currently has > > sudo apt-get build-dep python3 > >which did something on Glenn's machine, but did not enable him to build the >optional packages. So the question is, what should we put in the devguide as >the correct build-dep to install? Is it build-dep for the same version as >the system python for that particular system? I guess I would recommend: $ sudo apt-get build-dep python3.4 with a fallback to $ sudo apt-get build-dep python3.3 The drag is if they have a really old version which only has python3.2, or an even newer future version that has only python3.5. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 20:07:19 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 14 Apr 2014 18:07:19 +0000 Subject: [issue21146] update gzip usage examples in docs In-Reply-To: <1396521606.53.0.161098821761.issue21146@psf.upfronthosting.co.za> Message-ID: <1397498839.66.0.970428091575.issue21146@psf.upfronthosting.co.za> ?ric Araujo added the comment: Isn?t there a buffering argument in open that can be used to avoid line buffering? ---------- nosy: +eric.araujo versions: +Python 3.5 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 20:07:20 2014 From: report at bugs.python.org (Glenn Jones) Date: Mon, 14 Apr 2014 18:07:20 +0000 Subject: [issue15916] change doctest DocTestSuite not to raise ValueError if no docstrings In-Reply-To: <1347321295.19.0.66061447718.issue15916@psf.upfronthosting.co.za> Message-ID: <1397498840.05.0.12729264762.issue15916@psf.upfronthosting.co.za> Glenn Jones added the comment: I've attached a patch that uses the original default DocTestFinder and does not raise an exception when there are no tests. ---------- nosy: +Glenn.Jones Added file: http://bugs.python.org/file34829/issue15916-no-exception.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 20:11:40 2014 From: report at bugs.python.org (Zachary Ware) Date: Mon, 14 Apr 2014 18:11:40 +0000 Subject: [issue20035] Clean up Tcl library discovery in Tkinter on Windows In-Reply-To: <1387557050.08.0.350325342144.issue20035@psf.upfronthosting.co.za> Message-ID: <1397499100.53.0.477905646858.issue20035@psf.upfronthosting.co.za> Zachary Ware added the comment: Ok, debugging again with better breakpoints, I see what I missed before, so here's a new patch that does things a little differently. This patch sets the TCL_LIBRARY envvar just before calling Tcl_FindExecutable, and unsets it after the call. The $tcl_library Tcl var is set after interpreter creation, as in the previous patch. Both places do nothing if TCL_LIBRARY envvar is already set or the Tcl library isn't in one of the two expected locations. I attempted to get things to work by setting Tcl's encoding search path before the call to Tcl_FindExecutable, but doing so seems to require some part of the initialization done by Tcl_FindExecutable. I would much prefer a solution that doesn't mess around with the TCL_LIBRARY envvar at all, but I've had no luck with it. ---------- Added file: http://bugs.python.org/file34830/issue20035.v4.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 20:12:21 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Mon, 14 Apr 2014 18:12:21 +0000 Subject: [issue7776] http.client.HTTPConnection tunneling is broken In-Reply-To: <1264394042.86.0.571652227077.issue7776@psf.upfronthosting.co.za> Message-ID: <1397499141.63.0.506567191211.issue7776@psf.upfronthosting.co.za> Changes by Senthil Kumaran : ---------- resolution: -> fixed stage: test needed -> committed/rejected versions: +Python 3.5 -Python 2.7, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 20:12:52 2014 From: report at bugs.python.org (Sam Lucidi) Date: Mon, 14 Apr 2014 18:12:52 +0000 Subject: [issue15104] Unclear language in __main__ description In-Reply-To: <1340092965.02.0.675870286607.issue15104@psf.upfronthosting.co.za> Message-ID: <1397499172.19.0.486385933524.issue15104@psf.upfronthosting.co.za> Changes by Sam Lucidi : Added file: http://bugs.python.org/file34831/clarify-__main__-documentation-backticks.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 20:12:57 2014 From: report at bugs.python.org (Andrew Scheller) Date: Mon, 14 Apr 2014 18:12:57 +0000 Subject: [issue21198] Minor tarfile documentation bug In-Reply-To: <1397148227.41.0.631676560193.issue21198@psf.upfronthosting.co.za> Message-ID: <1397499177.95.0.286368198042.issue21198@psf.upfronthosting.co.za> Andrew Scheller added the comment: ?ric - appears to be only Doc/library/tarfile.rst that is affected. Matt - looks like your "simple patch" contains a lot more than you intended?! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 20:13:01 2014 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 14 Apr 2014 18:13:01 +0000 Subject: [issue21209] q.put(some_tuple) fails when PYTHONASYNCIODEBUG=1 In-Reply-To: <1397351442.01.0.248805040826.issue21209@psf.upfronthosting.co.za> Message-ID: <1397499181.7.0.15773259654.issue21209@psf.upfronthosting.co.za> Yury Selivanov added the comment: Guido: please take a look at the patch "corowrapper_01.patch". ---------- Added file: http://bugs.python.org/file34832/corowrapper_01.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 20:16:10 2014 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Mon, 14 Apr 2014 18:16:10 +0000 Subject: [issue21219] WARNING: Inline literal start-string without end-string. Message-ID: <1397499370.92.0.332930990444.issue21219@psf.upfronthosting.co.za> New submission from St?phane Wirtel: When I build the documentation, I get a warning about the NEWS file. Just add a new patch for this warning. > (sphinx) make html sphinx-build -b html -d build/doctrees -D latex_paper_size= . build/html Making output directory... Running Sphinx v1.2.2 loading pickled environment... not yet created building [html]: targets for 455 source files that are out of date updating environment: 455 added, 0 changed, 0 removed reading sources... [100%] whatsnew/index ../../Misc/NEWS:44: WARNING: Inline literal start-string without end-string. looking for now-outdated files... none found pickling environment... done checking consistency... done preparing documents... done ---------- assignee: docs at python components: Documentation messages: 216149 nosy: docs at python, matrixise priority: normal severity: normal status: open title: WARNING: Inline literal start-string without end-string. type: compile error versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 20:17:02 2014 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Mon, 14 Apr 2014 18:17:02 +0000 Subject: [issue21219] WARNING: Inline literal start-string without end-string. In-Reply-To: <1397499370.92.0.332930990444.issue21219@psf.upfronthosting.co.za> Message-ID: <1397499422.41.0.473193017999.issue21219@psf.upfronthosting.co.za> St?phane Wirtel added the comment: Here is the patch for this bug. ---------- keywords: +patch Added file: http://bugs.python.org/file34833/issue21219_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 20:19:31 2014 From: report at bugs.python.org (Zachary Ware) Date: Mon, 14 Apr 2014 18:19:31 +0000 Subject: [issue21219] WARNING: Inline literal start-string without end-string. In-Reply-To: <1397499370.92.0.332930990444.issue21219@psf.upfronthosting.co.za> Message-ID: <1397499571.3.0.739988225155.issue21219@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 20:20:15 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 14 Apr 2014 18:20:15 +0000 Subject: [issue11983] Inconsistent hash and comparison for code objects In-Reply-To: <1304388682.39.0.687842914438.issue11983@psf.upfronthosting.co.za> Message-ID: <3g6ymZ3pFKz7LjS@mail.python.org> Roundup Robot added the comment: New changeset 0e35cef1d984 by Andrew Kuchling in branch 'default': #11983: update comment to describe which fields are used and why. http://hg.python.org/cpython/rev/0e35cef1d984 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 20:21:26 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Mon, 14 Apr 2014 18:21:26 +0000 Subject: [issue11983] Inconsistent hash and comparison for code objects In-Reply-To: <1304388682.39.0.687842914438.issue11983@psf.upfronthosting.co.za> Message-ID: <1397499686.37.0.198713929617.issue11983@psf.upfronthosting.co.za> A.M. Kuchling added the comment: Thanks for the patch! ---------- assignee: -> akuchling nosy: +akuchling resolution: -> fixed stage: -> committed/rejected status: open -> closed versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 20:21:57 2014 From: report at bugs.python.org (Sam Kimbrel) Date: Mon, 14 Apr 2014 18:21:57 +0000 Subject: [issue10481] subprocess PIPEs are byte streams In-Reply-To: <1290319024.08.0.519309863324.issue10481@psf.upfronthosting.co.za> Message-ID: <1397499717.3.0.836867393453.issue10481@psf.upfronthosting.co.za> Sam Kimbrel added the comment: I've created a patch that updates the docs to reflect the behavior of communicate() and check_output(), which is that both the "input" argument and stdin/stdout/stderr PIPEs will convert to and from strings when self.univeral_newlines is True and must be bytes otherwise. ---------- keywords: +patch nosy: +sam.kimbrel Added file: http://bugs.python.org/file34834/10481-subprocess-docs.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 20:22:49 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Mon, 14 Apr 2014 18:22:49 +0000 Subject: [issue21219] WARNING: Inline literal start-string without end-string. In-Reply-To: <1397499370.92.0.332930990444.issue21219@psf.upfronthosting.co.za> Message-ID: <1397499769.26.0.925181339471.issue21219@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Oops did not notice. Thanks for catching. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 20:22:58 2014 From: report at bugs.python.org (Rafael Mejia) Date: Mon, 14 Apr 2014 18:22:58 +0000 Subject: [issue20874] Tutorial section on starting python is out of date In-Reply-To: <1394379932.36.0.812758095306.issue20874@psf.upfronthosting.co.za> Message-ID: <1397499778.8.0.472643413854.issue20874@psf.upfronthosting.co.za> Rafael Mejia added the comment: Please review that attached patch. Feedback is welcome. ---------- keywords: +patch nosy: +Israfil Added file: http://bugs.python.org/file34835/issue_20874.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 20:23:08 2014 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Mon, 14 Apr 2014 18:23:08 +0000 Subject: [issue21220] Enhance obmalloc allocation strategy Message-ID: <1397499786.06.0.606856949694.issue21220@psf.upfronthosting.co.za> New submission from Kristj?n Valur J?nsson: A new allocation policy, "lowest address strategy" improves fragmentation of memory in obmalloc. pools with available memory are chosen by lowest address preference. This increases the likelihood that unused pools are released to their corresponding arenas. Arenas with available pools are similarly chosen by lowest address. This significantly helps fragmentation in programs with dynamic memory usage, e.g. long running programs. Initial tests also indicate some minor performance benefits of the pybench, probably due to better cache behaviour. ---------- components: Interpreter Core files: obmalloc.patch keywords: patch messages: 216156 nosy: kristjan.jonsson priority: normal severity: normal status: open title: Enhance obmalloc allocation strategy type: resource usage versions: Python 3.5 Added file: http://bugs.python.org/file34836/obmalloc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 20:27:16 2014 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 14 Apr 2014 18:27:16 +0000 Subject: [issue21209] q.put(some_tuple) fails when PYTHONASYNCIODEBUG=1 In-Reply-To: <1397351442.01.0.248805040826.issue21209@psf.upfronthosting.co.za> Message-ID: <1397500036.46.0.0316398217199.issue21209@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 20:29:01 2014 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Mon, 14 Apr 2014 18:29:01 +0000 Subject: [issue4744] asynchat documentation needs to be more precise In-Reply-To: <1230168171.56.0.381937953807.issue4744@psf.upfronthosting.co.za> Message-ID: <1397500141.43.0.674025238291.issue4744@psf.upfronthosting.co.za> St?phane Wirtel added the comment: Could you review your patch, there is a mistake in the name of the project, it's asynchat and not asychat. The content seems to be right, not the reference and the title. Thank you so much for your help. ---------- nosy: +matrixise versions: +Python 3.5 -Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 20:29:20 2014 From: report at bugs.python.org (Andrew Scheller) Date: Mon, 14 Apr 2014 18:29:20 +0000 Subject: [issue21221] Minor struct_time documentation bug Message-ID: <1397500160.88.0.743491348049.issue21221@psf.upfronthosting.co.za> New submission from Andrew Scheller: The documentation for time.struct_time (in Doc/library/time.rst) explains tm_isdst as "0, 1 or -1; see below" but then doesn't really go into further detail below, other than to say "A -1 argument as the daylight savings flag, passed to mktime() will usually result in the correct daylight savings state to be filled in.". In Modules/timemodule.c there's a section which says: {"tm_isdst", "1 if summer time is in effect, 0 if not, and -1 if unknown"}, IMHO it would be nice if this more accurate info was also present in the HTML documentation. ---------- assignee: docs at python components: Documentation messages: 216158 nosy: docs at python, lurchman priority: normal severity: normal status: open title: Minor struct_time documentation bug type: enhancement versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 20:29:29 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Mon, 14 Apr 2014 18:29:29 +0000 Subject: [issue19546] configparser leaks implementation detail In-Reply-To: <1384103812.47.0.904880324738.issue19546@psf.upfronthosting.co.za> Message-ID: <1397500169.54.0.822534114367.issue19546@psf.upfronthosting.co.za> Claudiu.Popa added the comment: If there is anything left to do for this patch, please tell me. ---------- Added file: http://bugs.python.org/file34837/issue19546.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 20:29:56 2014 From: report at bugs.python.org (Eric Snow) Date: Mon, 14 Apr 2014 18:29:56 +0000 Subject: [issue20434] Process crashes if not enough memory to import module In-Reply-To: <1390984600.38.0.476358983499.issue20434@psf.upfronthosting.co.za> Message-ID: <1397500196.09.0.55685170251.issue20434@psf.upfronthosting.co.za> Eric Snow added the comment: Okay from me, but Victor has a better idea of the string APIs. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 20:34:37 2014 From: report at bugs.python.org (Ned Deily) Date: Mon, 14 Apr 2014 18:34:37 +0000 Subject: [issue10224] Build 3.x documentation using python3.x In-Reply-To: <1288304199.49.0.7053863257.issue10224@psf.upfronthosting.co.za> Message-ID: <1397500477.45.0.551759251549.issue10224@psf.upfronthosting.co.za> Ned Deily added the comment: For 3.4.1 and 3.5, the Doc/Makefile no longer explicitly vendors sphinx and its dependencies (via svn), rather it assumes that an externally-supplied sphinx-build is available, for example, via a venv and pip. And the current versions of sphinx and its dependencies are all supported on current Py3's. So can this issue be closed, Georg? ---------- assignee: docs at python -> nosy: +ned.deily versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 20:35:02 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Mon, 14 Apr 2014 18:35:02 +0000 Subject: [issue21219] WARNING: Inline literal start-string without end-string. In-Reply-To: <1397499370.92.0.332930990444.issue21219@psf.upfronthosting.co.za> Message-ID: <1397500502.08.0.641847856648.issue21219@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Fixed: 3.5 a85606b6de32 3.4 fb5516cbc522 ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed type: compile error -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 20:35:45 2014 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 14 Apr 2014 18:35:45 +0000 Subject: [issue8060] PEP 3101 string formatting missing engineering presentation type for floating point In-Reply-To: <1267733568.91.0.590819765764.issue8060@psf.upfronthosting.co.za> Message-ID: <1397500545.58.0.853219551686.issue8060@psf.upfronthosting.co.za> Eric V. Smith added the comment: After discussing this with Mark at the sprints, I'm going to close this. If someone comes up with a concrete proposal on python-ideas, we can revisit it. But as it is, there's not enough here to go on. There are a sufficient number of ideas and alternatives that it might warrant a PEP to record all of the decisions and tradeoffs. ---------- resolution: -> rejected stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 20:36:05 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 14 Apr 2014 18:36:05 +0000 Subject: [issue21216] getaddrinfo is wrongly considered thread safe on linux In-Reply-To: <1397496103.55.0.0681287877532.issue21216@psf.upfronthosting.co.za> Message-ID: <1397500565.89.0.577092685157.issue21216@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- assignee: -> gregory.p.smith nosy: +gregory.p.smith versions: +Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 20:38:01 2014 From: report at bugs.python.org (Kushal Das) Date: Mon, 14 Apr 2014 18:38:01 +0000 Subject: [issue17826] Setting a side_effect on mock from create_autospec doesn't work In-Reply-To: <1366797608.02.0.0150366437779.issue17826@psf.upfronthosting.co.za> Message-ID: <1397500681.09.0.0317693168362.issue17826@psf.upfronthosting.co.za> Kushal Das added the comment: New patch with fix in proper place for side_effect for functions (includes test case). ---------- versions: +Python 3.3 -Python 3.5 Added file: http://bugs.python.org/file34838/issue17826_v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 20:39:40 2014 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 14 Apr 2014 18:39:40 +0000 Subject: [issue21199] Python on 64-bit Windows uses signed 32-bit type for read length In-Reply-To: <1397149133.44.0.946556558932.issue21199@psf.upfronthosting.co.za> Message-ID: <1397500780.97.0.354723151677.issue21199@psf.upfronthosting.co.za> Changes by Eric V. Smith : ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 20:41:14 2014 From: report at bugs.python.org (Brett Cannon) Date: Mon, 14 Apr 2014 18:41:14 +0000 Subject: [issue21199] Python on 64-bit Windows uses signed 32-bit type for read length In-Reply-To: <1397149133.44.0.946556558932.issue21199@psf.upfronthosting.co.za> Message-ID: <1397500874.34.0.392663239018.issue21199@psf.upfronthosting.co.za> Brett Cannon added the comment: We discussed this bug at the sprint and we all agreed that it should be fixed. It's an oversight and a bug that this behaviour is different between Windows and other platforms due to how 64-bit Windows treats longs. ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 20:41:54 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 14 Apr 2014 18:41:54 +0000 Subject: [issue20434] Process crashes if not enough memory to import module In-Reply-To: <1397500196.09.0.55685170251.issue20434@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: I'm busy right now with Pycon (I organize a sprint to port OpenStack to Python 3). I will try to review the patch later this week. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 20:42:03 2014 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Mon, 14 Apr 2014 18:42:03 +0000 Subject: [issue20434] Process crashes if not enough memory to import module In-Reply-To: <1390984600.38.0.476358983499.issue20434@psf.upfronthosting.co.za> Message-ID: <1397500923.11.0.309370375128.issue20434@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Sure, there was at least one case in the patch, where the string resize was consider optional, and the code tried to recover if it didn't succeed. But I don't think we should be trying to change apis, even internal ones in python 2.7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 20:47:14 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 14 Apr 2014 18:47:14 +0000 Subject: [issue21216] getaddrinfo is wrongly considered thread safe on linux In-Reply-To: <1397496103.55.0.0681287877532.issue21216@psf.upfronthosting.co.za> Message-ID: <1397501234.47.0.0371170684233.issue21216@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Can you attach some python code that reproduces this for you? According to both of the references below it doesn't sound like this is supposed to be a problem. http://pubs.opengroup.org/onlinepubs/9699919799/functions/freeaddrinfo.html claims "The freeaddrinfo() and getaddrinfo() functions shall be thread-safe." Linux man pages claim "getaddrinfo() is reentrant". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 20:49:51 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 14 Apr 2014 18:49:51 +0000 Subject: [issue15916] change doctest DocTestSuite not to raise ValueError if no docstrings In-Reply-To: <1347321295.19.0.66061447718.issue15916@psf.upfronthosting.co.za> Message-ID: <1397501391.1.0.436458407401.issue15916@psf.upfronthosting.co.za> R. David Murray added the comment: This looks good, however we also need a documentation change indicating the new behavior, including a '.. versionchanged:: 3.5' tag, and an entry in whatsnew/3.5 in the 'other changes' section. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 20:57:20 2014 From: report at bugs.python.org (Ned Deily) Date: Mon, 14 Apr 2014 18:57:20 +0000 Subject: [issue18650] intermittent test_pydoc failure on 3.4.0a1 In-Reply-To: <1375567563.7.0.0482703899635.issue18650@psf.upfronthosting.co.za> Message-ID: <1397501840.81.0.892633649935.issue18650@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks for noticing the errant setuptools egg in the --user site-packages location. That should not have been there. ---------- resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 20:58:51 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Mon, 14 Apr 2014 18:58:51 +0000 Subject: [issue10481] subprocess PIPEs are byte streams In-Reply-To: <1290319024.08.0.519309863324.issue10481@psf.upfronthosting.co.za> Message-ID: <1397501931.95.0.0966237306245.issue10481@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- versions: +Python 3.5 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 20:59:36 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 14 Apr 2014 18:59:36 +0000 Subject: [issue21204] multiprocessing example does not work on Windows In-Reply-To: <1397267440.3.0.253901505287.issue21204@psf.upfronthosting.co.za> Message-ID: <1397501976.45.0.549441680773.issue21204@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- title: published examples don't work -> multiprocessing example does not work on Windows _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 20:59:44 2014 From: report at bugs.python.org (Xavier de Gaye) Date: Mon, 14 Apr 2014 18:59:44 +0000 Subject: [issue21161] list comprehensions don't see local variables in pdb in python3 In-Reply-To: <1396698943.39.0.489151150852.issue21161@psf.upfronthosting.co.za> Message-ID: <1397501984.21.0.42166845241.issue21161@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Interestingly, the interact command was added at changeset: $ hg log -v --pager cat -r $(hg blame Lib/pdb.py | grep do_interact | awk -F : '{print $1}') changeset: 66691:c2578a68879d user: Georg Brandl date: Sat Dec 04 11:20:26 2010 +0000 files: Doc/library/pdb.rst Lib/pdb.py Misc/NEWS description: Add the "interact" pdb command from pdb++. And the included documentation, added at that time, states (emphasis added by me): Start an interative interpreter (using the code module) whose global namespace contains all the ***(global and local)*** names found in the current scope. I can provide a test case for the patch when this issue is re-opened, unless someone else is willing to do it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 21:00:24 2014 From: report at bugs.python.org (Christian Hudon) Date: Mon, 14 Apr 2014 19:00:24 +0000 Subject: [issue20103] Documentation of itertools.accumulate is confused In-Reply-To: <1388592720.87.0.970906154406.issue20103@psf.upfronthosting.co.za> Message-ID: <1397502024.19.0.0715521165939.issue20103@psf.upfronthosting.co.za> Christian Hudon added the comment: The following patch improves (I hope) the documentation of itertools.accumulate. Comments and feedback welcome. Terry, I did not implement your suggestion of changing "returns" to "yields", as it would have made things inconsistent with the documentation (and docstrings) of pretty much all the other generators in the itertools module, as they all use this idiom also. If one of the Python documentation experts thinks this change is also a good idea, please just open a new bug report for that and put me in the nosy list, and I'll do the change for all relevant generators in the itertools module. ---------- keywords: +patch nosy: +chrish42 Added file: http://bugs.python.org/file34839/accumulate_doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 21:00:48 2014 From: report at bugs.python.org (John Ehresman) Date: Mon, 14 Apr 2014 19:00:48 +0000 Subject: [issue21151] winreg.SetValueEx causes crash if value = None In-Reply-To: <1396581421.46.0.554143633373.issue21151@psf.upfronthosting.co.za> Message-ID: <1397502048.67.0.296612831316.issue21151@psf.upfronthosting.co.za> John Ehresman added the comment: Here's a simple patch with a test. Oddly, the test doesn't fail before the fix is applied when run with rt.bat, but fails when run directly. ---------- keywords: +patch nosy: +jpe Added file: http://bugs.python.org/file34840/fix-none-value.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 21:06:09 2014 From: report at bugs.python.org (Sam Kimbrel) Date: Mon, 14 Apr 2014 19:06:09 +0000 Subject: [issue20956] tokenize module claims tokenize.tokenize returns namedtuple, but it doesn't In-Reply-To: <1395057365.37.0.876415448459.issue20956@psf.upfronthosting.co.za> Message-ID: <1397502369.74.0.344581652074.issue20956@psf.upfronthosting.co.za> Sam Kimbrel added the comment: Attached patch to update 2.7 docs to refer to the plain-old-tuple returned from generate_tokens(). ---------- keywords: +patch nosy: +sam.kimbrel Added file: http://bugs.python.org/file34841/20956-tokenize-docs.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 21:06:17 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 14 Apr 2014 19:06:17 +0000 Subject: [issue15104] Unclear language in __main__ description In-Reply-To: <1340092965.02.0.675870286607.issue15104@psf.upfronthosting.co.za> Message-ID: <3g6znh4Wx0z7Lk7@mail.python.org> Roundup Robot added the comment: New changeset 4f23648b7c97 by R David Murray in branch '3.4': #15104: improve the discussion of __main__. http://hg.python.org/cpython/rev/4f23648b7c97 New changeset 94ac365bf1b7 by R David Murray in branch 'default': Merge: #15104: improve the discussion of __main__. http://hg.python.org/cpython/rev/94ac365bf1b7 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 21:07:33 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 14 Apr 2014 19:07:33 +0000 Subject: [issue15104] Unclear language in __main__ description In-Reply-To: <1340092965.02.0.675870286607.issue15104@psf.upfronthosting.co.za> Message-ID: <1397502453.2.0.377289178481.issue15104@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, Sam. I did not apply this to 2.7 because I'm not sure if the __main__.py is supported there. Can someone check? ---------- type: enhancement -> behavior versions: -Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 21:07:35 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 14 Apr 2014 19:07:35 +0000 Subject: [issue15104] Unclear language in __main__ description In-Reply-To: <1340092965.02.0.675870286607.issue15104@psf.upfronthosting.co.za> Message-ID: <1397502455.32.0.271123478634.issue15104@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, Sam. I did not apply this to 2.7 because I'm not sure if the __main__.py is supported there. Can someone check? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 21:07:55 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 14 Apr 2014 19:07:55 +0000 Subject: [issue15104] Unclear language in __main__ description In-Reply-To: <1340092965.02.0.675870286607.issue15104@psf.upfronthosting.co.za> Message-ID: <1397502475.58.0.481481117087.issue15104@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- Removed message: http://bugs.python.org/msg216177 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 21:08:42 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 14 Apr 2014 19:08:42 +0000 Subject: [issue10481] subprocess PIPEs are byte streams In-Reply-To: <1290319024.08.0.519309863324.issue10481@psf.upfronthosting.co.za> Message-ID: <3g6zrV0bc7z7LjQ@mail.python.org> Roundup Robot added the comment: New changeset 267fff541bda by Andrew Kuchling in branch 'default': #10481: describe universal_newlines' effect on communicate()/check_output() output (alternately bytes or strings) http://hg.python.org/cpython/rev/267fff541bda ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 21:09:34 2014 From: report at bugs.python.org (Kushal Das) Date: Mon, 14 Apr 2014 19:09:34 +0000 Subject: [issue17861] put opcode information in one place In-Reply-To: <1367162089.6.0.986391601417.issue17861@psf.upfronthosting.co.za> Message-ID: <1397502574.43.0.725227362839.issue17861@psf.upfronthosting.co.za> Kushal Das added the comment: New patch with .hgtouch file details. ---------- versions: +Python 3.4 -Python 3.5 Added file: http://bugs.python.org/file34842/issue17861_v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 21:10:18 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Mon, 14 Apr 2014 19:10:18 +0000 Subject: [issue10481] subprocess PIPEs are byte streams In-Reply-To: <1290319024.08.0.519309863324.issue10481@psf.upfronthosting.co.za> Message-ID: <1397502618.23.0.0228750729991.issue10481@psf.upfronthosting.co.za> A.M. Kuchling added the comment: Thanks for your patch! ---------- nosy: +akuchling resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 21:11:42 2014 From: report at bugs.python.org (Caelyn McAulay) Date: Mon, 14 Apr 2014 19:11:42 +0000 Subject: [issue15840] Ambiguity with regard to the effect of accessing a closed IOBase instance In-Reply-To: <1346524424.76.0.407141547435.issue15840@psf.upfronthosting.co.za> Message-ID: <1397502702.87.0.867205752599.issue15840@psf.upfronthosting.co.za> Caelyn McAulay added the comment: Changed documentation to state that ValueError should be raised if any operation (excluding close()) is called on a closed stream. This appears to be what is done in iobase.c; and some investigation of inheriting types (rawiobase, fileio, bufferedio, etc.) indicates that there is nowhere where an IOError is being raised instead. Sphinx documentation appears to already be update to date. Is there any known place where operations on a closed stream raise IOError? I am currently assuming no. ---------- keywords: +patch nosy: +math_foo Added file: http://bugs.python.org/file34843/comment15840.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 21:13:45 2014 From: report at bugs.python.org (Christian Hudon) Date: Mon, 14 Apr 2014 19:13:45 +0000 Subject: [issue1704474] optparse tests fail under Jython Message-ID: <1397502825.36.0.901766885049.issue1704474@psf.upfronthosting.co.za> Christian Hudon added the comment: Which version of Jython should I concentrate on to make these tests pass? The 2.5.4 release candidate, or the 2.7 beta? ---------- nosy: +chrish42 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 21:18:47 2014 From: report at bugs.python.org (John Ehresman) Date: Mon, 14 Apr 2014 19:18:47 +0000 Subject: [issue8901] Windows registry path not ignored with -E option In-Reply-To: <1275705565.03.0.753930892849.issue8901@psf.upfronthosting.co.za> Message-ID: <1397503127.54.0.177441593502.issue8901@psf.upfronthosting.co.za> John Ehresman added the comment: Is still an issue with importlib? At this point, I don't think this change can be made on 2.7 or 3.2. ---------- nosy: +jpe _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 21:19:30 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Mon, 14 Apr 2014 19:19:30 +0000 Subject: [issue17380] initproc return value is unclear In-Reply-To: <1362676337.45.0.36627137275.issue17380@psf.upfronthosting.co.za> Message-ID: <1397503170.13.0.291308253249.issue17380@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- keywords: +easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 21:24:00 2014 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Mon, 14 Apr 2014 19:24:00 +0000 Subject: [issue20874] Tutorial section on starting python is out of date In-Reply-To: <1394379932.36.0.812758095306.issue20874@psf.upfronthosting.co.za> Message-ID: <1397503440.2.0.255190786145.issue20874@psf.upfronthosting.co.za> St?phane Wirtel added the comment: In your patch, you do not explain how to enable the command line editing. Can you add this part, or just add the reference to the existing doc? ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 21:24:45 2014 From: report at bugs.python.org (Georg Brandl) Date: Mon, 14 Apr 2014 19:24:45 +0000 Subject: [issue10224] Build 3.x documentation using python3.x In-Reply-To: <1288304199.49.0.7053863257.issue10224@psf.upfronthosting.co.za> Message-ID: <1397503485.48.0.578735096789.issue10224@psf.upfronthosting.co.za> Georg Brandl added the comment: Yep, thanks for the reminder. ---------- resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 21:26:43 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 14 Apr 2014 19:26:43 +0000 Subject: [issue21204] multiprocessing example does not work on Windows In-Reply-To: <1397267440.3.0.253901505287.issue21204@psf.upfronthosting.co.za> Message-ID: <1397503603.75.0.708397922887.issue21204@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Ah, Python 2.7. Note that the example is gone in Python 3, as part of the large change in issue8713. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 21:27:02 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 14 Apr 2014 19:27:02 +0000 Subject: [issue21204] multiprocessing example does not work on Windows In-Reply-To: <1397267440.3.0.253901505287.issue21204@psf.upfronthosting.co.za> Message-ID: <1397503622.59.0.798047161523.issue21204@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- nosy: -loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 21:33:59 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 14 Apr 2014 19:33:59 +0000 Subject: [issue10965] dev task of documenting undocumented APIs In-Reply-To: <1295566423.14.0.859020697485.issue10965@psf.upfronthosting.co.za> Message-ID: <1397504039.45.0.691576317583.issue10965@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 21:36:13 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 14 Apr 2014 19:36:13 +0000 Subject: [issue10224] Build 3.x documentation using python3.x In-Reply-To: <1288304199.49.0.7053863257.issue10224@psf.upfronthosting.co.za> Message-ID: <1397504173.86.0.384846300811.issue10224@psf.upfronthosting.co.za> ?ric Araujo added the comment: Do we need to change Doc/Makefile to have ?PYTHON = python3? or even ?PYTHON = ./python? (so doctests run with the development version)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 21:37:23 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Mon, 14 Apr 2014 19:37:23 +0000 Subject: [issue14910] argparse: disable abbreviation In-Reply-To: <1337943742.57.0.897347214609.issue14910@psf.upfronthosting.co.za> Message-ID: <1397504243.05.0.0437681376681.issue14910@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 21:38:26 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 14 Apr 2014 19:38:26 +0000 Subject: [issue18401] Tests for pdb import ~/.pdbrc In-Reply-To: <1373261746.39.0.598108958249.issue18401@psf.upfronthosting.co.za> Message-ID: <1397504306.89.0.796891642712.issue18401@psf.upfronthosting.co.za> R. David Murray added the comment: Adding a parameter is an enhancement. Probably not a bad thing to have anyway, but it can only go in 3.5. Since this isn't something that causes problems for production code, that seems fine. (The alternative would be to say have a private class variable that the tests would set/reset, but that is pretty ugly). The final patch will need doc changes and a whatsnew entry. ---------- nosy: +r.david.murray type: behavior -> enhancement versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 21:53:32 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 14 Apr 2014 19:53:32 +0000 Subject: [issue8901] Windows registry path not ignored with -E option In-Reply-To: <1275705565.03.0.753930892849.issue8901@psf.upfronthosting.co.za> Message-ID: <1397505212.21.0.922634671137.issue8901@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I don't think importlib changed anything in that regard (since one of the goals was too keep compatibility with all the old behaviours). Indeed the patch probably needs to be retargetted for 3.5. ---------- nosy: +brett.cannon, eric.snow, ncoghlan, pitrou stage: -> patch review versions: +Python 3.5 -Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 21:54:11 2014 From: report at bugs.python.org (Kushal Das) Date: Mon, 14 Apr 2014 19:54:11 +0000 Subject: [issue21222] Mock create_autospec with name argument fails Message-ID: <1397505251.05.0.288307474202.issue21222@psf.upfronthosting.co.za> New submission from Kushal Das: >>> from unittest import mock >>> def b(): ... print("hello") ... >>> q = mock.create_autospec(b, name="a") Traceback (most recent call last): File "", line 1, in File "/home/kdas/code/python/cpython3/Lib/unittest/mock.py", line 2092, in create_autospec name=_name, **_kwargs) TypeError: type object got multiple values for keyword argument 'name' The issue was originally reported on mock bug tracker. I am working on a patch for the same. ---------- components: Library (Lib) messages: 216190 nosy: kushaldas priority: normal severity: normal status: open title: Mock create_autospec with name argument fails type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 21:57:35 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Mon, 14 Apr 2014 19:57:35 +0000 Subject: [issue14216] ImportError: No module named binascii In-Reply-To: <1331106438.0.0.366139924133.issue14216@psf.upfronthosting.co.za> Message-ID: <1397505455.94.0.0404736223472.issue14216@psf.upfronthosting.co.za> A.M. Kuchling added the comment: No traffic on bug in 2 years, and not clear if there's anything to fix. Closing. ---------- nosy: +akuchling resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 22:00:50 2014 From: report at bugs.python.org (Don DeZutter) Date: Mon, 14 Apr 2014 20:00:50 +0000 Subject: [issue20983] Python 3.4 'repair' Windows installation does not install pip & setuptools packages In-Reply-To: <1395248368.62.0.321132661018.issue20983@psf.upfronthosting.co.za> Message-ID: <1397505650.13.0.600725275604.issue20983@psf.upfronthosting.co.za> Don DeZutter added the comment: On Windows 7 SP1 x64 after having installed Python 3.3 (x64) in ?c:\Python33? and then subsequently installing Python 3.4 (x64) in ?c:\Python34?, and then uninstalling the Python 3.3 (x64) and I?m not sure what else I may have done, I can no longer do any of the following: Open an IDLE window using the Windows Start Menu; Uninstall, Change, or Repair Python 3.4 using Windows Programs and Features; Uninstall Python 3.4 using Windows Start Menu; Reinstall Python 3.4 using the current 3.4 .msi install program. I would like to go back to being able to do a forced fresh install. I am a Python newby so maybe I should open a new incident but I don?t know how to start one yet. Perhaps I should try the previously described reproduce procedure by doing the following: Rename or delete target installation folder and then rerun Python installation procedure to install. ---------- nosy: +DeZutter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 22:01:55 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 14 Apr 2014 20:01:55 +0000 Subject: [issue20956] tokenize module claims tokenize.tokenize returns namedtuple, but it doesn't In-Reply-To: <1395057365.37.0.876415448459.issue20956@psf.upfronthosting.co.za> Message-ID: <1397505715.0.0.269915506181.issue20956@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- assignee: docs at python -> terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 22:03:56 2014 From: report at bugs.python.org (Tatiana Al-Chueyr) Date: Mon, 14 Apr 2014 20:03:56 +0000 Subject: [issue17218] support title and description in argparse add_mutually_exclusive_group In-Reply-To: <1361061502.09.0.252084655816.issue17218@psf.upfronthosting.co.za> Message-ID: <1397505836.14.0.0450815765543.issue17218@psf.upfronthosting.co.za> Tatiana Al-Chueyr added the comment: My proposal is that both: - add_mutually_exclusive_group() - add_argument_group() print optional arguments in the same way when title and/or description are provided. I've attached a test case of the proposed behavior. Please, let me know if you have any objections or suggestions! :) I'm working on the implementation right now. Note: it is outside the existing Lib/test/test_argparse.py for clarifying the idea. BTW: thanks to r.david.murray for mentoring and discussing use cases! ---------- nosy: +paul.j3, r.david.murray, tati_alchueyr Added file: http://bugs.python.org/file34844/test_argparse_mutex_with_title.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 22:06:51 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Mon, 14 Apr 2014 20:06:51 +0000 Subject: =?utf-8?q?=5Bissue16537=5D_Python=E2=80=99s_setup=2Epy_raises_a_ValueErro?= =?utf-8?q?r_when_self=2Eextensions_is_empty?= In-Reply-To: <1353633257.31.0.391670680901.issue16537@psf.upfronthosting.co.za> Message-ID: <1397506011.73.0.552125012072.issue16537@psf.upfronthosting.co.za> A.M. Kuchling added the comment: Patch LGTM to me too; someone can probably just commit it. ---------- nosy: +akuchling stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 22:09:35 2014 From: report at bugs.python.org (jmaki) Date: Mon, 14 Apr 2014 20:09:35 +0000 Subject: [issue21204] multiprocessing example does not work on Windows In-Reply-To: <1397267440.3.0.253901505287.issue21204@psf.upfronthosting.co.za> Message-ID: <1397506175.74.0.337373284291.issue21204@psf.upfronthosting.co.za> jmaki added the comment: Upon further investigation, this may be related to: http://bugs.python.org/issue1378 However, it seems the issue is not checked-in to Windows release for 2.x? Regards, John ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 22:10:17 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 14 Apr 2014 20:10:17 +0000 Subject: [issue17826] Setting a side_effect on mock from create_autospec doesn't work In-Reply-To: <1366797608.02.0.0150366437779.issue17826@psf.upfronthosting.co.za> Message-ID: <3g71CX1mYhz7Ljd@mail.python.org> Roundup Robot added the comment: New changeset 1e3c64470629 by Michael Foord in branch '3.4': Issue 17826. Setting an iterable side_effect on a mock created by create_autospec now works http://hg.python.org/cpython/rev/1e3c64470629 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 22:10:47 2014 From: report at bugs.python.org (Michael Foord) Date: Mon, 14 Apr 2014 20:10:47 +0000 Subject: [issue17826] Setting a side_effect on mock from create_autospec doesn't work In-Reply-To: <1366797608.02.0.0150366437779.issue17826@psf.upfronthosting.co.za> Message-ID: <1397506247.96.0.0589883309844.issue17826@psf.upfronthosting.co.za> Changes by Michael Foord : ---------- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 22:17:44 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 14 Apr 2014 20:17:44 +0000 Subject: [issue20956] tokenize module claims tokenize.tokenize returns namedtuple, but it doesn't In-Reply-To: <1395057365.37.0.876415448459.issue20956@psf.upfronthosting.co.za> Message-ID: <3g71N80JVzz7LjS@mail.python.org> Roundup Robot added the comment: New changeset d4f5a88b94b4 by Terry Jan Reedy in branch '2.7': Closes #20956: 2.7 tokenize does not produce named tuples. Patch by Sam Kimbrel. http://hg.python.org/cpython/rev/d4f5a88b94b4 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 22:19:23 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 14 Apr 2014 20:19:23 +0000 Subject: [issue18518] return-ing within code timed with timeit.timeit causes wrong return value of timeit.timeit In-Reply-To: <1374400020.0.0.45788018989.issue18518@psf.upfronthosting.co.za> Message-ID: <1397506763.25.0.615482887178.issue18518@psf.upfronthosting.co.za> R. David Murray added the comment: OK, if you think it is worthwhile in the text, then sure. But yeah, not as a ..note. And yes, I think we should keep backporting relevant doc patches. Especially since Google results still land one on the 2.7 docs... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 22:21:01 2014 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 14 Apr 2014 20:21:01 +0000 Subject: [issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse) In-Reply-To: <1279836939.11.0.811316280273.issue9334@psf.upfronthosting.co.za> Message-ID: <1397506861.87.0.612985441602.issue9334@psf.upfronthosting.co.za> Changes by Eric V. Smith : ---------- versions: +Python 3.5 -Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 22:24:13 2014 From: report at bugs.python.org (Jeff Ramnani) Date: Mon, 14 Apr 2014 20:24:13 +0000 Subject: [issue21015] support SSL_CTX_set_ecdh_auto on newer OpenSSLs In-Reply-To: <1395455671.92.0.144736574461.issue21015@psf.upfronthosting.co.za> Message-ID: <1397507053.71.0.832208502674.issue21015@psf.upfronthosting.co.za> Jeff Ramnani added the comment: > Really? Apple's packaging looks almost criminal here. Apple has deprecated their bundled version of OpenSSL. This issue has more details, http://bugs.python.org/issue17128 ---------- nosy: +jramnani _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 22:25:13 2014 From: report at bugs.python.org (Matthias Klose) Date: Mon, 14 Apr 2014 20:25:13 +0000 Subject: [issue21223] fix test_site/test_startup_imports when some of the extensions are built as builtins Message-ID: <1397507113.83.0.846424139619.issue21223@psf.upfronthosting.co.za> New submission from Matthias Klose: fix test_site/test_startup_imports when some of the extensions are built as builtins. --- a/Lib/test/test_site.py Mon Apr 14 12:24:37 2014 -0400 +++ b/Lib/test/test_site.py Mon Apr 14 22:17:57 2014 +0200 @@ -459,7 +459,8 @@ # http://bugs.python.org/issue19218> collection_mods = {'_collections', 'collections', 'functools', 'heapq', 'itertools', 'keyword', 'operator', - 'reprlib', 'types', 'weakref'} + 'reprlib', 'types', 'weakref' + }.difference(sys.builtin_module_names) self.assertFalse(modules.intersection(collection_mods), stderr) the test now passes indepedent of the status of _collections (builtin or extension). ---------- components: Tests keywords: patch messages: 216200 nosy: doko, eric.snow priority: normal severity: normal stage: patch review status: open title: fix test_site/test_startup_imports when some of the extensions are built as builtins type: behavior versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 22:25:31 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 14 Apr 2014 20:25:31 +0000 Subject: [issue17660] mock.patch could whitelist builtins to not need create=True In-Reply-To: <1365418089.99.0.0976801798706.issue17660@psf.upfronthosting.co.za> Message-ID: <3g71Y63JZWz7LjT@mail.python.org> Roundup Robot added the comment: New changeset e457de60028c by Michael Foord in branch 'default': Closes issue 17660. You no longer need to explicitly pass create=True when patching builtin names. http://hg.python.org/cpython/rev/e457de60028c ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 22:26:32 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 14 Apr 2014 20:26:32 +0000 Subject: [issue1704474] optparse tests fail under Jython Message-ID: <1397507192.23.0.316499979805.issue1704474@psf.upfronthosting.co.za> R. David Murray added the comment: I'm guessing they've got a local fix in the release candidate and won't change even their test code there, so I'd guess the beta. But the jython folks would really be the ones to ask. Perhaps they will respond here (they are not at pycon). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 22:27:23 2014 From: report at bugs.python.org (Tatiana Al-Chueyr) Date: Mon, 14 Apr 2014 20:27:23 +0000 Subject: [issue17218] support title and description in argparse add_mutually_exclusive_group In-Reply-To: <1361061502.09.0.252084655816.issue17218@psf.upfronthosting.co.za> Message-ID: <1397507243.18.0.318799418529.issue17218@psf.upfronthosting.co.za> Changes by Tatiana Al-Chueyr : Removed file: http://bugs.python.org/file34844/test_argparse_mutex_with_title.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 22:28:56 2014 From: report at bugs.python.org (Tatiana Al-Chueyr) Date: Mon, 14 Apr 2014 20:28:56 +0000 Subject: [issue17218] support title and description in argparse add_mutually_exclusive_group In-Reply-To: <1361061502.09.0.252084655816.issue17218@psf.upfronthosting.co.za> Message-ID: <1397507336.8.0.463364232654.issue17218@psf.upfronthosting.co.za> Tatiana Al-Chueyr added the comment: uploading test file ---------- Added file: http://bugs.python.org/file34845/test_argparse_mutex_with_title.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 22:31:46 2014 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 14 Apr 2014 20:31:46 +0000 Subject: [issue21217] inspect.getsourcelines finds wrong lines when lambda used argument to decorator In-Reply-To: <1397496660.33.0.566497694968.issue21217@psf.upfronthosting.co.za> Message-ID: <1397507506.54.0.780887203349.issue21217@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 22:32:45 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 14 Apr 2014 20:32:45 +0000 Subject: [issue20307] Android's failure to expose SYS_* system call constants causes _posixsubprocess cross-compilation to fail In-Reply-To: <1390156070.61.0.536992358716.issue20307@psf.upfronthosting.co.za> Message-ID: <3g71jS3Pt2z7Lk6@mail.python.org> Roundup Robot added the comment: New changeset 211eeb97b352 by Gregory P. Smith in branch '3.4': Add conditional code for android's lack of definition of SYS_getdent64. http://hg.python.org/cpython/rev/211eeb97b352 New changeset 9f89958ded0a by Gregory P. Smith in branch 'default': Add conditional code for android's lack of definition of SYS_getdent64. http://hg.python.org/cpython/rev/9f89958ded0a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 22:39:37 2014 From: report at bugs.python.org (Christian Hudon) Date: Mon, 14 Apr 2014 20:39:37 +0000 Subject: [issue984870] curses: getmaxyx() breaks when the window shrinks Message-ID: <1397507977.24.0.479181629462.issue984870@psf.upfronthosting.co.za> Christian Hudon added the comment: I get the same traceback. The traceback happens only when the window is shrunk below the size specified in derwin(). It's easy to see this by changing the first and second arguments to the derwin call to something like 2, 2, and then you can resize the window to a much smaller size without getting this exception. (My curses.version is 2.2 also. Running on OSX Mavericks.) The getmaxyx() function reports the correct size when the window is shrunk. Also note that the upstream bug has been closed, with the comment "Not seen in python 2.7". So I think we can close this. Maybe we want to document the behavior of derwin() and related functions of raising _curses.error when the dimensions of the terminal are smaller than that of the window, though? (Or maybe raise a better exception?) That should probably be another bug report, though. ---------- nosy: +chrish42 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 22:42:34 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 14 Apr 2014 20:42:34 +0000 Subject: [issue20307] Android's failure to expose SYS_* system call constants causes _posixsubprocess cross-compilation to fail In-Reply-To: <1390156070.61.0.536992358716.issue20307@psf.upfronthosting.co.za> Message-ID: <1397508154.14.0.242215347863.issue20307@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 22:43:52 2014 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Mon, 14 Apr 2014 20:43:52 +0000 Subject: [issue21224] BaseHTTPRequestHandler, update the protocol version to http 1.1 by default? Message-ID: <1397508232.09.0.0337317788686.issue21224@psf.upfronthosting.co.za> New submission from St?phane Wirtel: Hi, With this issue, I would like to ask you to use the last version of the HTTP protocol in the BaseHTTPRequestHandler for Python 3.5. Because this one uses the version 1.0 of the protocol for the backward-compatibility. https://docs.python.org/3/library/http.server.html?highlight=protocol_version#http.server.BaseHTTPRequestHandler.protocol_version When we develop an web app with Flask/Werkzeug or an other tool, the default version of the protocol is "HTTP/1.0". If we use Gunicorn, the protocol version is HTTP/1.1 and not 1.0, but this one can support the old version. So, I propose to change the default version to the HTTP/1.1. It seems that the code of the server can handle this version without any problem. HTTP 1.0 - http://www.ietf.org/rfc/rfc1945.txt - 1996 HTTP 1.1 - http://www.ietf.org/rfc/rfc2616.txt - 1999 In 2014, I think we can move to HTTP 1.1 by default. Regards, Stephane ---------- components: Library (Lib) messages: 216206 nosy: matrixise priority: normal severity: normal status: open title: BaseHTTPRequestHandler, update the protocol version to http 1.1 by default? versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 22:44:00 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 14 Apr 2014 20:44:00 +0000 Subject: [issue13598] string.Formatter doesn't support empty curly braces "{}" In-Reply-To: <1323835162.4.0.792542335688.issue13598@psf.upfronthosting.co.za> Message-ID: <3g71yS0bw5z7Lk0@mail.python.org> Roundup Robot added the comment: New changeset ad74229a6fba by Eric V. Smith in branch '3.4': Issue #13598: Add auto-numbering of replacement fields to string.Formatter. http://hg.python.org/cpython/rev/ad74229a6fba ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 22:45:36 2014 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 14 Apr 2014 20:45:36 +0000 Subject: [issue13598] string.Formatter doesn't support empty curly braces "{}" In-Reply-To: <1323835162.4.0.792542335688.issue13598@psf.upfronthosting.co.za> Message-ID: <1397508336.0.0.972423166466.issue13598@psf.upfronthosting.co.za> Changes by Eric V. Smith : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 22:47:00 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 14 Apr 2014 20:47:00 +0000 Subject: [issue13598] string.Formatter doesn't support empty curly braces "{}" In-Reply-To: <1323835162.4.0.792542335688.issue13598@psf.upfronthosting.co.za> Message-ID: <3g721w0ckFz7LjX@mail.python.org> Roundup Robot added the comment: New changeset 50fe497983fd by Eric V. Smith in branch '3.4': Issue #13598: Added acknowledgements to Misc/NEWS. http://hg.python.org/cpython/rev/50fe497983fd ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 22:48:55 2014 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 14 Apr 2014 20:48:55 +0000 Subject: [issue21111] PyLong_AsUnsignedLongAndOverflow does not exist In-Reply-To: <1396272396.7.0.644063349125.issue21111@psf.upfronthosting.co.za> Message-ID: <1397508535.65.0.131666850459.issue21111@psf.upfronthosting.co.za> Mark Dickinson added the comment: Here's an updated patch, for PyLong_AsUnsignedLongAndOverflow only, including docs and tests. ---------- keywords: +patch Added file: http://bugs.python.org/file34846/pylong_as_unsigned_long_and_overflow.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 22:50:46 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Mon, 14 Apr 2014 20:50:46 +0000 Subject: [issue21225] io.py: Improve docstrings for classes Message-ID: <1397508646.21.0.210626779275.issue21225@psf.upfronthosting.co.za> New submission from A.M. Kuchling: io.py contains the following to declare ABCs for some of its classes: class IOBase(_io._IOBase, metaclass=abc.ABCMeta): pass (and similarly for RawIOBase, BufferedIOBase, TextIOBase). _io._IOBase has an extensive docstring, but IOBase doesn't. (Python doesn't inherit parent-class docstrings, on the theory that the subclass may change things that make the docstring invalid.) I propose the attached patch. ---------- files: io-copy-docstrings.patch keywords: easy, patch messages: 216210 nosy: akuchling priority: normal severity: normal stage: patch review status: open title: io.py: Improve docstrings for classes type: enhancement Added file: http://bugs.python.org/file34847/io-copy-docstrings.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 23:00:05 2014 From: report at bugs.python.org (Glenn Jones) Date: Mon, 14 Apr 2014 21:00:05 +0000 Subject: [issue15916] change doctest DocTestSuite not to raise ValueError if no docstrings In-Reply-To: <1347321295.19.0.66061447718.issue15916@psf.upfronthosting.co.za> Message-ID: <1397509205.65.0.579584862129.issue15916@psf.upfronthosting.co.za> Glenn Jones added the comment: Added docs to patch ---------- Added file: http://bugs.python.org/file34848/issue15916-with-docs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 23:00:22 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 14 Apr 2014 21:00:22 +0000 Subject: [issue20874] Tutorial section on starting python is out of date In-Reply-To: <1394379932.36.0.812758095306.issue20874@psf.upfronthosting.co.za> Message-ID: <1397509222.93.0.601158205848.issue20874@psf.upfronthosting.co.za> R. David Murray added the comment: Just as a point of information, when making a patch like this it is best to change the smallest number of lines possible, without worrying about line wrapping. This allows us to see just what was changed. The committer can then reflow the paragraph (actually I prefer to commit the minimum change and then do a separate reflow commit). The patch itself looks fine. St?phane: the original docs didn't explain it either, and in 3.4 you don't have to do anything to enable it. (That is, if it isn't automatically enabled, it *can't* be turned on, because readline isn't available.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 23:02:37 2014 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 14 Apr 2014 21:02:37 +0000 Subject: [issue21209] q.put(some_tuple) fails when PYTHONASYNCIODEBUG=1 In-Reply-To: <1397351442.01.0.248805040826.issue21209@psf.upfronthosting.co.za> Message-ID: <1397509357.5.0.194945401741.issue21209@psf.upfronthosting.co.za> Guido van Rossum added the comment: Yuri, thanks for the test, but why would the patch need a version check? Shouldn't the work-around work equally well in Python versions that don't need it? Maybe all we need is a comment explaining that it is a work-around and a hint that eventually we should change it back? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 23:02:52 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Mon, 14 Apr 2014 21:02:52 +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: <1397509372.68.0.366784734885.issue21224@psf.upfronthosting.co.za> Senthil Kumaran added the comment: It may not just the be the version, but the capabilities. We have ensure that capabilities are met/added before updated the version. Thanks for filing the issue. ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 23:04:07 2014 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Mon, 14 Apr 2014 21:04:07 +0000 Subject: [issue20874] Tutorial section on starting python is out of date In-Reply-To: <1394379932.36.0.812758095306.issue20874@psf.upfronthosting.co.za> Message-ID: <1397509447.04.0.342586199567.issue20874@psf.upfronthosting.co.za> St?phane Wirtel added the comment: David, thank you for this comment about the automatic activation of the command line editing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 23:04:25 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 14 Apr 2014 21:04:25 +0000 Subject: [issue20874] Tutorial section on starting python is out of date In-Reply-To: <1394379932.36.0.812758095306.issue20874@psf.upfronthosting.co.za> Message-ID: <1397509465.26.0.209843110175.issue20874@psf.upfronthosting.co.za> R. David Murray added the comment: Actually I take it back, the patch as a patch also has a couple issues: the line lengths are not in fact less than 80 characters in any case, and there is trailing whitespace on several lines. Could you redo it with just the minimum lines changed and no trailing whitespace? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 23:04:27 2014 From: report at bugs.python.org (Trevor Caira) Date: Mon, 14 Apr 2014 21:04:27 +0000 Subject: [issue21226] PyImport_ExecCodeModuleObject not setting module attributes Message-ID: <1397509467.13.0.547431443442.issue21226@psf.upfronthosting.co.za> New submission from Trevor Caira: In Python/import.c, PyImport_ExecCodeModuleObject creates a new module object but doesn't set all of the attributes required for modules, such as __spec__ or __loader__. This breaks mod_wsgi from 3.3 and up, which depends on PyImport_ExecCodeModuleEx, which delegates to PyImport_ExecCodeModuleObject for its module creation logic. See https://code.google.com/p/modwsgi/source/browse/mod_wsgi/mod_wsgi.c#6289 ---------- components: Library (Lib) messages: 216217 nosy: brett.cannon, eric.snow, ncoghlan, trevor3 priority: normal severity: normal status: open title: PyImport_ExecCodeModuleObject not setting module attributes type: behavior versions: Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 23:05:31 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 14 Apr 2014 21:05:31 +0000 Subject: [issue15104] Unclear language in __main__ description In-Reply-To: <1340092965.02.0.675870286607.issue15104@psf.upfronthosting.co.za> Message-ID: <1397509531.15.0.931303906516.issue15104@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I am a bit puzzled. According to https://docs.python.org/2.7/using/cmdline.html#interface-options __main__.py (not indexed) has been supported since 2.5. On the other hand, recursively grepping Lib for 'e' in __main__.py files hits about 20 files in 3.4 but only 2 in 2.7. Moreover, those two files fail for trying to do relative imports: "from .main import main, TestProgram, USAGE_AS_MAIN". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 23:08:15 2014 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Mon, 14 Apr 2014 21:08:15 +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: <1397509695.7.0.755003766235.issue21224@psf.upfronthosting.co.za> St?phane Wirtel added the comment: gunicorn has an implementation of the HTTP/1.1 protocol, we can ask to the author of this project if we can use its code and reuse it in the standard library. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 23:11:05 2014 From: report at bugs.python.org (Christian Hudon) Date: Mon, 14 Apr 2014 21:11:05 +0000 Subject: [issue1704474] optparse tests fail under Jython Message-ID: <1397509865.44.0.307697686673.issue1704474@psf.upfronthosting.co.za> Christian Hudon added the comment: I'll use Jython 2.7. The Jython people can backport the fix to 2.5.4, if they want it there too. So... this is marked as related to Python 3.2, but Jython is on Python 2 of course. I'll just take the version as being wrong. So, what should the patch that fixes this be based on? Not Python 3, obviously. But CPython 2.7's latest? Or the Jython 2.7 repository? And where should the fix be committed? In CPython's repository, or in Jython? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 23:13:10 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 14 Apr 2014 21:13:10 +0000 Subject: [issue12220] minidom xmlns not handling spaces in xmlns attribute value field In-Reply-To: <1306789573.92.0.875996944294.issue12220@psf.upfronthosting.co.za> Message-ID: <1397509990.94.0.37134215997.issue12220@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks. Could you also change 'Invalid syntax' to 'Unsupported syntax', per the last bit of the discussion between Terry and I? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 23:17:33 2014 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Mon, 14 Apr 2014 21:17:33 +0000 Subject: [issue21220] Enhance obmalloc allocation strategy In-Reply-To: <1397499786.06.0.606856949694.issue21220@psf.upfronthosting.co.za> Message-ID: <1397510253.83.0.254463098868.issue21220@psf.upfronthosting.co.za> Changes by Kristj?n Valur J?nsson : ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 23:22:44 2014 From: report at bugs.python.org (Glenn Jones) Date: Mon, 14 Apr 2014 21:22:44 +0000 Subject: [issue21215] build-deps instructions for Ubuntu In-Reply-To: <1397485129.87.0.0518806030798.issue21215@psf.upfronthosting.co.za> Message-ID: <1397510564.23.0.908542578384.issue21215@psf.upfronthosting.co.za> Glenn Jones added the comment: Uploaded new patch with a little more about getting build-deps installed. ---------- Added file: http://bugs.python.org/file34849/issue21215.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 23:23:20 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 14 Apr 2014 21:23:20 +0000 Subject: [issue6623] Lib/ftplib.py Netrc class should be removed. In-Reply-To: <1249165781.68.0.418938928921.issue6623@psf.upfronthosting.co.za> Message-ID: <1397510600.79.0.56670206769.issue6623@psf.upfronthosting.co.za> R. David Murray added the comment: Did you hand test it? Also, you could open a new issue to add tests for the ftplib cli, and probably improve and document it? It was designed as a test, but some people may be using it and it might even be actually useful :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 23:27:48 2014 From: report at bugs.python.org (Eric Snow) Date: Mon, 14 Apr 2014 21:27:48 +0000 Subject: [issue21223] fix test_site/test_startup_imports when some of the extensions are built as builtins In-Reply-To: <1397507113.83.0.846424139619.issue21223@psf.upfronthosting.co.za> Message-ID: <1397510868.33.0.265384128413.issue21223@psf.upfronthosting.co.za> Eric Snow added the comment: Looks good to me. This should not impact the standard build, but is useful for alternate builds. Does something similar need to happen to also exclude frozen modules? ---------- nosy: +brett.cannon, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 23:40:15 2014 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 14 Apr 2014 21:40:15 +0000 Subject: [issue21209] q.put(some_tuple) fails when PYTHONASYNCIODEBUG=1 In-Reply-To: <1397351442.01.0.248805040826.issue21209@psf.upfronthosting.co.za> Message-ID: <1397511615.24.0.0702179396163.issue21209@psf.upfronthosting.co.za> Yury Selivanov added the comment: Please see the corowrapper_02.patch. I've removed the version check, now it's much simpler. ---------- Added file: http://bugs.python.org/file34850/corowrapper_02.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 23:45:51 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Mon, 14 Apr 2014 21:45:51 +0000 Subject: [issue10318] "make altinstall" installs many files with incorrect shebangs In-Reply-To: <1288926610.35.0.932494150274.issue10318@psf.upfronthosting.co.za> Message-ID: <1397511951.8.0.87682463986.issue10318@psf.upfronthosting.co.za> Changes by Senthil Kumaran : ---------- nosy: -orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 23:46:48 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Mon, 14 Apr 2014 21:46:48 +0000 Subject: [issue16278] Improve os.rename documentation and tests In-Reply-To: <1350581776.08.0.668682100781.issue16278@psf.upfronthosting.co.za> Message-ID: <1397512008.6.0.699967419121.issue16278@psf.upfronthosting.co.za> Changes by Senthil Kumaran : ---------- nosy: -orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 23:50:37 2014 From: report at bugs.python.org (Josiah Carlson) Date: Mon, 14 Apr 2014 21:50:37 +0000 Subject: [issue1191964] asynchronous Subprocess Message-ID: <1397512237.12.0.592856496417.issue1191964@psf.upfronthosting.co.za> Josiah Carlson added the comment: I ended up eliminating the overlapped IO cancel call on Windows. Better to be correct than to minimize internal state. Instead, we keep a reference to the overlapped IO object, and any attempts to write to the child stdin before the previous overlapped IO completes are kicked back as a 0 byte write. The communicate() method does the right thing with pre-existing non-blocking writes, whether input is passed or not. I also eliminated universal_newline support for non-blocking reads and writes to prevent error conditions on edge cases: On the write side of things, you could end up with a partial multi-byte character write, which with universal newlines, would be impossible to finish the send using the public API without first modifying state attributes on the Popen object (disabling universal newlines for a subsequent bytes write_nonblocking() call). On the read side of things, if you get a partial read of a multi-byte character, then the subsequent decode operation would fail with a UnicodeDecodeError. Though you could pull the original bytes from the exception, that's an awful API to create. ---------- Added file: http://bugs.python.org/file34851/subprocess_4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 23:54:01 2014 From: report at bugs.python.org (Sam Kimbrel) Date: Mon, 14 Apr 2014 21:54:01 +0000 Subject: [issue17078] string.Template.safe_substitute hard-wires "braces" as {} In-Reply-To: <1359495046.85.0.635388190725.issue17078@psf.upfronthosting.co.za> Message-ID: <1397512441.85.0.138599759727.issue17078@psf.upfronthosting.co.za> Sam Kimbrel added the comment: Florent Xicluna already fixed this in r84888 for 3.2+; I've tested that the patch applies cleanly to 2.7 and tests pass. Someone with the commit bit should transplant that commit into 2.7 as it does not change the public API to this module. ---------- nosy: +sam.kimbrel _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 23:55:13 2014 From: report at bugs.python.org (Glenn Jones) Date: Mon, 14 Apr 2014 21:55:13 +0000 Subject: [issue15795] Zipfile.extractall does not preserve file permissions In-Reply-To: <1346106964.12.0.723201722432.issue15795@psf.upfronthosting.co.za> Message-ID: <1397512513.14.0.257367415572.issue15795@psf.upfronthosting.co.za> Glenn Jones added the comment: Here is an updated patch that applies cleanly to head. Tests pass against head of repo. ---------- nosy: +Glenn.Jones Added file: http://bugs.python.org/file34852/issue15795_updated.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 14 23:56:10 2014 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Mon, 14 Apr 2014 21:56:10 +0000 Subject: [issue12916] Add inspect.splitdoc In-Reply-To: <1315326747.38.0.43030903994.issue12916@psf.upfronthosting.co.za> Message-ID: <1397512570.57.0.519981742618.issue12916@psf.upfronthosting.co.za> St?phane Wirtel added the comment: I move the pydoc.splitdoc function to the inspect module. Update the documentation. Add a unittest for this new function. I can provide an other patch for the backward-compatiblity if this function is used by an other module than pydoc. ---------- keywords: +patch nosy: +matrixise Added file: http://bugs.python.org/file34853/issue12916_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 00:00:43 2014 From: report at bugs.python.org (Kushal Das) Date: Mon, 14 Apr 2014 22:00:43 +0000 Subject: [issue21222] Mock create_autospec with name argument fails In-Reply-To: <1397505251.05.0.288307474202.issue21222@psf.upfronthosting.co.za> Message-ID: <1397512843.12.0.849241634367.issue21222@psf.upfronthosting.co.za> Kushal Das added the comment: Fix for the issue with test case. We are checking name in keyword arguments, if found replace _name with it and delete it from keyword arguments. ---------- keywords: +patch Added file: http://bugs.python.org/file34854/issue21222.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 00:01:41 2014 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 14 Apr 2014 22:01:41 +0000 Subject: [issue8931] '#' has no affect with 'c' type In-Reply-To: <1275865635.78.0.716511257083.issue8931@psf.upfronthosting.co.za> Message-ID: <1397512901.83.0.252365857279.issue8931@psf.upfronthosting.co.za> Changes by Eric V. Smith : ---------- versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 00:06:13 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 14 Apr 2014 22:06:13 +0000 Subject: [issue12916] Add inspect.splitdoc In-Reply-To: <1315326747.38.0.43030903994.issue12916@psf.upfronthosting.co.za> Message-ID: <1397513173.97.0.359954784168.issue12916@psf.upfronthosting.co.za> R. David Murray added the comment: The patch looks good, but 'splitdoc' needs to remain a valid name for the function in the pydoc namespace. You could just add 'splitdoc = inspect.splitdoc' after the import statements. (The reason it needs to remain valid is for backward compatibility...there may be people who discovered it and have been importing it from pydoc.) ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 00:08:24 2014 From: report at bugs.python.org (Steven Hiscocks) Date: Mon, 14 Apr 2014 22:08:24 +0000 Subject: [issue21207] urandom persistent fd - not re-openned after fd close In-Reply-To: <1397316819.31.0.463593532744.issue21207@psf.upfronthosting.co.za> Message-ID: <1397513304.17.0.528133224232.issue21207@psf.upfronthosting.co.za> Steven Hiscocks added the comment: Just to add for those interested: a possible work around solution is using "os.path.sameopenfile" to check fds against another known fd for urandom. And for those wish to have a bit of fun (and maybe a security consideration): python -c "import os;os.urandom(1);os.closerange(3,256);fd = open('/dev/zero');print(os.urandom(10))" b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 00:09:59 2014 From: report at bugs.python.org (Kushal Das) Date: Mon, 14 Apr 2014 22:09:59 +0000 Subject: [issue17861] put opcode information in one place In-Reply-To: <1367162089.6.0.986391601417.issue17861@psf.upfronthosting.co.za> Message-ID: <1397513399.16.0.258322527338.issue17861@psf.upfronthosting.co.za> Kushal Das added the comment: New patch with proper changesets. ---------- Added file: http://bugs.python.org/file34855/issue17861_v4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 00:12:39 2014 From: report at bugs.python.org (Rafael Mejia) Date: Mon, 14 Apr 2014 22:12:39 +0000 Subject: [issue20874] Tutorial section on starting python is out of date In-Reply-To: <1394379932.36.0.812758095306.issue20874@psf.upfronthosting.co.za> Message-ID: <1397513559.71.0.106291924225.issue20874@psf.upfronthosting.co.za> Rafael Mejia added the comment: I've resubmitted the patch with the minimum lines changed and no trailing white space. ---------- Added file: http://bugs.python.org/file34856/issue_20874_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 00:22:52 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 14 Apr 2014 22:22:52 +0000 Subject: [issue17498] error responses from server are masked in smtplib when server closes connection In-Reply-To: <1363812510.09.0.989538319205.issue17498@psf.upfronthosting.co.za> Message-ID: <3g748W6R40z7Lk0@mail.python.org> Roundup Robot added the comment: New changeset 3c441e9ccf87 by R David Murray in branch '3.4': #17498: Defer SMTPServerDisconnected errors until the next command. http://hg.python.org/cpython/rev/3c441e9ccf87 New changeset 842014ab1c06 by R David Murray in branch 'default': Merge #17498: Defer SMTPServerDisconnected errors until the next command. http://hg.python.org/cpython/rev/842014ab1c06 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 00:23:12 2014 From: report at bugs.python.org (Matt Chaput) Date: Mon, 14 Apr 2014 22:23:12 +0000 Subject: [issue21198] Minor tarfile documentation bug In-Reply-To: <1397148227.41.0.631676560193.issue21198@psf.upfronthosting.co.za> Message-ID: <1397514192.83.0.909833467057.issue21198@psf.upfronthosting.co.za> Changes by Matt Chaput : Removed file: http://bugs.python.org/file34824/issue21198.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 00:23:56 2014 From: report at bugs.python.org (Matt Chaput) Date: Mon, 14 Apr 2014 22:23:56 +0000 Subject: [issue21198] Minor tarfile documentation bug In-Reply-To: <1397148227.41.0.631676560193.issue21198@psf.upfronthosting.co.za> Message-ID: <1397514236.8.0.7096283997.issue21198@psf.upfronthosting.co.za> Matt Chaput added the comment: Oops! Yes, I accidentally included a bunch of other crap. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 00:24:41 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 14 Apr 2014 22:24:41 +0000 Subject: [issue17498] error responses from server are masked in smtplib when server closes connection In-Reply-To: <1363812510.09.0.989538319205.issue17498@psf.upfronthosting.co.za> Message-ID: <1397514281.28.0.0415956458235.issue17498@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, Kushal. Sorry it took so long to get this committed :) ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed type: -> behavior versions: +Python 3.5 -Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 00:25:27 2014 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 14 Apr 2014 22:25:27 +0000 Subject: [issue12916] Add inspect.splitdoc In-Reply-To: <1315326747.38.0.43030903994.issue12916@psf.upfronthosting.co.za> Message-ID: <1397514327.49.0.815639442805.issue12916@psf.upfronthosting.co.za> Yury Selivanov added the comment: I don't like this idea. inspect module is about introspection, and not about interpreting its results. I'd keep this function in pydoc and document it if there is noticeable demand for it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 00:27:38 2014 From: report at bugs.python.org (Stefan Krah) Date: Mon, 14 Apr 2014 22:27:38 +0000 Subject: [issue21015] support SSL_CTX_set_ecdh_auto on newer OpenSSLs In-Reply-To: <1395455671.92.0.144736574461.issue21015@psf.upfronthosting.co.za> Message-ID: <1397514458.08.0.350727361724.issue21015@psf.upfronthosting.co.za> Stefan Krah added the comment: FreeBSD 9.0 has the same broken install: $ openssl version OpenSSL 0.9.8y 5 Feb 2013 $ ls /usr/include/openssl/ecd* /usr/include/openssl/ecdh.h /usr/include/openssl/ecdsa.h I'm inclined to view this as an OS issue. FreeBSD 9.2 (koobs' buildslave) apparently does not have this problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 00:31:52 2014 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Mon, 14 Apr 2014 22:31:52 +0000 Subject: [issue12916] Add inspect.splitdoc In-Reply-To: <1315326747.38.0.43030903994.issue12916@psf.upfronthosting.co.za> Message-ID: <1397514712.77.0.568774399265.issue12916@psf.upfronthosting.co.za> St?phane Wirtel added the comment: Yury and David, please, can you discuss about this point, or just close this ticket if this one is useless. Thank you ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 00:32:18 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 14 Apr 2014 22:32:18 +0000 Subject: [issue21204] multiprocessing example does not work on Windows In-Reply-To: <1397267440.3.0.253901505287.issue21204@psf.upfronthosting.co.za> Message-ID: <1397514738.61.0.795685487075.issue21204@psf.upfronthosting.co.za> R. David Murray added the comment: If you look at the source code for 2.7, it is clear that patch has been applied. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 00:35:35 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 14 Apr 2014 22:35:35 +0000 Subject: [issue21204] multiprocessing example does not work on Windows In-Reply-To: <1397267440.3.0.253901505287.issue21204@psf.upfronthosting.co.za> Message-ID: <1397514935.93.0.20931366251.issue21204@psf.upfronthosting.co.za> R. David Murray added the comment: To clarify, the commit in that issue is in 2.7. So if there is something else that isn't in 2.7, it is a different issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 00:42:51 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Mon, 14 Apr 2014 22:42:51 +0000 Subject: [issue13244] WebSocket schemes in urllib.parse In-Reply-To: <1319281663.43.0.214740119457.issue13244@psf.upfronthosting.co.za> Message-ID: <1397515371.95.0.385444506013.issue13244@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Reading both the RFCs and requirements, I see that this is already taken care. Note: we are actually have unencoded fragment like # and RFCs talk about fragments with # character only. If you want the behavior of parse with urlencoded to match un-urlencoded one, that's a different requirement and not a scope here. Here is 3.5 output $ ./python.exe Python 3.5.0a0 (default:528234542ff0, Apr 14 2014, 18:25:27) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import urllib.parse >>> p = urllib.parse.urlparse('ws://example.com/something?query=foo#bar') >>> p ParseResult(scheme='ws', netloc='example.com', path='/something', params='', query='query=foo', fragment='bar') >>> p = urllib.parse.urlparse('ws://example.com/something#bar') >>> p ParseResult(scheme='ws', netloc='example.com', path='/something', params='', query='', fragment='bar') Here is 2.7.6 output $ ./python.exe Python 2.7.6+ (2.7:7dab4feec126+, Jan 11 2014, 15:25:20) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import urlparse >>> ^D [localhost 2.7]$ ./python.exe Python 2.7.6+ (2.7:7dab4feec126+, Jan 11 2014, 15:25:20) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from urlparse import urlparse >>> urlparse('ws://example.com/something?query=foo#bar') ParseResult(scheme='ws', netloc='example.com', path='/something', params='', query='query=foo', fragment='bar') >>> urlparse('ws://example.com/something#bar') ParseResult(scheme='ws', netloc='example.com', path='/something', params='', query='', fragment='bar') >>> I find it satisfactory and I think, this bug should be closed. Thank you! ---------- assignee: -> orsenthil resolution: -> works for me status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 00:48:03 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Mon, 14 Apr 2014 22:48:03 +0000 Subject: [issue9374] urlparse should parse query and fragment for arbitrary schemes In-Reply-To: <1280012321.31.0.791086727515.issue9374@psf.upfronthosting.co.za> Message-ID: <1397515683.5.0.00681624548276.issue9374@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Reviewed the issue and correct rollbacks and commits were applied. This ticket should be closed. Thanks! ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 00:48:30 2014 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 14 Apr 2014 22:48:30 +0000 Subject: [issue8931] '#' has no effect with 'c' type In-Reply-To: <1275865635.78.0.716511257083.issue8931@psf.upfronthosting.co.za> Message-ID: <1397515710.5.0.633870623114.issue8931@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- title: '#' has no affect with 'c' type -> '#' has no effect with 'c' type _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 00:49:51 2014 From: report at bugs.python.org (A Kaptur) Date: Mon, 14 Apr 2014 22:49:51 +0000 Subject: [issue21217] inspect.getsourcelines finds wrong lines when lambda used argument to decorator In-Reply-To: <1397496660.33.0.566497694968.issue21217@psf.upfronthosting.co.za> Message-ID: <1397515791.29.0.750695370802.issue21217@psf.upfronthosting.co.za> A Kaptur added the comment: This patch adds tests demonstrating broken behavior inspect.getsource and inspect.getsourcelines of decorators containing lambda functions, and modifies inspect.getsourcelines to behave correctly. We use co_lnotab to extract line numbers on all objects with a code object. inspect.getsourcelines can also take a class, which cannot use co_lnotab as there is no associated code object. @ballingt and I paired on this patch. Some open questions about inspect.getsource not created or addressed by this patch: - Is this a bug that should be patched in previous versions as well? - the docs for say it can take a traceback. What is the correct behavior here? There aren't any tests at the moment. We suggest the line of code that caused the traceback, i.e. the line at tb.tb_lineno - We added tests of decorated classes. The source of decorated classes does not include the decorators, which is different than the usual behavior of decorated functions. What is the correct behavior here? - inspect.getblock and inspect.BlockFinder use the term "block" in a way that is inconsistent with its typical use in the interpreter (that is, in ceval.c). Should this be renamed? If so, to what? ("chunk"?) ---------- keywords: +patch nosy: +akaptur stage: -> patch review versions: -Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file34857/issue21217.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 00:53:44 2014 From: report at bugs.python.org (Alex Lord) Date: Mon, 14 Apr 2014 22:53:44 +0000 Subject: [issue18262] ZipInfo.external_attr are not documented In-Reply-To: <1371622762.23.0.278457180872.issue18262@psf.upfronthosting.co.za> Message-ID: <1397516024.03.0.521194755334.issue18262@psf.upfronthosting.co.za> Alex Lord added the comment: Here's a documentation patch for 2.7 that informs the users that Zipfile.extra and Zipfile.extraall don't save permissions and that Zipfile.writestr will use ZipInfo.extra_attr or default to chmod permission set of 0600. ---------- keywords: +patch nosy: +Alex.Lord versions: -Python 2.6, Python 3.1, Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file34858/Issue18262_27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 00:54:32 2014 From: report at bugs.python.org (Alex Lord) Date: Mon, 14 Apr 2014 22:54:32 +0000 Subject: [issue18262] ZipInfo.external_attr are not documented In-Reply-To: <1371622762.23.0.278457180872.issue18262@psf.upfronthosting.co.za> Message-ID: <1397516072.17.0.9747231512.issue18262@psf.upfronthosting.co.za> Alex Lord added the comment: And here's the 3.4 and 3.5 patch ---------- Added file: http://bugs.python.org/file34859/Issue18262_34_35.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 00:54:42 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 14 Apr 2014 22:54:42 +0000 Subject: [issue15104] Unclear language in __main__ description In-Reply-To: <1340092965.02.0.675870286607.issue15104@psf.upfronthosting.co.za> Message-ID: <3g74sF6cx2z7LjS@mail.python.org> Roundup Robot added the comment: New changeset 008486e18e90 by R David Murray in branch '3.4': #15104: add backtick code markup. http://hg.python.org/cpython/rev/008486e18e90 New changeset 14e874736d3a by R David Murray in branch 'default': Merge: #15104: add backtick code markup. http://hg.python.org/cpython/rev/14e874736d3a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 01:27:52 2014 From: report at bugs.python.org (Caelyn McAulay) Date: Mon, 14 Apr 2014 23:27:52 +0000 Subject: [issue10523] argparse has problem parsing option files containing empty rows In-Reply-To: <1290635267.13.0.585990858581.issue10523@psf.upfronthosting.co.za> Message-ID: <1397518072.19.0.218288262347.issue10523@psf.upfronthosting.co.za> Caelyn McAulay added the comment: The current behaviour takes empty lines and interprets them as empty strings. The attached demonstration script shows the error occurring. The first case is a simple example to illustrate what happens in the general case. The second case shows empty lines being interpreted as empty strings and assigned to arguments. The third case, despite being very similar to the first, results in argparse exiting with an error message. Internally, what is happening is, after taking the 'foo' and 'baz' arguments and assigning them 'bar' and 'quux' respectively, it reads in an argument "", which it does not recognize. And produces the following error message: "argparse_example.py: error: unrecognized arguments:" The error message, in it's current form, is kind of opaque. For the third case, if we move the blank line to between 'bar' and '-baz', the same error results, as again it tried to interpret the blank line as an argument. If we move the blank line to the start of the file, same thing again. If we move the blank line between '-foo' and 'bar', instead the error reads: "argparse_example.py: error: unrecognized arguments: bar" - which is at least somewhat comprehensible. The question is, how should blank lines be handled? Should they be accepted as possible values for arguments? If they fall into spaces where arguments (versus values for arguments) are expected, should we skip them? If the current handling is fine, I would propose updating the documentation to add the following after the paragraph that begins "Arguments read from a file ...": "By default, blank lines are interpreted as empty strings. An empty string is not an acceptable argument; but it is an acceptable value for an argument." And changing the way that the error from argparse is displayed so that it is more obvious what "argparse_example.py: error: unrecognized arguments:" means. ---------- nosy: +math_foo Added file: http://bugs.python.org/file34860/argparse_example.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 01:39:52 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Mon, 14 Apr 2014 23:39:52 +0000 Subject: [issue10983] Errors in http.client.HTTPConnection class (python3) In-Reply-To: <1295732961.38.0.859825723182.issue10983@psf.upfronthosting.co.za> Message-ID: <1397518792.15.0.628021795341.issue10983@psf.upfronthosting.co.za> Nikolaus Rath added the comment: This issue can be closed. The testcases have been added in 39ee3286d187. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 01:42:15 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Mon, 14 Apr 2014 23:42:15 +0000 Subject: [issue10983] Errors in http.client.HTTPConnection class (python3) In-Reply-To: <1295732961.38.0.859825723182.issue10983@psf.upfronthosting.co.za> Message-ID: <1397518935.04.0.883309813724.issue10983@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Yes, they indeed are. Thank you! ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 01:46:08 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 14 Apr 2014 23:46:08 +0000 Subject: [issue21191] os.fdopen() may eat file descriptor and still raise exception In-Reply-To: <1397067895.73.0.194150876234.issue21191@psf.upfronthosting.co.za> Message-ID: <3g760b6zxKz7Ljd@mail.python.org> Roundup Robot added the comment: New changeset 339c79791b65 by Benjamin Peterson in branch '2.7': when an exception is raised in fdopen, never close the fd (changing on my mind on #21191) http://hg.python.org/cpython/rev/339c79791b65 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 02:02:39 2014 From: report at bugs.python.org (leewz) Date: Tue, 15 Apr 2014 00:02:39 +0000 Subject: [issue21227] Decimal class error messages for integer division aren't good Message-ID: <1397520159.39.0.440264883295.issue21227@psf.upfronthosting.co.za> New submission from leewz: Python's `decimal.Decimal` doesn't seem to like taking modulo or intdiv of large Decimals by integers (where "large" depends on how many digits are internally stored). >>> from decimal import * >>> getcontext().prec 28 >>> Decimal(10**29)%1 Traceback (most recent call last): File "", line 1, in decimal.InvalidOperation: [] >>> getcontext().prec=50 >>> Decimal(10**29)%1 Decimal('0') Same for `Decimal(10**29)//1` This is a logical problem: "Alice has a 100-digit number which begins with 1543256. What is the last digit?" But I found the error hard to understand. Searching for "DivisionImpossible" didn't turn up anything immediate (it wasn't added to the official docs?). I was most of the way through writing out a question to StackOverflow when it clicked. (Also, why is it an InvalidOperation that holds an exception as a message? Never saw that before.) Suggestions: - Improve docs with further examples. The examples of InvalidOperation are logical MATH errors (e.g. division by 0), not logical PROGRAMMING errors. - Uh, maybe the error message could be changed to something like, "The answer you seek lies beyond the mantissa." Or more sanely, "Not enough precision to compute the answer." Or something else that hints to me to look into precision. ---------- assignee: docs at python components: Documentation, Library (Lib) messages: 216253 nosy: docs at python, leewz priority: normal severity: normal status: open title: Decimal class error messages for integer division aren't good type: enhancement versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 02:08:03 2014 From: report at bugs.python.org (=?utf-8?q?Evens_Fortun=C3=A9?=) Date: Tue, 15 Apr 2014 00:08:03 +0000 Subject: [issue21228] Missing enumeration of HTTPResponse Objects methods of urllib.request.urlopen's http.client.HTTPResponse? Message-ID: <1397520483.48.0.224250148615.issue21228@psf.upfronthosting.co.za> New submission from Evens Fortun?: In the Python Library documentation, in section "21.6. urllib.request ? Extensible library for opening URLs", in the description of the urllib.request.urlopen() function it is writen: --------- [?] For http and https urls, this function returns a http.client.HTTPResponse object which has the following HTTPResponse Objects methods. For ftp, file, and data urls and requests explicity handled by legacy [?] --------- The first sentence seemed to imply that something is supposed to be specified if I understand correctly. Is it me missing something?? ---------- assignee: docs at python components: Documentation messages: 216254 nosy: EvensF, docs at python priority: normal severity: normal status: open title: Missing enumeration of HTTPResponse Objects methods of urllib.request.urlopen's http.client.HTTPResponse? type: enhancement versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 02:29:04 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 15 Apr 2014 00:29:04 +0000 Subject: [issue15916] change doctest DocTestSuite not to raise ValueError if no docstrings In-Reply-To: <1347321295.19.0.66061447718.issue15916@psf.upfronthosting.co.za> Message-ID: <3g76y46N2Hz7LjQ@mail.python.org> Roundup Robot added the comment: New changeset 57fb5441a4aa by R David Murray in branch 'default': #15916: if there are no docstrings, make empty suite, not an error. http://hg.python.org/cpython/rev/57fb5441a4aa ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 02:29:46 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 15 Apr 2014 00:29:46 +0000 Subject: [issue15916] change doctest DocTestSuite not to raise ValueError if no docstrings In-Reply-To: <1347321295.19.0.66061447718.issue15916@psf.upfronthosting.co.za> Message-ID: <1397521786.13.0.766092499901.issue15916@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, Glenn. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 02:36:23 2014 From: report at bugs.python.org (=?utf-8?q?Evens_Fortun=C3=A9?=) Date: Tue, 15 Apr 2014 00:36:23 +0000 Subject: [issue21229] Path used for HTTP PUT request doesn't match the description Message-ID: <1397522183.41.0.398189687255.issue21229@psf.upfronthosting.co.za> New submission from Evens Fortun?: In the Python Standard Library, at the end of : - Section "20.7.3. Examples" of "20.7. httplib ? HTTP protocol client" (for Python 2.7.6) - Section "20.10.3. Examples" of "20.10. http.client ? HTTP protocol client" (for Python 3.2.5) - Section "21.12.3. Examples" of "21.12. http.client ? HTTP protocol client" (for Python 3.3.5, Python 3.4.0, and Python 3.5a0) the last example is described this way (change httplib for http.client for Python 3.2+): -------- >>> # This creates an HTTP message >>> # with the content of BODY as the enclosed representation >>> # for the resource http://localhost:8080/foobar ... >>> import httplib >>> BODY = "***filecontents***" >>> conn = httplib.HTTPConnection("localhost", 8080) >>> conn.request("PUT", "/file", BODY) >>> response = conn.getresponse() >>> print response.status, response.reason 200, OK -------- Is it possible that the request method should have been called this way: conn.request("PUT", "/foobar", BODY) ^^^^^^ Thank you ---------- assignee: docs at python components: Documentation messages: 216257 nosy: EvensF, docs at python priority: normal severity: normal status: open title: Path used for HTTP PUT request doesn't match the description type: enhancement versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 02:39:01 2014 From: report at bugs.python.org (=?utf-8?q?Evens_Fortun=C3=A9?=) Date: Tue, 15 Apr 2014 00:39:01 +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: <1397522341.82.0.843004249316.issue21228@psf.upfronthosting.co.za> Evens Fortun? added the comment: I forgot to tell that it is in section "20.5. urllib.request ? Extensible library for opening URLs" for Python 3.2.5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 02:49:20 2014 From: report at bugs.python.org (Josiah Carlson) Date: Tue, 15 Apr 2014 00:49:20 +0000 Subject: [issue1191964] asynchronous Subprocess Message-ID: <1397522960.7.0.669622379798.issue1191964@psf.upfronthosting.co.za> Changes by Josiah Carlson : Added file: http://bugs.python.org/file34861/subprocess_5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 03:08:48 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 15 Apr 2014 01:08:48 +0000 Subject: [issue1704474] optparse tests fail under Jython Message-ID: <1397524128.36.0.071138464381.issue1704474@psf.upfronthosting.co.za> R. David Murray added the comment: Well, we want it to apply to python3 as well, since we want to see jython support python3 eventually :) Also, optparse is present in python3 for backward compatibility reasons only...there were very few changes between the time python3 branched from python2 and argparse superceeded optparse. So the differences between the two code bases should be minimal. Obviously you can't test against jython3, since it doesn't exist, but what you can do is make the patch based on the python2 optparse, and then see if the patch applies cleanly to python3. It probably won't, but as far as I can see from a quick diff, most of the changes will be related to the changes between python2 syntax and python3 syntax, and will be easy to forward port even without being able to test it directly against jython. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 03:13:51 2014 From: report at bugs.python.org (Faiz Abbasi) Date: Tue, 15 Apr 2014 01:13:51 +0000 Subject: [issue21230] imghdr does not accept adobe photoshop mime type Message-ID: <1397524431.49.0.471880586962.issue21230@psf.upfronthosting.co.za> New submission from Faiz Abbasi: Python 2.7 I noticed a recurring bug we've had attempting to send a particular JPEG image in emails: email.mime.image.__init__ : Could not guess image MIME subtype After looking into the imghdr.what and tests source code, I noticed that this JPEG image begins with the following data: '\xff\xd8\xff\xee\x00\x0eAdobe\x00d\x00\x00\x00\x00\x00\xff\xed\x008Photoshop ' I've attached the image in question to this bug report. There's two functions for asserting an image is JPEG format, test_jpeg and test_exif. I'd like to propose another function for resolving Adobe Photoshop image formats. Unless, of course, this is expected behavior? Thanks! ---------- components: email files: image.jpeg messages: 216260 nosy: barry, benjamin.peterson, faiz, r.david.murray priority: normal severity: normal status: open title: imghdr does not accept adobe photoshop mime type type: enhancement versions: Python 2.7 Added file: http://bugs.python.org/file34862/image.jpeg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 03:19:26 2014 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 15 Apr 2014 01:19:26 +0000 Subject: [issue21209] q.put(some_tuple) fails when PYTHONASYNCIODEBUG=1 In-Reply-To: <1397351442.01.0.248805040826.issue21209@psf.upfronthosting.co.za> Message-ID: <1397524766.86.0.894076633951.issue21209@psf.upfronthosting.co.za> Guido van Rossum added the comment: OK, looks good. I tried your test with my earlier workaround and the wrapper got deallocated too early, proving that my workaround was indeed wrong and your test is useful. I am still concerned theoretically that the CoroWrapper.send() signature is different from a real generator's send() method, but I think that send() to a coroutine is an internal detail anyway, so I can live with that, and I don't see another work-around. When you commit, can you do upstgream (Tulip) first? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 03:27:22 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Tue, 15 Apr 2014 01:27:22 +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: <1397525242.8.0.87755638739.issue21228@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Hello Evens, If you can, then please attach a doc to this and we and fix this soon. ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 03:27:32 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 15 Apr 2014 01:27:32 +0000 Subject: [issue21215] build-deps instructions for Ubuntu In-Reply-To: <1397485129.87.0.0518806030798.issue21215@psf.upfronthosting.co.za> Message-ID: <3g78Fb4wS7z7LjX@mail.python.org> Roundup Robot added the comment: New changeset 84ccbb961f26 by R David Murray in branch 'default': #21215: update debian/ubuntu build-dep instructions. http://hg.python.org/devguide/rev/84ccbb961f26 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 03:27:49 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Tue, 15 Apr 2014 01:27:49 +0000 Subject: [issue21229] Path used for HTTP PUT request doesn't match the description In-Reply-To: <1397522183.41.0.398189687255.issue21229@psf.upfronthosting.co.za> Message-ID: <1397525269.49.0.792744059138.issue21229@psf.upfronthosting.co.za> Senthil Kumaran added the comment: A simple docs patch would definitely help here. Thanks for the bug report. ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 03:29:09 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 15 Apr 2014 01:29:09 +0000 Subject: [issue21215] build-deps instructions for Ubuntu In-Reply-To: <1397485129.87.0.0518806030798.issue21215@psf.upfronthosting.co.za> Message-ID: <1397525349.65.0.195963289615.issue21215@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, Glenn. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 03:31:56 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Tue, 15 Apr 2014 01:31:56 +0000 Subject: [issue20578] BufferedIOBase.readinto1 is missing In-Reply-To: <1391991229.05.0.363628736117.issue20578@psf.upfronthosting.co.za> Message-ID: <1397525516.38.0.064344926276.issue20578@psf.upfronthosting.co.za> Nikolaus Rath added the comment: Attached is an updated patch that - removes the code duplication in _pyio.BufferedIOBase - adds an internal _readinto helper method to _pyio.BufferedReader that makes the implementation similar to io.BufferedReader. - implements _pyio.BuffereadReader.{readinto,readinto1} in terms of the new helper method and, as a side effect, also increases their performance. Performance of the _pyio implementation on my system is: pre-patch: readinto: 5.130e+00 seconds readinto1 not available post-patch: readinto: 2.039e+00 seconds readinto1: 1.995e+00 seconds ---------- Added file: http://bugs.python.org/file34863/issue20578_r3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 03:32:18 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Tue, 15 Apr 2014 01:32:18 +0000 Subject: [issue20578] BufferedIOBase.readinto1 is missing In-Reply-To: <1391991229.05.0.363628736117.issue20578@psf.upfronthosting.co.za> Message-ID: <1397525538.56.0.992892834979.issue20578@psf.upfronthosting.co.za> Changes by Nikolaus Rath : Added file: http://bugs.python.org/file34864/benchmark_r3.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 03:47:14 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 15 Apr 2014 01:47:14 +0000 Subject: [issue15795] Zipfile.extractall does not preserve file permissions In-Reply-To: <1346106964.12.0.723201722432.issue15795@psf.upfronthosting.co.za> Message-ID: <1397526434.07.0.233007082038.issue15795@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks. The patch contains a number of lines that are not wrapped to <80, which is one of our requirements. It would be great to get that fixed. (In the documentation, you can use \ to wrap the prototype line.) There is non-ascii in one place in the documentation...probably an em-dash, which is written in sphinx as '---'. Also, please remove the news entry from the patch, it will just make it harder to apply (and is in the wrong place anyway...we add entries at the top of the appropriate section, not the bottom). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 03:49:00 2014 From: report at bugs.python.org (=?utf-8?q?Evens_Fortun=C3=A9?=) Date: Tue, 15 Apr 2014 01:49:00 +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: <1397526540.2.0.623542805553.issue21228@psf.upfronthosting.co.za> Evens Fortun? added the comment: I don't quite understand what you are asking me. You need a copy of the document?? You can find an example at this link: https://docs.python.org/3/library/urllib.request.html#urllib.request.urlopen ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 03:50:12 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 15 Apr 2014 01:50:12 +0000 Subject: [issue12916] Add inspect.splitdoc In-Reply-To: <1315326747.38.0.43030903994.issue12916@psf.upfronthosting.co.za> Message-ID: <1397526612.43.0.353519948173.issue12916@psf.upfronthosting.co.za> R. David Murray added the comment: The precedent has already been set by the 'cleandoc' function, I think. This one seems to go right along with that one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 03:51:24 2014 From: report at bugs.python.org (=?utf-8?q?Evens_Fortun=C3=A9?=) Date: Tue, 15 Apr 2014 01:51:24 +0000 Subject: [issue21229] Path used for HTTP PUT request doesn't match the description In-Reply-To: <1397522183.41.0.398189687255.issue21229@psf.upfronthosting.co.za> Message-ID: <1397526684.48.0.549343302048.issue21229@psf.upfronthosting.co.za> Evens Fortun? added the comment: Do you have some documentation on how to do a "docs patch"?? I'm sorry this is the first time I'm reporting a bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 04:13:13 2014 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 15 Apr 2014 02:13:13 +0000 Subject: [issue21209] q.put(some_tuple) fails when PYTHONASYNCIODEBUG=1 In-Reply-To: <1397351442.01.0.248805040826.issue21209@psf.upfronthosting.co.za> Message-ID: <1397527993.07.0.377622365786.issue21209@psf.upfronthosting.co.za> Yury Selivanov added the comment: > [...] CoroWrapper.send() signature is different from a real generator's send() method, but I think that send() to a coroutine is an internal detail anyway [...] Yeah, and since it's used in debug mode only, I think we should be safe. > When you commit, can you do upstgream (Tulip) first? Sure, this patch was for tulip code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 04:29:46 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 15 Apr 2014 02:29:46 +0000 Subject: [issue21209] q.put(some_tuple) fails when PYTHONASYNCIODEBUG=1 In-Reply-To: <1397351442.01.0.248805040826.issue21209@psf.upfronthosting.co.za> Message-ID: <3g79dQ1DVrz7LjR@mail.python.org> Roundup Robot added the comment: New changeset 0c35d3616df5 by Yury Selivanov in branch '3.4': asyncio.tasks: Fix CoroWrapper to workaround yield-from bug in CPython < 3.4.1 http://hg.python.org/cpython/rev/0c35d3616df5 New changeset 13ff8645be57 by Yury Selivanov in branch 'default': syncio.tasks: Fix CoroWrapper to workaround yield-from bug in CPython < 3.4.1 http://hg.python.org/cpython/rev/13ff8645be57 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 04:30:19 2014 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 15 Apr 2014 02:30:19 +0000 Subject: [issue21209] q.put(some_tuple) fails when PYTHONASYNCIODEBUG=1 In-Reply-To: <1397351442.01.0.248805040826.issue21209@psf.upfronthosting.co.za> Message-ID: <1397529019.48.0.199320602617.issue21209@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 05:01:53 2014 From: report at bugs.python.org (Alex Gaynor) Date: Tue, 15 Apr 2014 03:01:53 +0000 Subject: [issue21231] Issue a python 3 warning when old style classes are defined. Message-ID: <1397530913.57.0.912065211904.issue21231@psf.upfronthosting.co.za> New submission from Alex Gaynor: This will assist in porting applications from Python2 to Python3. ---------- files: old-style-classes.diff keywords: patch messages: 216273 nosy: alex priority: normal severity: normal status: open title: Issue a python 3 warning when old style classes are defined. type: enhancement versions: Python 2.7 Added file: http://bugs.python.org/file34865/old-style-classes.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 05:20:46 2014 From: report at bugs.python.org (Kushal Das) Date: Tue, 15 Apr 2014 03:20:46 +0000 Subject: [issue21229] Path used for HTTP PUT request doesn't match the description In-Reply-To: <1397522183.41.0.398189687255.issue21229@psf.upfronthosting.co.za> Message-ID: <1397532046.68.0.776139247272.issue21229@psf.upfronthosting.co.za> Kushal Das added the comment: You should have a look at the following guides: https://docs.python.org/devguide/docquality.html https://docs.python.org/devguide/patch.html ---------- nosy: +kushal.das _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 05:22:21 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Tue, 15 Apr 2014 03:22:21 +0000 Subject: [issue21229] Path used for HTTP PUT request doesn't match the description In-Reply-To: <1397522183.41.0.398189687255.issue21229@psf.upfronthosting.co.za> Message-ID: <1397532141.67.0.0534104821889.issue21229@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Sure, here is the information on how to create a patch - https://docs.python.org/devguide/ It could feel that there are multiple steps, but the process is easy. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 06:26:02 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Tue, 15 Apr 2014 04:26:02 +0000 Subject: [issue20983] Python 3.4 'repair' Windows installation does not install pip & setuptools packages In-Reply-To: <1395248368.62.0.321132661018.issue20983@psf.upfronthosting.co.za> Message-ID: <1397535962.79.0.925990430624.issue20983@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Don: This is not a helpdesk system, but a bug tracker; the difference is that we don't help you here, but you help us. If you need help yourself, I suggest subscribing to python-list, at https://mail.python.org/mailman/listinfo/python-list and posting a question there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 07:29:59 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 15 Apr 2014 05:29:59 +0000 Subject: [issue21192] Idle: Print filename when running a file from editor In-Reply-To: <1397078686.2.0.0309283772804.issue21192@psf.upfronthosting.co.za> Message-ID: <1397539799.52.0.214939216044.issue21192@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I have not tried your patch yet, but the relevant code seems to be class ModifiedInterpreter(InteractiveInterpreter): def runcode(self, code): if code.co_filename[0] != '<': ## your patch self.tkconsole.write('Executing ' + code.co_filename + '\n') if self.tkconsole.executing: self.interp.restart_subprocess() def restart_subprocess(self, with_cwd=False): if was_executing: console.write('\n') console.showprompt() halfbar = ((int(console.width) - 16) // 2) * '=' console.write(halfbar + ' RESTART ' + halfbar) The 2 problems I see with the patch are that 1) it prints prematurely and 2) it does not replace RESTART. Both should be solved by passing the title string to restart_process as a new 'title' arg (title=' RESTART '). The halfbar expression should use len(title). I believe 16 is 9 (len(' RESTART ')) + 4 (len('>>> ')) + 3 (console.width (80) - 77). So halfbar = ((int(console.width) - len(title) - 7) // 2) * '=' I think the bar would be better without a prompt before it. If console.showprompt() is deleted, 7 becomes 3. I will code this later. ---------- assignee: -> terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 08:06:37 2014 From: report at bugs.python.org (Jayanth Koushik) Date: Tue, 15 Apr 2014 06:06:37 +0000 Subject: [issue21232] Use of '1' instead of 'True' as 'splitlines' argument in difflib documentation Message-ID: <1397541997.96.0.890116395425.issue21232@psf.upfronthosting.co.za> Changes by Jayanth Koushik : ---------- assignee: docs at python components: Documentation nosy: docs at python, jayanthkoushik priority: normal severity: normal status: open title: Use of '1' instead of 'True' as 'splitlines' argument in difflib documentation type: enhancement versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 08:10:31 2014 From: report at bugs.python.org (Jayanth Koushik) Date: Tue, 15 Apr 2014 06:10:31 +0000 Subject: [issue21232] Use of '1' instead of 'True' as 'splitlines' argument in difflib documentation Message-ID: <1397542231.28.0.662234584475.issue21232@psf.upfronthosting.co.za> New submission from Jayanth Koushik: In the difflib documentation, multiple uses of 'splitlines' use '1' as the 'keepends' argument. In Python 2.x, 1 is not guaranteed to be True and while this is guaranteed in 3.x, it would be much clearer to specify the argument as 'True'. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 09:05:14 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 15 Apr 2014 07:05:14 +0000 Subject: [issue8931] '#' has no effect with 'c' type In-Reply-To: <1275865635.78.0.716511257083.issue8931@psf.upfronthosting.co.za> Message-ID: <3g7HlF5xjmz7LjV@mail.python.org> Roundup Robot added the comment: New changeset 16efa8d27e4c by Eric V. Smith in branch '3.4': Closed issue #8931: Make alternate formatting for 'c' raise an exception. Patch by Torsten Landschoff. http://hg.python.org/cpython/rev/16efa8d27e4c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 09:05:48 2014 From: report at bugs.python.org (Eric V. Smith) Date: Tue, 15 Apr 2014 07:05:48 +0000 Subject: [issue8931] '#' has no effect with 'c' type In-Reply-To: <1275865635.78.0.716511257083.issue8931@psf.upfronthosting.co.za> Message-ID: <1397545548.34.0.0751100336938.issue8931@psf.upfronthosting.co.za> Changes by Eric V. Smith : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 09:43:34 2014 From: report at bugs.python.org (Wolfgang Maier) Date: Tue, 15 Apr 2014 07:43:34 +0000 Subject: [issue21146] update gzip usage examples in docs In-Reply-To: <1396521606.53.0.161098821761.issue21146@psf.upfronthosting.co.za> Message-ID: <1397547814.4.0.674633278349.issue21146@psf.upfronthosting.co.za> Wolfgang Maier added the comment: well, buffering is not the issue here. It's that the file iterator used in the current example is line-based, so whatever the buffer size you're doing unnecessary inspection to find and split on line terminators. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 10:56:01 2014 From: report at bugs.python.org (Nathaniel Smith) Date: Tue, 15 Apr 2014 08:56:01 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API Message-ID: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> New submission from Nathaniel Smith: Numpy would like to switch to using the CPython allocator interface in order to take advantage of the new tracemalloc infrastructure in 3.4. But, numpy relies on the availability of calloc(), and the CPython allocator API does not expose calloc(). https://docs.python.org/3.5/c-api/memory.html#c.PyMemAllocator So, we should add *Calloc variants. This met general approval on python-dev. Thread here: https://mail.python.org/pipermail/python-dev/2014-April/133985.html This would involve adding a new .calloc field to the PyMemAllocator struct, exposed through new API functions PyMem_RawCalloc, PyMem_Calloc, PyObject_Calloc. [It's not clear that all 3 would really be used, but since we have only one PyMemAllocator struct that they all share, it'd be hard to add support to only one or two of these domains and not the rest. And the higher-level calloc variants might well be used. Numpy array buffers are often small (e.g., holding only a single value), and these small buffers benefit from small-alloc optimizations; meanwhile, large buffers benefit from calloc optimizations. So it might be optimal to use a single allocator that has both.] We might also have to rename the PyMemAllocator struct to ensure that compiling old code with the new headers doesn't silently leave garbage in the .calloc field and lead to crashes. ---------- components: Interpreter Core messages: 216281 nosy: njs priority: normal severity: normal status: open title: Add *Calloc functions to CPython memory allocation API type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 11:00:27 2014 From: report at bugs.python.org (Marek Stepniowski) Date: Tue, 15 Apr 2014 09:00:27 +0000 Subject: [issue12220] minidom xmlns not handling spaces in xmlns attribute value field In-Reply-To: <1306789573.92.0.875996944294.issue12220@psf.upfronthosting.co.za> Message-ID: <1397552427.27.0.0443239069205.issue12220@psf.upfronthosting.co.za> Marek Stepniowski added the comment: I agree that "Unsupported syntax" is a more accurate message. Changed in the newest patch. ---------- Added file: http://bugs.python.org/file34866/minidom_space_char_in_namespace_unsupported.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 11:34:17 2014 From: report at bugs.python.org (Dima Tisnek) Date: Tue, 15 Apr 2014 09:34:17 +0000 Subject: [issue21191] os.fdopen() may eat file descriptor and still raise exception In-Reply-To: <1397067895.73.0.194150876234.issue21191@psf.upfronthosting.co.za> Message-ID: <1397554457.58.0.99289799944.issue21191@psf.upfronthosting.co.za> Dima Tisnek added the comment: Banjamin, Your patch looks good to me! I have a small concern regarding "We now know we will succeed..." -- should there be a test case to make sure fstat test here matches whatever test is/was done on a lower level? Or is your code now such that it will explicitly succeed because it doesn't call anything that can fail after the comment? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 11:41:10 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 15 Apr 2014 09:41:10 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1397554870.52.0.209252516099.issue21233@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 11:42:52 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 15 Apr 2014 09:42:52 +0000 Subject: [issue21227] Decimal class error messages for integer division aren't good In-Reply-To: <1397520159.39.0.440264883295.issue21227@psf.upfronthosting.co.za> Message-ID: <1397554972.83.0.693202403488.issue21227@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- assignee: docs at python -> skrah nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 14:56:48 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 15 Apr 2014 12:56:48 +0000 Subject: [issue21197] venv does not create lib64 directory and appropriate symlinks In-Reply-To: <1397137832.25.0.881871760177.issue21197@psf.upfronthosting.co.za> Message-ID: <3g7RXv41QHz7LkB@mail.python.org> Roundup Robot added the comment: New changeset 4d9b24b2f1b8 by Vinay Sajip in branch '3.4': Issue #21197: Add lib64 -> lib symlink in venvs on 64-bit non-OS X POSIX. http://hg.python.org/cpython/rev/4d9b24b2f1b8 New changeset 947515cc8957 by Vinay Sajip in branch 'default': Closes #21197: Add lib64 -> lib symlink in venvs on 64-bit non-OS X POSIX. http://hg.python.org/cpython/rev/947515cc8957 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 14:58:39 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 15 Apr 2014 12:58:39 +0000 Subject: [issue21191] os.fdopen() may eat file descriptor and still raise exception In-Reply-To: <1397554457.58.0.99289799944.issue21191@psf.upfronthosting.co.za> Message-ID: <1397566716.29084.106706669.56C920D2@webmail.messagingengine.com> Benjamin Peterson added the comment: On Tue, Apr 15, 2014, at 2:34, Dima Tisnek wrote: > > Dima Tisnek added the comment: > > Banjamin, Your patch looks good to me! > > I have a small concern regarding "We now know we will succeed..." -- > should there be a test case to make sure fstat test here matches whatever > test is/was done on a lower level? > > Or is your code now such that it will explicitly succeed because it > doesn't call anything that can fail after the comment? That's what I mean. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 15:04:23 2014 From: report at bugs.python.org (Jurjen N.E. Bos) Date: Tue, 15 Apr 2014 13:04:23 +0000 Subject: [issue21234] __contains__ and friends should check "is" for all elements first Message-ID: <1397567063.59.0.649029276797.issue21234@psf.upfronthosting.co.za> New submission from Jurjen N.E. Bos: It all started when adding an __equals__ method to a self made class. The effect was that my program slowed down enormously, which came as a surprise. This is because when doing an operation that does linear search through a container, the interpreter checks all items one by one, first checking identity and then equality. If the __equals__ method is slow, this is slower than needed. In python, you effectively get: class myContainer: def __contains__(self, obj): for i in range(len(self)): if self[i] is obj: return True if self[i]==obj: return True return False My proposal is to change this to: class myContainer: def __contains__(self, obj): for i in range(len(self)): if self[i] is obj: return True for i in range(len(self)): if self[i]==obj: return True return False The net effect would be approximately: - if the object is exactly in the container, the speedup is significant. - if the object is not in the container, there is no difference. - if an object is in the container that is equal to the object, it will be slower, but not very much. In the normal use case, this will probably feel to the user as a speed improvement, especially when the __equals__ is slow. I tried to find cases in which this would change behaviour of programs, but I couldn't find any. If this _does_ change behaviour in some noticeable and unwanted way, let me know! (Documenting would also be a good idea, then.) The accompanying file gives some timings to show what I mean, e.g. Time in us to find an exact match (begin, middle, end): 0.042335559340708886 31.610660936887758 62.69573781716389 Time in us to find an equal match (begin, middle, end): 0.3730294263293299 31.421928646805195 63.177373531221896 Time if not found: 63.44531546956001 And now for an object that has no __equal__: Time in us to find a thing (begin, middle, end): 0.03555453901338268 9.878883646121661 19.656711762284473 Time if not found: 19.676395048315776 (Python 2.7 does something completely different with objects without __equal__, so the test gives quite different results.) ---------- components: Interpreter Core files: containsDemo.py messages: 216286 nosy: jneb priority: normal severity: normal status: open title: __contains__ and friends should check "is" for all elements first type: performance versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file34867/containsDemo.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 15:14:13 2014 From: report at bugs.python.org (Vinay Sajip) Date: Tue, 15 Apr 2014 13:14:13 +0000 Subject: [issue21203] logging configurators ignoring documented options In-Reply-To: <1397252368.02.0.0923177521945.issue21203@psf.upfronthosting.co.za> Message-ID: <1397567653.27.0.634597527164.issue21203@psf.upfronthosting.co.za> Vinay Sajip added the comment: I'm not sure I can accept the change in 2.7, because it is technically a new feature and would mean that configs would not be treated the same way in all 2.7.x versions failing in some and not in others. You can get the equivalent behaviour using '()' rather than 'class', and the 'class' keyword is only mentioned in the docs against Handlers, not Formatters. The patch for the default branch looks OK. Thanks! ---------- versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 15:25:05 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 15 Apr 2014 13:25:05 +0000 Subject: [issue21203] logging configurators ignoring documented options In-Reply-To: <1397252368.02.0.0923177521945.issue21203@psf.upfronthosting.co.za> Message-ID: <3g7S9X2nsXz7LjT@mail.python.org> Roundup Robot added the comment: New changeset 2d33cbf02522 by Vinay Sajip in branch 'default': Closes #21203: Updated fileConfig and dictConfig to remove inconsistencies. Thanks to Jure Koren for the patch. http://hg.python.org/cpython/rev/2d33cbf02522 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 15:38:25 2014 From: report at bugs.python.org (Chris Rose) Date: Tue, 15 Apr 2014 13:38:25 +0000 Subject: [issue20752] Difflib should provide the option of overriding the SequenceMatcher In-Reply-To: <1393193816.17.0.662615840954.issue20752@psf.upfronthosting.co.za> Message-ID: <1397569105.45.0.10495459744.issue20752@psf.upfronthosting.co.za> Chris Rose added the comment: Updated according to review. ---------- Added file: http://bugs.python.org/file34868/difflib-sm.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 15:51:36 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Tue, 15 Apr 2014 13:51:36 +0000 Subject: [issue20752] Difflib should provide the option of overriding the SequenceMatcher In-Reply-To: <1393193816.17.0.662615840954.issue20752@psf.upfronthosting.co.za> Message-ID: <1397569896.81.0.8062009301.issue20752@psf.upfronthosting.co.za> Claudiu.Popa added the comment: Hi. I added a couple of comments for your previous patch, the new one doesn't seem to have a review link. ---------- nosy: +Claudiu.Popa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 16:07:55 2014 From: report at bugs.python.org (Chris Rose) Date: Tue, 15 Apr 2014 14:07:55 +0000 Subject: [issue20752] Difflib should provide the option of overriding the SequenceMatcher In-Reply-To: <1393193816.17.0.662615840954.issue20752@psf.upfronthosting.co.za> Message-ID: <1397570875.35.0.337601487737.issue20752@psf.upfronthosting.co.za> Chris Rose added the comment: Addressed comments regarding documentation and assertion formats in the test. ---------- Added file: http://bugs.python.org/file34869/difflib-sm.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 16:10:54 2014 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 15 Apr 2014 14:10:54 +0000 Subject: [issue21209] q.put(some_tuple) fails when PYTHONASYNCIODEBUG=1 In-Reply-To: <1397351442.01.0.248805040826.issue21209@psf.upfronthosting.co.za> Message-ID: <1397571054.82.0.549259184177.issue21209@psf.upfronthosting.co.za> Yury Selivanov added the comment: Guido, I'm feeling a bit uncomfortable with the patch I pushed. I think we should adjust the solution, to avoid having arguments to 'gen.send' packed in two nested tuples. Please take a look at the new patch (corowrapper_03.patch). It adds some amount of ugliness, but with it in place, I'd be more sure that we don't brake anything. ---------- Added file: http://bugs.python.org/file34870/corowrapper_03.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 16:15:08 2014 From: report at bugs.python.org (Chris Rose) Date: Tue, 15 Apr 2014 14:15:08 +0000 Subject: [issue20752] Difflib should provide the option of overriding the SequenceMatcher In-Reply-To: <1393193816.17.0.662615840954.issue20752@psf.upfronthosting.co.za> Message-ID: <1397571308.02.0.406746632069.issue20752@psf.upfronthosting.co.za> Chris Rose added the comment: Patch against tip ---------- Added file: http://bugs.python.org/file34871/difflib-sm.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 16:24:03 2014 From: report at bugs.python.org (Kushal Das) Date: Tue, 15 Apr 2014 14:24:03 +0000 Subject: [issue17861] put opcode information in one place In-Reply-To: <1367162089.6.0.986391601417.issue17861@psf.upfronthosting.co.za> Message-ID: <1397571843.87.0.438579734101.issue17861@psf.upfronthosting.co.za> Kushal Das added the comment: New patch from a clean repo, with changed opcode.h ---------- Added file: http://bugs.python.org/file34872/issue17861_v5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 16:24:41 2014 From: report at bugs.python.org (Armin Ronacher) Date: Tue, 15 Apr 2014 14:24:41 +0000 Subject: [issue21235] importlib's spec module create algorithm is not exposed Message-ID: <1397571881.77.0.850697644958.issue21235@psf.upfronthosting.co.za> New submission from Armin Ronacher: 3.4 deprecates load_module on the loaders and now proposes to use create_module (optionally) and exec_module. Unfortunately for external callers these interfaces are not useful because you need to reimplement _SpecMethods.create and a whole bunch of other stuff for it. Right now a caller can get hold of _SpecMethods by importing from _frozen_importlib but that seems very unsupported and is obviously entirely not exposed. Is there a reason those methods are not on the ModuleSpec directly but on a private wrapper? Example usage: from types import ModuleType from importlib.machinery import ModuleSpec, SourceFileLoader from _frozen_importlib import _SpecMethods loader = SourceFileLoader('plugin_base', 'my_file.py') spec = ModuleSpec(name=loader.name, loader=loader) mod = _SpecMethods(spec).create() In the absence of _SpecMethods a caller needs to do this: from importlib.machinery import ModuleSpec, SourceFileLoader loader = SourceFileLoader('plugin_base', 'my_file.py') spec = ModuleSpec(name=loader.name, loader=loader) if not hasattr(loader, 'create_module'): module = types.ModuleType(loader.name) else: module = loader.create_module(spec) module.__loader__ = loader module.__spec__ = spec try: module.__package__ = spec.parent except AttributeError: pass loader.exec_module(module) (And that is not the whole logic yet) ---------- keywords: 3.4regression messages: 216295 nosy: aronacher priority: normal severity: normal status: open title: importlib's spec module create algorithm is not exposed versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 16:26:36 2014 From: report at bugs.python.org (Armin Ronacher) Date: Tue, 15 Apr 2014 14:26:36 +0000 Subject: [issue21235] importlib's spec module create algorithm is not exposed In-Reply-To: <1397571881.77.0.850697644958.issue21235@psf.upfronthosting.co.za> Message-ID: <1397571996.83.0.612434959011.issue21235@psf.upfronthosting.co.za> Armin Ronacher added the comment: On further investigation that is not even enough yet due to the new locking mechanism. I'm not even sure if exposing _SpecMethods would be enough. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 16:32:56 2014 From: report at bugs.python.org (Michael Stahl) Date: Tue, 15 Apr 2014 14:32:56 +0000 Subject: [issue837046] pyport.h redeclares gethostname() if SOLARIS is defined Message-ID: <1397572376.58.0.728089784749.issue837046@psf.upfronthosting.co.za> Michael Stahl added the comment: we carry a patch in LibreOffice for exactly this problem: http://cgit.freedesktop.org/libreoffice/core/tree/external/python3/python-3.3.0-i42553.patch.2 this was found many years ago in OOo: https://issues.apache.org/ooo/show_bug.cgi?id=42553 there is at least one file in the LO code which includes pyport.h (which i have just verified via generated header dependencies), and the LO build system globally defines a SOLARIS macro on that platform, so there's a real-world problem caused by this. so if you could re-open this and merge that patch we could finally get rid of it on our side; there doesn't appear to be a downside to me since according to this bug report the prototype is wrong for Solaris 2.6 already, and older versions ought to have died out by now. ---------- nosy: +mst _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 16:41:45 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 15 Apr 2014 14:41:45 +0000 Subject: [issue1650090] doctest doesn't find nested functions Message-ID: <1397572905.77.0.0505143643017.issue1650090@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 16:46:30 2014 From: report at bugs.python.org (Glenn Jones) Date: Tue, 15 Apr 2014 14:46:30 +0000 Subject: [issue15795] Zipfile.extractall does not preserve file permissions In-Reply-To: <1346106964.12.0.723201722432.issue15795@psf.upfronthosting.co.za> Message-ID: <1397573190.81.0.936438881955.issue15795@psf.upfronthosting.co.za> Glenn Jones added the comment: Patch cleaned up based on previous comments. ---------- Added file: http://bugs.python.org/file34873/issue15795_cleaned.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 16:48:37 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Tue, 15 Apr 2014 14:48:37 +0000 Subject: [issue21027] difflib new cli interface In-Reply-To: <1395521056.07.0.611061866436.issue21027@psf.upfronthosting.co.za> Message-ID: <1397573317.78.0.688809324018.issue21027@psf.upfronthosting.co.za> Claudiu.Popa added the comment: Raymond, any news on this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 16:50:58 2014 From: report at bugs.python.org (Christian Hudon) Date: Tue, 15 Apr 2014 14:50:58 +0000 Subject: [issue1704474] optparse tests fail under Jython Message-ID: <1397573458.47.0.0629332151204.issue1704474@psf.upfronthosting.co.za> Christian Hudon added the comment: Actually, the only optparse test failing on jython 2.7 beta 1 currently is the one that relies on sys.getrefcount. Adding a test_support.impl_detail() guard makes all the tests pass. (See attached patch.) I'd propose adding this patch to both the python3 and python2 tips, as it would make the life of other, non-cpython implementations easier, and then closing this bug. ---------- Added file: http://bugs.python.org/file34874/jython.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 16:55:53 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 15 Apr 2014 14:55:53 +0000 Subject: [issue21209] q.put(some_tuple) fails when PYTHONASYNCIODEBUG=1 In-Reply-To: <1397351442.01.0.248805040826.issue21209@psf.upfronthosting.co.za> Message-ID: <1397573753.16.0.955591775201.issue21209@psf.upfronthosting.co.za> STINNER Victor added the comment: "I think we should adjust the solution, to avoid having arguments to 'gen.send' packed in two nested tuples." I should check, but I think that Python create a tuple for you if you don't pass directly a tuple, so it's not very different. Anyway, it is only used for debug, so I don't think that performances matter here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 17:00:49 2014 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 15 Apr 2014 15:00:49 +0000 Subject: [issue21209] q.put(some_tuple) fails when PYTHONASYNCIODEBUG=1 In-Reply-To: <1397351442.01.0.248805040826.issue21209@psf.upfronthosting.co.za> Message-ID: <1397574049.57.0.683317105315.issue21209@psf.upfronthosting.co.za> Guido van Rossum added the comment: I agree with Yuri and I approve of the patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 17:01:56 2014 From: report at bugs.python.org (Eric Snow) Date: Tue, 15 Apr 2014 15:01:56 +0000 Subject: [issue21235] importlib's spec module create algorithm is not exposed In-Reply-To: <1397571881.77.0.850697644958.issue21235@psf.upfronthosting.co.za> Message-ID: <1397574116.33.0.497838921579.issue21235@psf.upfronthosting.co.za> Eric Snow added the comment: I agree that this is something we need to address in 3.5. Adding this to 3.4 won't be an option since it would require a new feature. However, Loader.load_module() is only deprecated (and won't be removed in 3.X), so the current approach will still work until we provide a new approach in 3.5. The only gap is that now it is possible (even if very unlikely) that in 3.4 you would run into a loader that does not implement load_module(), which would obviously break direct calls to the method. :( For 3.4 such direct calls in the stdlib to loader.load_module() were replaced with this (mostly): spec = importlib.util.spec_from_loader(name, loader) # or importlib.util.spec_from_file_location(...) methods = _SpecMethods(spec) mod = methods.load() As you already noted, this relies on a current implementation detail of importlib._bootstrap. We'd rather not encourage use of such private API so providing a simple replacement makes sense. Futhermore, for 3.5 (in the "soon" timeframe) I'm planning on working on improving the import system abstractions*. My expectation is that part of that will be exposing most or all of the functionality of _SpecMethods directly. At the same time I don't want that API to be a distraction. I think accomplishing both is doable. So you shouldn't need to worry about create() or anything else. * Suggestions welcome. :) You can email me directly (ericsnowcurrently at gmail.com). ---------- components: +Library (Lib) nosy: +brett.cannon, eric.snow, ncoghlan versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 17:04:56 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Tue, 15 Apr 2014 15:04:56 +0000 Subject: [issue15795] Zipfile.extractall does not preserve file permissions In-Reply-To: <1346106964.12.0.723201722432.issue15795@psf.upfronthosting.co.za> Message-ID: <1397574296.53.0.841334722751.issue15795@psf.upfronthosting.co.za> Claudiu.Popa added the comment: Hello. I added a couple of comments to your latest patch. ---------- nosy: +Claudiu.Popa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 17:10:31 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 15 Apr 2014 15:10:31 +0000 Subject: [issue20318] subprocess.Popen can hang in threaded applications in Python 2 In-Reply-To: <1390249819.03.0.991344131396.issue20318@psf.upfronthosting.co.za> Message-ID: <1397574631.2.0.691242116842.issue20318@psf.upfronthosting.co.za> Gregory P. Smith added the comment: I added a pointer to subprocess32 in the 2.7 subprocess docs in dd52365c8721. ---------- resolution: -> wont fix stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 17:13:37 2014 From: report at bugs.python.org (Caelyn McAulay) Date: Tue, 15 Apr 2014 15:13:37 +0000 Subject: [issue10523] argparse has problem parsing option files containing empty rows In-Reply-To: <1290635267.13.0.585990858581.issue10523@psf.upfronthosting.co.za> Message-ID: <1397574817.15.0.0669739786883.issue10523@psf.upfronthosting.co.za> Caelyn McAulay added the comment: I've attached a patch making the changes I suggested, assuming that the current behaviour is desirable. It documents the behaviour of argparse on files with blank lines and changes the way the error message that argparse generates when encountering unrecognized arguments is generated. When a blank line is included at the end of a file, the resulting error message is now: "argparse_example.py: error: unrecognized arguments: ''". This also makes it obvious when the problem is white space, e.g. if an argument has trailing spaces, this also makes that obvious. ---------- keywords: +patch Added file: http://bugs.python.org/file34875/argparse_blanklines.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 17:26:28 2014 From: report at bugs.python.org (Brett Cannon) Date: Tue, 15 Apr 2014 15:26:28 +0000 Subject: [issue21235] importlib's spec module create algorithm is not exposed In-Reply-To: <1397571881.77.0.850697644958.issue21235@psf.upfronthosting.co.za> Message-ID: <1397575588.04.0.577015314897.issue21235@psf.upfronthosting.co.za> Brett Cannon added the comment: Are you after just the module creation/initialization code so you can call exec_module() yourself, Armin, or do you want even more of the algorithm exposed (e.g. the lock stuff)? There are not tons of importlib users to the level of wanting to re-implement import to the level of wanting to control module creation, setting sys.modules manually, etc., so we are constantly trying to figure out how far to go in exposing things without going so far as to make it impossible to make changes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 17:29:05 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Tue, 15 Apr 2014 15:29:05 +0000 Subject: [issue20103] Documentation of itertools.accumulate is confused In-Reply-To: <1388592720.87.0.970906154406.issue20103@psf.upfronthosting.co.za> Message-ID: <1397575745.88.0.163503361714.issue20103@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 17:32:01 2014 From: report at bugs.python.org (Chris Rose) Date: Tue, 15 Apr 2014 15:32:01 +0000 Subject: [issue20752] Difflib should provide the option of overriding the SequenceMatcher In-Reply-To: <1393193816.17.0.662615840954.issue20752@psf.upfronthosting.co.za> Message-ID: <1397575921.15.0.700634863446.issue20752@psf.upfronthosting.co.za> Chris Rose added the comment: As a historical record, it should be noted that this is driven by an actual use case: I was experimenting with using Bazaar's patience diff implementation, and I saw that in order for them to use a custom sequence matcher, they had to essentially copy-paste and modify the stdlib diff methods in order to inject their own sequence matchers. That struck me as a bad thing, and that's pretty much what led to this. I welcome a discussion of the API itself; there's definitely a bit of an odd challenge in describing the usage of the matcher variants when both are used (in line_matcher and char_matcher roles). A possible approach would be to consider matcher factories to take _just_ a junk function, nothing else, and use the SequenceMatcher API's set_seqs method to actually provide the sequences in all cases. This fits the character use case, which reuses the matcher, and the line use case which does not. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 17:33:35 2014 From: report at bugs.python.org (Michael Stahl) Date: Tue, 15 Apr 2014 15:33:35 +0000 Subject: [issue21236] patch to use cabinet.lib instead of fci.lib (fixes build with Windows SDK 8.0) Message-ID: <1397576015.94.0.746613486015.issue21236@psf.upfronthosting.co.za> New submission from Michael Stahl: building with MSVC2012 and the Windows SDK 8.0 fails according to this page, the fci.lib is no longer available and cabinet.lib should be used instead: http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/3b85f36e-dffe-4589-adc3-13673b349812/ "For Windows 8 onward fci.lib and fdi.lib will become private internal libraries and will not included in Windows SDK" here is a patch to do that: http://cgit.freedesktop.org/libreoffice/core/tree/external/python3/python-3.3.0-msvc2012.patch.1 the author of the patch is Peter Foley. ---------- components: Windows messages: 216309 nosy: mst priority: normal severity: normal status: open title: patch to use cabinet.lib instead of fci.lib (fixes build with Windows SDK 8.0) type: compile error versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 17:36:17 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Tue, 15 Apr 2014 15:36:17 +0000 Subject: [issue1704474] optparse tests fail under Jython Message-ID: <1397576177.61.0.491158308553.issue1704474@psf.upfronthosting.co.za> A.M. Kuchling added the comment: Patch to add impl_detail() looks fine to me. ---------- versions: +Python 2.7, Python 3.5 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 17:37:10 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 15 Apr 2014 15:37:10 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1397576230.41.0.810183601396.issue21233@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 17:37:44 2014 From: report at bugs.python.org (Michael Foord) Date: Tue, 15 Apr 2014 15:37:44 +0000 Subject: [issue21222] Mock create_autospec with name argument fails In-Reply-To: <1397505251.05.0.288307474202.issue21222@psf.upfronthosting.co.za> Message-ID: <1397576264.51.0.66624016785.issue21222@psf.upfronthosting.co.za> Michael Foord added the comment: You can use kwargs.pop instead of the two step fetch and delete. For the test, could you add an assert that the name is used. Can you add an extra underscore to the method name, to make it: test_create_autospec_with_name ---------- nosy: +michael.foord _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 17:39:19 2014 From: report at bugs.python.org (Christian Theune) Date: Tue, 15 Apr 2014 15:39:19 +0000 Subject: [issue18099] wsgiref sets Content-Length: 0 on 304 Not Modified In-Reply-To: <1369910008.93.0.397797975418.issue18099@psf.upfronthosting.co.za> Message-ID: <1397576359.35.0.287258746582.issue18099@psf.upfronthosting.co.za> Changes by Christian Theune : ---------- versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 17:41:37 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Tue, 15 Apr 2014 15:41:37 +0000 Subject: [issue15370] test_runpy should include namespace package tests In-Reply-To: <1342448771.76.0.81603722524.issue15370@psf.upfronthosting.co.za> Message-ID: <1397576497.21.0.0799425288292.issue15370@psf.upfronthosting.co.za> A.M. Kuchling added the comment: Because Nick both originally created this ticket and also added the new tests (http://hg.python.org/cpython/rev/51dddfead80a/), I'll assume he knew what he was doing when he named those methods, and simply forgot to close this issue. ---------- assignee: -> ncoghlan nosy: +akuchling resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 17:41:42 2014 From: report at bugs.python.org (Armin Ronacher) Date: Tue, 15 Apr 2014 15:41:42 +0000 Subject: [issue21235] importlib's spec module create algorithm is not exposed In-Reply-To: <1397571881.77.0.850697644958.issue21235@psf.upfronthosting.co.za> Message-ID: <1397576502.07.0.450261945885.issue21235@psf.upfronthosting.co.za> Armin Ronacher added the comment: I'm not sure myself what I need right now. I personally have avoided importlib/imp entirely for my code and I roll with manual module creation because it is most stable between 2.6 - 3.4 but it's getting more complicated to work because of all the new attributes (__package__, __spec__ etc.). This particular case came from SQLAlchemy I believe (I tried to help Mike Bayer transition his code). It's true that create() is the wrong function, load() is actually what should have been used there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 17:43:00 2014 From: report at bugs.python.org (Armin Ronacher) Date: Tue, 15 Apr 2014 15:43:00 +0000 Subject: [issue21235] importlib's spec module create algorithm is not exposed In-Reply-To: <1397571881.77.0.850697644958.issue21235@psf.upfronthosting.co.za> Message-ID: <1397576580.95.0.892977925522.issue21235@psf.upfronthosting.co.za> Armin Ronacher added the comment: Also mostly unrelated importlib now does something I have never seen an ABC do: the ABC has create_module but concrete implementations mostly have that function entirely absent. That should probably be reconsidered as it's super confusing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 17:45:50 2014 From: report at bugs.python.org (Brett Cannon) Date: Tue, 15 Apr 2014 15:45:50 +0000 Subject: [issue21237] Update Python 2/3 porting HOWTO's suggestion for dealing with map() Message-ID: <1397576750.55.0.0117658136784.issue21237@psf.upfronthosting.co.za> New submission from Brett Cannon: In Python 2.6 and newer you can import future_builtins and use everything from there. In Python 2.5 it should be itertools.imap(). This is much cleaner than the current suggestion at https://docs.python.org/2/howto/pyporting.html#update-map-for-imbalanced-input-sequences ---------- assignee: brett.cannon components: Documentation keywords: easy messages: 216315 nosy: brett.cannon priority: normal severity: normal stage: needs patch status: open title: Update Python 2/3 porting HOWTO's suggestion for dealing with map() type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 17:46:02 2014 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Tue, 15 Apr 2014 15:46:02 +0000 Subject: [issue21220] Enhance obmalloc allocation strategy In-Reply-To: <1397499786.06.0.606856949694.issue21220@psf.upfronthosting.co.za> Message-ID: <1397576762.75.0.415793495406.issue21220@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Update patch with suggestions from Larry ---------- Added file: http://bugs.python.org/file34876/obmalloc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 17:47:22 2014 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Tue, 15 Apr 2014 15:47:22 +0000 Subject: [issue20438] inspect: Deprecate getfullargspec? In-Reply-To: <1391014813.06.0.594760406572.issue20438@psf.upfronthosting.co.za> Message-ID: <1397576842.64.0.18891496455.issue20438@psf.upfronthosting.co.za> St?phane Wirtel added the comment: In this patch, I deprecate the inspect.getfullargspec function in the documentation and raise an warnings.warn with DeprecationWarning. Need feedback, because the inspect.getargspec() informs the user that it can use the getfullargspec() and I think we should use inspect.signature instead of inspect.getfullargspec() and inspect.getargspec(). Thank you ---------- keywords: +patch nosy: +matrixise Added file: http://bugs.python.org/file34877/issue20438_deprecate_inspect-getfullargspec.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 17:47:48 2014 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Tue, 15 Apr 2014 15:47:48 +0000 Subject: [issue20438] inspect: Deprecate getfullargspec? In-Reply-To: <1391014813.06.0.594760406572.issue20438@psf.upfronthosting.co.za> Message-ID: <1397576868.73.0.72767935042.issue20438@psf.upfronthosting.co.za> St?phane Wirtel added the comment: Here is the output of my test: > ./python3.5 -Wd test.py test.py:9: DeprecationWarning: Deprecated warnings.warn('Deprecated', DeprecationWarning) /private/tmp/python/lib/python3.5/inspect.py:955: DeprecationWarning: Use inspect.signature() instead of inspect.getfullargspec() warnings.warn("Use inspect.signature() instead of inspect.getfullargspec()", DeprecationWarning) FullArgSpec(args=[], varargs='args', varkw='kwargs', defaults=None, kwonlyargs=[], kwonlydefaults=None, annotations={}) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 17:47:58 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Tue, 15 Apr 2014 15:47:58 +0000 Subject: [issue984870] curses: getmaxyx() breaks when the window shrinks Message-ID: <1397576878.83.0.539442831091.issue984870@psf.upfronthosting.co.za> A.M. Kuchling added the comment: I agree with Chris's logic; the incorrect size seems to be a curses/ncurses bug that has gotten fixed somewhere along the line. You also aren't able to shrink the terminal to be smaller than the size of a derived window created with derwin(), but you seem to get an exception when you try rather than a crash. This seems reasonable to me. I don't think we need to document this behaviour, because that edge case would really belong in the ncurses documentation (and they might change it from version to version). ---------- resolution: -> invalid stage: test needed -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 17:51:18 2014 From: report at bugs.python.org (Michael Foord) Date: Tue, 15 Apr 2014 15:51:18 +0000 Subject: [issue21238] unittest.mock.Mock should not allow you to use non-existent assert methods Message-ID: <1397577078.96.0.678735725627.issue21238@psf.upfronthosting.co.za> New submission from Michael Foord: A common problem with unittest.mock.Mock is to mistype an assert method. Because mocks create attributes on demand your test will pass without error. We should raise an AttributeError if you access any attribute name (that doesn't exist) starting with assert or assret. There should also be a keyword argument allowing you to get the old behaviour if you need it (but this new feature should be on by default). Will also need docs. ---------- assignee: michael.foord components: Library (Lib) messages: 216320 nosy: kushal.das, michael.foord priority: normal severity: normal stage: needs patch status: open title: unittest.mock.Mock should not allow you to use non-existent assert methods type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 17:52:21 2014 From: report at bugs.python.org (Christian Hudon) Date: Tue, 15 Apr 2014 15:52:21 +0000 Subject: [issue20103] Documentation of itertools.accumulate is confused In-Reply-To: <1388592720.87.0.970906154406.issue20103@psf.upfronthosting.co.za> Message-ID: <1397577141.53.0.79783187451.issue20103@psf.upfronthosting.co.za> Christian Hudon added the comment: Second revision, incorporating comments. Also document the behavior when passed an empty input iterable. ---------- Added file: http://bugs.python.org/file34878/accumulate2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 17:53:51 2014 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 15 Apr 2014 15:53:51 +0000 Subject: [issue21235] importlib's spec module create algorithm is not exposed In-Reply-To: <1397571881.77.0.850697644958.issue21235@psf.upfronthosting.co.za> Message-ID: <1397577230.99.0.314303492162.issue21235@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 17:54:31 2014 From: report at bugs.python.org (Michael Foord) Date: Tue, 15 Apr 2014 15:54:31 +0000 Subject: [issue21239] unittest.mock.patch.stopall intermittently doesn't work when the same thing is patched multiple times Message-ID: <1397577271.48.0.402954348215.issue21239@psf.upfronthosting.co.za> New submission from Michael Foord: stopall does not always stop all patches to single target http://code.google.com/p/mock/issues/detail?id=226 What steps will reproduce the problem? python code to reproduce error import mock def myfunc(): return 'hello' m = mock.patch('__main__.myfunc').start() m.return_value = 'firstmock' myfunc() m2 = mock.patch('__main__.myfunc').start() m2.return_value = 'secondmock' myfunc() mock.patch.stopall() myfunc() What is the expected output? What do you see instead? I would expect the output from above to be: 'firstmock' 'secondmock' 'hello' Instead, sometimes it comes out as: 'firstmock' 'secondmock' 'firstmock' This result is non-deterministic though so it may also come out as expected. Re-run several times to get the error. This is a result of using a set to store the active patches. Conversion from a set to a list is non-deterministic because the set has no notion of order. Please provide any additional information below. This use case may seem strange, but it shows up in large unit tests where a base class sets up a default patch to catch external calls or something similar and then an individual unit test requiring specific mock behavior patches it differently. I have a patch here that fixes the problem using a list to store the patches to maintain order and call them in reverse order to stop them in the correct order. https://code.google.com/r/blak111-mockfix/source/detail?r=3c2f72b0253075d628afb333a79b7cb118132294 ---------- assignee: michael.foord messages: 216322 nosy: michael.foord priority: normal severity: normal stage: patch review status: open title: unittest.mock.patch.stopall intermittently doesn't work when the same thing is patched multiple times type: behavior versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 17:56:56 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 15 Apr 2014 15:56:56 +0000 Subject: [issue11316] RFC822 header parsing API inconsistencies between httplib.HTTPMessage and email.message.Message In-Reply-To: <1298630272.85.0.58708707749.issue11316@psf.upfronthosting.co.za> Message-ID: <1397577416.85.0.961694649726.issue11316@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 17:57:26 2014 From: report at bugs.python.org (Eric Snow) Date: Tue, 15 Apr 2014 15:57:26 +0000 Subject: [issue21240] Add an abstactmethod directive to the Python ReST domain Message-ID: <1397577446.45.0.129673687933.issue21240@psf.upfronthosting.co.za> New submission from Eric Snow: I'd like to be able to mark abstract methods in the docs more explicitly and have their presentation in the docs be more obvious. So I'd like to propose "abstractmethod" as a new directive to join the existing ones (classmethod, staticmethod, etc.). (This is motivated by msg216314.) ---------- assignee: docs at python components: Documentation messages: 216323 nosy: docs at python, eric.snow priority: normal severity: normal status: open title: Add an abstactmethod directive to the Python ReST domain type: enhancement versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 17:58:46 2014 From: report at bugs.python.org (Eric Snow) Date: Tue, 15 Apr 2014 15:58:46 +0000 Subject: [issue21235] importlib's spec module create algorithm is not exposed In-Reply-To: <1397571881.77.0.850697644958.issue21235@psf.upfronthosting.co.za> Message-ID: <1397577526.89.0.172938919812.issue21235@psf.upfronthosting.co.za> Eric Snow added the comment: I've opened up #21240 to address the the docs concern. Thanks for bringing it up. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 18:02:26 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 15 Apr 2014 16:02:26 +0000 Subject: [issue21209] q.put(some_tuple) fails when PYTHONASYNCIODEBUG=1 In-Reply-To: <1397351442.01.0.248805040826.issue21209@psf.upfronthosting.co.za> Message-ID: <3g7Wg540Qzz7LjR@mail.python.org> Roundup Robot added the comment: New changeset 2729823525fe by Yury Selivanov in branch '3.4': asyncio.tasks: Make sure CoroWrapper.send proxies one argument correctly http://hg.python.org/cpython/rev/2729823525fe New changeset 552ee474f3e7 by Yury Selivanov in branch 'default': asyncio.tasks: Make sure CoroWrapper.send proxies one argument correctly http://hg.python.org/cpython/rev/552ee474f3e7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 18:02:42 2014 From: report at bugs.python.org (Brett Cannon) Date: Tue, 15 Apr 2014 16:02:42 +0000 Subject: [issue21240] Add an abstactmethod directive to the Python ReST domain In-Reply-To: <1397577446.45.0.129673687933.issue21240@psf.upfronthosting.co.za> Message-ID: <1397577762.9.0.0699371980461.issue21240@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 18:05:12 2014 From: report at bugs.python.org (Jure Koren) Date: Tue, 15 Apr 2014 16:05:12 +0000 Subject: [issue21203] logging configurators ignoring documented options In-Reply-To: <1397252368.02.0.0923177521945.issue21203@psf.upfronthosting.co.za> Message-ID: <1397577912.56.0.760095320957.issue21203@psf.upfronthosting.co.za> Jure Koren added the comment: I agree about the 2.7 branch, I did that one off the top of my head after struggling with backporting the code to 2.7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 18:16:35 2014 From: report at bugs.python.org (Brett Cannon) Date: Tue, 15 Apr 2014 16:16:35 +0000 Subject: [issue20438] inspect: Deprecate getfullargspec? In-Reply-To: <1391014813.06.0.594760406572.issue20438@psf.upfronthosting.co.za> Message-ID: <1397578595.64.0.533522695234.issue20438@psf.upfronthosting.co.za> Brett Cannon added the comment: I was thinking about suggesting we don't code deprecate getfullargspec() but the function seems to be new to Python 3 and so that worry for Python 2/3 code is not founded. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 18:20:06 2014 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 15 Apr 2014 16:20:06 +0000 Subject: [issue20438] inspect: Deprecate getfullargspec? In-Reply-To: <1391014813.06.0.594760406572.issue20438@psf.upfronthosting.co.za> Message-ID: <1397578806.88.0.811551053529.issue20438@psf.upfronthosting.co.za> Yury Selivanov added the comment: How about we deprecate with a warning getfullargspec(); deprecate getargspec() in docs only (in 3.6 we'll fully deprecate all function parameters API except Signature)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 18:24:46 2014 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 15 Apr 2014 16:24:46 +0000 Subject: [issue21209] q.put(some_tuple) fails when PYTHONASYNCIODEBUG=1 In-Reply-To: <1397351442.01.0.248805040826.issue21209@psf.upfronthosting.co.za> Message-ID: <1397579086.02.0.350963200623.issue21209@psf.upfronthosting.co.za> Yury Selivanov added the comment: > I should check, but I think that Python create a tuple for you if you don't pass directly a tuple, so it's not very different. That's what I thought, but still, better to have the code clearly expressing what it does, than relying on obscure implementation/protocol details. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 18:24:52 2014 From: report at bugs.python.org (Florent Xicluna) Date: Tue, 15 Apr 2014 16:24:52 +0000 Subject: [issue21235] importlib's spec module create algorithm is not exposed In-Reply-To: <1397571881.77.0.850697644958.issue21235@psf.upfronthosting.co.za> Message-ID: <1397579092.27.0.566893099569.issue21235@psf.upfronthosting.co.za> Changes by Florent Xicluna : ---------- nosy: +flox type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 18:33:15 2014 From: report at bugs.python.org (Eric Olson) Date: Tue, 15 Apr 2014 16:33:15 +0000 Subject: [issue2159] dbmmodule inquiry function is performance prohibitive In-Reply-To: <1203640875.82.0.736964888757.issue2159@psf.upfronthosting.co.za> Message-ID: <1397579595.2.0.061253514336.issue2159@psf.upfronthosting.co.za> Eric Olson added the comment: The performance is still an issue in python 3. Attaching a patch for python 3, performance numbers are below. Measuring ndbm time for a falsey check on an open db with 100 entries. gdbm performance is similar. Before patch: db is not None: 6.9141387939453125e-06 not db: 0.0006985664367675781 Factor: 101X (slow) After patch: db is not None: 4.76837158203125e-06 not db: 4.0531158447265625e-06 Factor: 1X (expected) Also, added a couple tests to verify bool(db) returns the correct value. ---------- nosy: +eolson Added file: http://bugs.python.org/file34879/dbm_bool.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 18:37:44 2014 From: report at bugs.python.org (Sam Kimbrel) Date: Tue, 15 Apr 2014 16:37:44 +0000 Subject: [issue21075] fileinput should use stdin.buffer for "rb" mode In-Reply-To: <1395927763.6.0.283357087125.issue21075@psf.upfronthosting.co.za> Message-ID: <1397579864.15.0.0302272444286.issue21075@psf.upfronthosting.co.za> Sam Kimbrel added the comment: Patch attached that checks for 'b' in self._mode and sets self._file to sys.stdin.buffer as appropriate. ---------- keywords: +patch nosy: +sam.kimbrel Added file: http://bugs.python.org/file34880/21075-fileinput-stdin.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 18:39:54 2014 From: report at bugs.python.org (Berker Peksag) Date: Tue, 15 Apr 2014 16:39:54 +0000 Subject: [issue16236] Doc/Makefile should have $PYTHON=python2 In-Reply-To: <1350252917.6.0.180225296667.issue16236@psf.upfronthosting.co.za> Message-ID: <1397579994.79.0.654531939217.issue16236@psf.upfronthosting.co.za> Berker Peksag added the comment: You can now build the Python documentation with using Python 3. See msg216161 in issue 10224 for more information. ---------- nosy: +berker.peksag resolution: -> out of date stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 18:40:49 2014 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Tue, 15 Apr 2014 16:40:49 +0000 Subject: [issue20438] inspect: Deprecate getfullargspec? In-Reply-To: <1391014813.06.0.594760406572.issue20438@psf.upfronthosting.co.za> Message-ID: <1397580049.41.0.719300859721.issue20438@psf.upfronthosting.co.za> St?phane Wirtel added the comment: Just one thing, how do you work for the deprecation? 1. you deprecate in the doc for 3.5? 2. you deprecate in the code for 3.6? 3. you remove the code in 3.7? What's the strategy in this case or in general? Thanks ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 18:41:05 2014 From: report at bugs.python.org (Henk-Jaap Wagenaar) Date: Tue, 15 Apr 2014 16:41:05 +0000 Subject: [issue21241] Variable name with number causes interactive console to crash Message-ID: <1397580065.89.0.773898256837.issue21241@psf.upfronthosting.co.za> New submission from Henk-Jaap Wagenaar: Executing in the interactive console: "foo1 = 0" and then "foo1" gives "Segmentation Fault: 11" on OS X 10.9.2, Python 3.3.2 (v3.3.2:d047928ae3f6, May 13 2013, 13:52:24) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] If foo1 is defined in a program, and interactive mode is entered, assigning a value to it seg faults the console as well, but executing "foo1" *does* work. It does not seem to crash problems on my friends PC (running Ubuntu). ---------- messages: 216334 nosy: Henk-Jaap.Wagenaar priority: normal severity: normal status: open title: Variable name with number causes interactive console to crash versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 18:41:29 2014 From: report at bugs.python.org (Henk-Jaap Wagenaar) Date: Tue, 15 Apr 2014 16:41:29 +0000 Subject: [issue21241] Variable name with number causes interactive console to crash In-Reply-To: <1397580065.89.0.773898256837.issue21241@psf.upfronthosting.co.za> Message-ID: <1397580089.62.0.987666726872.issue21241@psf.upfronthosting.co.za> Changes by Henk-Jaap Wagenaar : ---------- type: -> crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 18:44:11 2014 From: report at bugs.python.org (Ned Deily) Date: Tue, 15 Apr 2014 16:44:11 +0000 Subject: [issue21241] Variable name with number causes interactive console to crash In-Reply-To: <1397580065.89.0.773898256837.issue21241@psf.upfronthosting.co.za> Message-ID: <1397580251.58.0.378497523524.issue21241@psf.upfronthosting.co.za> Ned Deily added the comment: See Issue18458. Update to the latest Python 3.3.5 or 3.4.0. ---------- nosy: +ned.deily resolution: -> duplicate stage: -> committed/rejected superseder: -> interactive interpreter crashes and test_readline fails on OS X 10.9 Mavericks due to libedit update _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 18:44:43 2014 From: report at bugs.python.org (Ned Deily) Date: Tue, 15 Apr 2014 16:44:43 +0000 Subject: [issue21241] Variable name with number causes interactive console to crash In-Reply-To: <1397580065.89.0.773898256837.issue21241@psf.upfronthosting.co.za> Message-ID: <1397580283.7.0.104002866539.issue21241@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 18:44:55 2014 From: report at bugs.python.org (Wolfgang Maier) Date: Tue, 15 Apr 2014 16:44:55 +0000 Subject: [issue21234] __contains__ and friends should check "is" for all elements first In-Reply-To: <1397567063.59.0.649029276797.issue21234@psf.upfronthosting.co.za> Message-ID: <1397580295.05.0.590575001739.issue21234@psf.upfronthosting.co.za> Wolfgang Maier added the comment: >> - if an object is in the container that is equal to the object, it will be slower, but not very much. You don't know that in general. It depends on where in the sequence the equal object sits, and also on how expensive the equality check is compared to the identity check. A simplified example over your rather lengthy one: >>> l=list(range(20000000)) >>> any(e is 9000000 or e == 9000000 for e in l) # mimicking current behaviour True >>> any(e is 9000000 for e in l) or any(e == 9000000 for e in l) # your suggestion True The second example takes about twice as long as the first one because the identity check has to be run on the whole list, when the equality check discovers the match half way through the sequence. Given that equality is usually more likely than identity, I guess, you would pay a price for your suggestion more often than you profit from it. ---------- nosy: +wolma _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 18:58:03 2014 From: report at bugs.python.org (Brett Cannon) Date: Tue, 15 Apr 2014 16:58:03 +0000 Subject: [issue20438] inspect: Deprecate getfullargspec? In-Reply-To: <1391014813.06.0.594760406572.issue20438@psf.upfronthosting.co.za> Message-ID: <1397581083.93.0.330609166055.issue20438@psf.upfronthosting.co.za> Brett Cannon added the comment: How warnings are handled vary from case to case. Typically its documentation-only if we want to warn people that they shouldn't use something because there is a better alternative but the code is not fundamentally broken and its in Python 2. If there is something wrong with it or it's just in Python 3 then a deprecation warning with a decided amount of time for when the code will be removed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 18:59:54 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 15 Apr 2014 16:59:54 +0000 Subject: [issue21220] Enhance obmalloc allocation strategy In-Reply-To: <1397499786.06.0.606856949694.issue21220@psf.upfronthosting.co.za> Message-ID: <1397581194.56.0.274160051799.issue21220@psf.upfronthosting.co.za> Antoine Pitrou added the comment: In Python 3, arenas are allocated using mmap(), so wherever the arena ends up in the address space shouldn't matter, should it? Also, the new strategy adds an O(n) component in the allocator. ---------- nosy: +neologix, pitrou, tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 19:02:52 2014 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Tue, 15 Apr 2014 17:02:52 +0000 Subject: [issue20438] inspect: Deprecate getfullargspec? In-Reply-To: <1391014813.06.0.594760406572.issue20438@psf.upfronthosting.co.za> Message-ID: <1397581372.32.0.425782882575.issue20438@psf.upfronthosting.co.za> St?phane Wirtel added the comment: ok, so in this case, I can only change the documentation with a ".. deprecated:". But for the future, how can we know we have to deprecate this function for >= 3.6 ? Will you parse the documentation and check there is an deprecation to add in the code? Or is there a file with the "future" deprecations? Are you agree with the deprecation in the documentation? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 19:07:30 2014 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 15 Apr 2014 17:07:30 +0000 Subject: [issue20438] inspect: Deprecate getfullargspec? In-Reply-To: <1391014813.06.0.594760406572.issue20438@psf.upfronthosting.co.za> Message-ID: <1397581650.45.0.29168929039.issue20438@psf.upfronthosting.co.za> Yury Selivanov added the comment: I'd +1 for: 1. Deprecating getfullargsspec in docs; 2. Deprecating getargspec in docs and code (since it's an ancient and outdated API) Brett? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 19:09:53 2014 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Tue, 15 Apr 2014 17:09:53 +0000 Subject: [issue20438] inspect: Deprecate getfullargspec? In-Reply-To: <1397581650.45.0.29168929039.issue20438@psf.upfronthosting.co.za> Message-ID: <59D69B14-D83C-421B-9EFA-60A8645575A9@wirtel.be> St?phane Wirtel added the comment: Brett, If you agree with Yury, I will provide a patch with these tasks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 19:28:29 2014 From: report at bugs.python.org (Brett Cannon) Date: Tue, 15 Apr 2014 17:28:29 +0000 Subject: [issue20438] inspect: Deprecate getfullargspec? In-Reply-To: <1391014813.06.0.594760406572.issue20438@psf.upfronthosting.co.za> Message-ID: <1397582909.93.0.605313091008.issue20438@psf.upfronthosting.co.za> Brett Cannon added the comment: Since getfullargspec is new in Python 3 and inspect.signature fundamentally improves things in Python 3 due to Argument Clinic I would say go ahead and code deprecate getfullargspec (we can do a DeprecationWarning for 3.5 and 3.6 and remove in 3.7; people needing compatibility can just use getargspec). As for getargspec, it was already deprecated so just leave it deprecated and update its message to say to use inspect.signature. As for keeping track of this stuff, St?phane, as part of the test that makes sure the warning is raised, add to that test -- don't need a separate method -- some code that will fail if the function exists in Python 3.7 or later. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 19:32:17 2014 From: report at bugs.python.org (Kushal Das) Date: Tue, 15 Apr 2014 17:32:17 +0000 Subject: [issue21222] Mock create_autospec with name argument fails In-Reply-To: <1397505251.05.0.288307474202.issue21222@psf.upfronthosting.co.za> Message-ID: <1397583137.6.0.909878259264.issue21222@psf.upfronthosting.co.za> Kushal Das added the comment: New patchset with changes made as suggested. ---------- Added file: http://bugs.python.org/file34881/issue21222_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 19:40:09 2014 From: report at bugs.python.org (A Kaptur) Date: Tue, 15 Apr 2014 17:40:09 +0000 Subject: [issue21217] inspect.getsourcelines finds wrong lines when lambda used argument to decorator In-Reply-To: <1397496660.33.0.566497694968.issue21217@psf.upfronthosting.co.za> Message-ID: <1397583609.14.0.41342815022.issue21217@psf.upfronthosting.co.za> A Kaptur added the comment: v2 of the patch incorporating the comments at http://bugs.python.org/review/21217/ ---------- Added file: http://bugs.python.org/file34882/issue21217-v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 19:45:39 2014 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 15 Apr 2014 17:45:39 +0000 Subject: [issue21217] inspect.getsourcelines finds wrong lines when lambda used argument to decorator In-Reply-To: <1397496660.33.0.566497694968.issue21217@psf.upfronthosting.co.za> Message-ID: <1397583939.69.0.083393486452.issue21217@psf.upfronthosting.co.za> Yury Selivanov added the comment: Apart from one nit, the patch is looking good. Also, could you please sign the contributor agreement, as described here: https://docs.python.org/devguide/coredev.html#sign-a-contributor-agreement ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 19:50:05 2014 From: report at bugs.python.org (Brett Cannon) Date: Tue, 15 Apr 2014 17:50:05 +0000 Subject: [issue21242] Generalize configure check for working Python executable Message-ID: <1397584205.03.0.366670026915.issue21242@psf.upfronthosting.co.za> New submission from Brett Cannon: configure.ac has a check that sets ASDLGEN based on what Python interpreter to use for running various scripts which generate files related to the AST. It probably should be generalized so that there's only one check for any script usage in Makefile.pre.in since there is really no need to check multiple times for the same thing. ---------- components: Build messages: 216346 nosy: brett.cannon, kushal.das priority: low severity: normal stage: needs patch status: open title: Generalize configure check for working Python executable versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 19:53:02 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 15 Apr 2014 17:53:02 +0000 Subject: [issue1521196] smtplib login fails with aol smtp server Message-ID: <1397584382.93.0.724889854964.issue1521196@psf.upfronthosting.co.za> R. David Murray added the comment: This will be fixed as part of issue 15014, which also adds support for providing user created auth methods. ---------- resolution: -> duplicate stage: test needed -> committed/rejected status: open -> closed superseder: -> smtplib: add support for arbitrary auth methods _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 19:53:23 2014 From: report at bugs.python.org (Kushal Das) Date: Tue, 15 Apr 2014 17:53:23 +0000 Subject: [issue17861] put opcode information in one place In-Reply-To: <1367162089.6.0.986391601417.issue17861@psf.upfronthosting.co.za> Message-ID: <1397584403.68.0.976792990394.issue17861@psf.upfronthosting.co.za> Kushal Das added the comment: New patch with changes as suggested by Brett. ---------- Added file: http://bugs.python.org/file34883/issue17861_v6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 19:58:44 2014 From: report at bugs.python.org (Caelyn McAulay) Date: Tue, 15 Apr 2014 17:58:44 +0000 Subject: [issue18229] attribute headers of http.server.BaseHTTPRequestHandler sometimes does not exists In-Reply-To: <1371376761.5.0.41138715811.issue18229@psf.upfronthosting.co.za> Message-ID: <1397584724.26.0.211351743201.issue18229@psf.upfronthosting.co.za> Caelyn McAulay added the comment: Added comment to documentation concerning when the headers attribute gets set. I confirmed that the headers attribute is only ever set in the parse_request method of BaseHTTPRequestHandler and only if the request is successfully parsed as HTTP. ---------- keywords: +patch nosy: +math_foo Added file: http://bugs.python.org/file34884/documentation18229.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 19:59:11 2014 From: report at bugs.python.org (Don DeZutter) Date: Tue, 15 Apr 2014 17:59:11 +0000 Subject: [issue20983] Python 3.4 'repair' Windows installation does not install pip & setuptools packages In-Reply-To: <1397535962.79.0.925990430624.issue20983@psf.upfronthosting.co.za> Message-ID: Don DeZutter added the comment: Martin: Thank you for your prompt and helpful response to my attempt to tag along to a possibly similar bug. I had been working on my issue for about two weeks and truly believed it was a bug before i adventured as I did. As you know, the difference between a problem and a bug is who comes up with the fix. I continued working my issue and discovered I could reinstall by running msiexec with the "/l *v" option and again with the "/fa /l*v" option which forces all file files to be reinstalled. I still consider this to be a bug in the Python installer because the installer does not truly repair. But I am a happy camper now will use the python-list you recommended. Don DeZutter On Mon, Apr 14, 2014 at 11:26 PM, Martin v. L?wis wrote: > > Martin v. L?wis added the comment: > > Don: This is not a helpdesk system, but a bug tracker; the difference is > that we don't help you here, but you help us. > > If you need help yourself, I suggest subscribing to python-list, at > > https://mail.python.org/mailman/listinfo/python-list > > and posting a question there. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 20:01:12 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Tue, 15 Apr 2014 18:01:12 +0000 Subject: [issue21217] inspect.getsourcelines finds wrong lines when lambda used argument to decorator In-Reply-To: <1397496660.33.0.566497694968.issue21217@psf.upfronthosting.co.za> Message-ID: <1397584872.59.0.47041518962.issue21217@psf.upfronthosting.co.za> Claudiu.Popa added the comment: "- We added tests of decorated classes. The source of decorated classes does not include the decorators, which is different than the usual behavior of decorated functions. What is the correct behavior here?" There is an open issue for this, http://bugs.python.org/issue1764286. It has a patch which uses inspect.unwrap in order to unwrap the decorated functions. ---------- nosy: +Claudiu.Popa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 20:02:34 2014 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 15 Apr 2014 18:02:34 +0000 Subject: [issue1764286] inspect.getsource does not work with decorated functions Message-ID: <1397584954.32.0.167547571282.issue1764286@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- assignee: -> yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 20:02:42 2014 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 15 Apr 2014 18:02:42 +0000 Subject: [issue21217] inspect.getsourcelines finds wrong lines when lambda used argument to decorator In-Reply-To: <1397496660.33.0.566497694968.issue21217@psf.upfronthosting.co.za> Message-ID: <1397584962.77.0.996926442639.issue21217@psf.upfronthosting.co.za> Yury Selivanov added the comment: Claudiu: I'll take a look at your patch, thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 20:08:49 2014 From: report at bugs.python.org (Meador Inge) Date: Tue, 15 Apr 2014 18:08:49 +0000 Subject: [issue21242] Generalize configure check for working Python executable In-Reply-To: <1397584205.03.0.366670026915.issue21242@psf.upfronthosting.co.za> Message-ID: <1397585329.15.0.273000034418.issue21242@psf.upfronthosting.co.za> Meador Inge added the comment: I am not sure I follow. In configure.ac I see one check for Python: AC_SUBST(ASDLGEN) AC_CHECK_PROGS(PYTHON, python$PACKAGE_VERSION python3 python, not-found) if test "$PYTHON" = not-found; then ASDLGEN="@echo python: $PYTHON! cannot run \$(srcdir)/Parser/asdl_c.py #" else ASDLGEN="$PYTHON" fi and a couple of uses for it in Makefile.pre.in: $(AST_H): $(AST_ASDL) $(ASDLGEN_FILES) $(MKDIR_P) $(AST_H_DIR) $(ASDLGEN) -h $(AST_H_DIR) $(AST_ASDL) $(AST_C): $(AST_H) $(AST_ASDL) $(ASDLGEN_FILES) $(MKDIR_P) $(AST_C_DIR) $(ASDLGEN) -c $(AST_C_DIR) $(AST_ASDL) Are you suggesting that the variable name 'ASDLGEN" be renamed to something more general so that any scripts that need to be run *before* building the interpreter can use it? I don't see any other AC_CHECK_PROGS checks for Python in configure.ac. Apologies if I am being dense today :-) ---------- nosy: +meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 20:12:29 2014 From: report at bugs.python.org (Brett Cannon) Date: Tue, 15 Apr 2014 18:12:29 +0000 Subject: [issue21243] Auto-generate exceptions.c from a Python file Message-ID: <1397585549.14.0.873533303783.issue21243@psf.upfronthosting.co.za> New submission from Brett Cannon: There isn't very much that's special about the various exceptions (although maybe there will be some day). Anyway, it seems like we could, if we so desired, define the exceptions in Python and then auto-generate the C code. The other option is to obviously just load the exceptions from Python code, store the various objects in various C attributes, and update the C API for exceptions to operate off of the Python-defined exception objects (question is what performance impact that would have). The key question, though, is whether any of this is actually worth it. =) ---------- components: Interpreter Core messages: 216354 nosy: brett.cannon priority: low severity: normal stage: needs patch status: open title: Auto-generate exceptions.c from a Python file type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 20:15:32 2014 From: report at bugs.python.org (Meador Inge) Date: Tue, 15 Apr 2014 18:15:32 +0000 Subject: [issue21242] Generalize configure check for working Python executable In-Reply-To: <1397584205.03.0.366670026915.issue21242@psf.upfronthosting.co.za> Message-ID: <1397585732.6.0.905675483514.issue21242@psf.upfronthosting.co.za> Meador Inge added the comment: Ah, okay, this looks in reference to the opcode generation stuff in issue17861. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 20:16:35 2014 From: report at bugs.python.org (Brett Cannon) Date: Tue, 15 Apr 2014 18:16:35 +0000 Subject: [issue21242] Generalize configure check for working Python executable In-Reply-To: <1397584205.03.0.366670026915.issue21242@psf.upfronthosting.co.za> Message-ID: <1397585795.29.0.944191750514.issue21242@psf.upfronthosting.co.za> Brett Cannon added the comment: You figured out the reason for the interest; I filed the bug faster than Kushal could commit his code. =) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 20:18:05 2014 From: report at bugs.python.org (A Kaptur) Date: Tue, 15 Apr 2014 18:18:05 +0000 Subject: [issue21217] inspect.getsourcelines finds wrong lines when lambda used argument to decorator In-Reply-To: <1397496660.33.0.566497694968.issue21217@psf.upfronthosting.co.za> Message-ID: <1397585885.49.0.234619996809.issue21217@psf.upfronthosting.co.za> A Kaptur added the comment: v3 of patch, including misc/news update, docstring for function, and removing class decorator tests, since it sounds like those are better handled in http://bugs.python.org/issue1764286. ---------- Added file: http://bugs.python.org/file34885/issue21217-v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 20:22:27 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 15 Apr 2014 18:22:27 +0000 Subject: [issue17861] put opcode information in one place In-Reply-To: <1367162089.6.0.986391601417.issue17861@psf.upfronthosting.co.za> Message-ID: <3g7Zmf6vLNz7LjT@mail.python.org> Roundup Robot added the comment: New changeset 56e7fa27f979 by Kushal Das in branch 'default': Closes Issue 17861: Autogenerate Include/opcode.h from opcode.py. http://hg.python.org/cpython/rev/56e7fa27f979 ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 20:36:33 2014 From: report at bugs.python.org (Ned Deily) Date: Tue, 15 Apr 2014 18:36:33 +0000 Subject: [issue21236] patch to use cabinet.lib instead of fci.lib (fixes build with Windows SDK 8.0) In-Reply-To: <1397576015.94.0.746613486015.issue21236@psf.upfronthosting.co.za> Message-ID: <1397586993.75.0.610410622902.issue21236@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- components: +Build nosy: +loewis, zach.ware type: compile error -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 20:38:40 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 15 Apr 2014 18:38:40 +0000 Subject: [issue21223] fix test_site/test_startup_imports when some of the extensions are built as builtins In-Reply-To: <1397507113.83.0.846424139619.issue21223@psf.upfronthosting.co.za> Message-ID: <3g7b7N2ThDz7Lm2@mail.python.org> Roundup Robot added the comment: New changeset ebb9595af548 by doko in branch '3.4': - Issue #21223: Pass test_site/test_startup_imports when some of the extensions http://hg.python.org/cpython/rev/ebb9595af548 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 20:50:23 2014 From: report at bugs.python.org (Matthias Klose) Date: Tue, 15 Apr 2014 18:50:23 +0000 Subject: [issue21223] fix test_site/test_startup_imports when some of the extensions are built as builtins In-Reply-To: <1397507113.83.0.846424139619.issue21223@psf.upfronthosting.co.za> Message-ID: <1397587823.1.0.160041009398.issue21223@psf.upfronthosting.co.za> Changes by Matthias Klose : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 20:52:49 2014 From: report at bugs.python.org (Berker Peksag) Date: Tue, 15 Apr 2014 18:52:49 +0000 Subject: [issue17660] mock.patch could whitelist builtins to not need create=True In-Reply-To: <1365418089.99.0.0976801798706.issue17660@psf.upfronthosting.co.za> Message-ID: <1397587969.75.0.403064114678.issue17660@psf.upfronthosting.co.za> Berker Peksag added the comment: + .. note:: I think using a note directive is not necessary here. Also it looks a bit ugly :) https://dl.dropboxusercontent.com/u/166024/issue17660.png + .. versionchanged:: 3.5 + If you are patching builtins in a module then you don't + need to pass `create=True`, it will be added by default. ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 20:54:18 2014 From: report at bugs.python.org (Eric Olson) Date: Tue, 15 Apr 2014 18:54:18 +0000 Subject: [issue2159] dbmmodule inquiry function is performance prohibitive In-Reply-To: <1203640875.82.0.736964888757.issue2159@psf.upfronthosting.co.za> Message-ID: <1397588058.01.0.429062473761.issue2159@psf.upfronthosting.co.za> Eric Olson added the comment: Uploading patch with minor test changes (dbm_bool_b.patch). Backwards compatibility note: Result of running bool(db) on a db that has been closed: Old: _dbm.error: DBM object has already been closed With patch: returns False instead of raising. I think this is desireable, but we could have bool(db) raise an exception when the db is closed if that is preferred for backwards compatibility. ---------- Added file: http://bugs.python.org/file34886/dbm_bool_b.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 20:58:26 2014 From: report at bugs.python.org (Christian Theune) Date: Tue, 15 Apr 2014 18:58:26 +0000 Subject: [issue18099] wsgiref sets Content-Length: 0 on 304 Not Modified In-Reply-To: <1369910008.93.0.397797975418.issue18099@psf.upfronthosting.co.za> Message-ID: <1397588306.34.0.211363764701.issue18099@psf.upfronthosting.co.za> Changes by Christian Theune : ---------- hgrepos: +235 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 20:58:47 2014 From: report at bugs.python.org (Christian Theune) Date: Tue, 15 Apr 2014 18:58:47 +0000 Subject: [issue18099] wsgiref sets Content-Length: 0 on 304 Not Modified In-Reply-To: <1369910008.93.0.397797975418.issue18099@psf.upfronthosting.co.za> Message-ID: <1397588327.91.0.0177335070486.issue18099@psf.upfronthosting.co.za> Changes by Christian Theune : ---------- hgrepos: +236 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 21:00:16 2014 From: report at bugs.python.org (Jurjen N.E. Bos) Date: Tue, 15 Apr 2014 19:00:16 +0000 Subject: [issue21234] __contains__ and friends should check "is" for all elements first In-Reply-To: <1397567063.59.0.649029276797.issue21234@psf.upfronthosting.co.za> Message-ID: <1397588416.17.0.767327455525.issue21234@psf.upfronthosting.co.za> Jurjen N.E. Bos added the comment: Well, I partially agree. I see the following points: Against my proposal: - For *very* big containers, it can be slower in the case the object is early in the container, as you pointed out. - Current behaviour is easier to understand. OTOH, fore the proposal: - Such giant containers are not efficient anyway; that's were set/Counter can help. - The documentation doesn't promise anywhere the objects are scanned in order. Anyway, if this is supposed to be the behaviour, I suggest to document it, and add the following recipe for people dealing with the same problem as I had: from operator import ne from itertools import repeat class MyContainer: """container allowing equality search with containsEqual, while allowing fast identity search with __contains__: use "obj in c" to test if obj exactly sits in c use "c.containsEqual(obj)" to test if an object in c has c==obj """ def containsEqual(self, object): return not all(map(ne, zip(repeat(object), self))) def __ne__(self, object): "Your not-equal test" If you see a more elegant equivalent recipe, feel free to add. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 21:01:55 2014 From: report at bugs.python.org (Christian Theune) Date: Tue, 15 Apr 2014 19:01:55 +0000 Subject: [issue18099] wsgiref sets Content-Length: 0 on 304 Not Modified In-Reply-To: <1369910008.93.0.397797975418.issue18099@psf.upfronthosting.co.za> Message-ID: <1397588515.58.0.815933815419.issue18099@psf.upfronthosting.co.za> Changes by Christian Theune : ---------- keywords: +patch Added file: http://bugs.python.org/file34887/125e080bbe15.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 21:02:30 2014 From: report at bugs.python.org (Christian Theune) Date: Tue, 15 Apr 2014 19:02:30 +0000 Subject: [issue18099] wsgiref sets Content-Length: 0 on 304 Not Modified In-Reply-To: <1369910008.93.0.397797975418.issue18099@psf.upfronthosting.co.za> Message-ID: <1397588550.54.0.271546895717.issue18099@psf.upfronthosting.co.za> Changes by Christian Theune : Added file: http://bugs.python.org/file34888/762d11a72249.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 21:06:06 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 15 Apr 2014 19:06:06 +0000 Subject: [issue18099] wsgiref sets Content-Length: 0 on 304 Not Modified In-Reply-To: <1369910008.93.0.397797975418.issue18099@psf.upfronthosting.co.za> Message-ID: <1397588766.36.0.638772533428.issue18099@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 21:06:34 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 15 Apr 2014 19:06:34 +0000 Subject: [issue18099] wsgiref sets Content-Length: 0 on 304 Not Modified In-Reply-To: <1369910008.93.0.397797975418.issue18099@psf.upfronthosting.co.za> Message-ID: <1397588794.6.0.221770107741.issue18099@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 21:16:26 2014 From: report at bugs.python.org (Kent Frazier) Date: Tue, 15 Apr 2014 19:16:26 +0000 Subject: [issue21244] distutils fails to build C extensions with XCode 5.1 and OS X 10.9 (Mavericks) Message-ID: <1397589386.91.0.235020854992.issue21244@psf.upfronthosting.co.za> New submission from Kent Frazier: Using the stock Python shipped by Apple with OS X 10.9 Mavericks and XCode 5.1, Mercurial (and other Python extensions) encounter an error like: cc -fno-strict-aliasing -fno-common -dynamic -g -Os -pipe -fno-common -fno-strict-aliasing -fwrapv -mno-fused-madd -DENABLE_DTRACE -DMACOSX -DNDEBUG -Wall -Wstrict-prototypes -Wshorten-64-to-32 -DNDEBUG -g -fwrapv -Os -Wall -Wstrict-prototypes -DENABLE_DTRACE -pipe -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -c mercurial/base85.c -o /private/var/folders/qv/tv81r5_9119bs3jwj3g2rp540000gn/T/hgtests._a6HZj/build/temp.macosx-10.9-intel-2.7/mercurial/base85.o clang: error: unknown argument: '-mno-fused-madd' [-Wunused-command-line-argument-hard-error-in-future] clang: note: this will be a hard error (cannot be downgraded to a warning) in the future error: command 'cc' failed with exit status 1 make: *** [tests] Error 1 This can be worked around with: export CFLAGS=-Qunused-arguments On my machine, Python was build with clang-500.0.68 and the XCode 5.1 updates it to clang-503.0.40. I will include a simple setup.py that can be run against Mercurial's head to demonstrate the issue. ---------- components: Distutils files: toysetup.py messages: 216363 nosy: dstufft, eric.araujo, jason.coombs, kfrazier priority: normal severity: normal status: open title: distutils fails to build C extensions with XCode 5.1 and OS X 10.9 (Mavericks) type: compile error versions: Python 2.7 Added file: http://bugs.python.org/file34889/toysetup.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 21:26:09 2014 From: report at bugs.python.org (Michael Foord) Date: Tue, 15 Apr 2014 19:26:09 +0000 Subject: [issue17660] mock.patch could whitelist builtins to not need create=True In-Reply-To: <1365418089.99.0.0976801798706.issue17660@psf.upfronthosting.co.za> Message-ID: <1397589969.26.0.745978960704.issue17660@psf.upfronthosting.co.za> Michael Foord added the comment: Personally I don't think it looks ugly and that it is a point worth calling out. Other opinions welcomed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 21:26:56 2014 From: report at bugs.python.org (ddvento@ucar.edu) Date: Tue, 15 Apr 2014 19:26:56 +0000 Subject: [issue20939] test_geturl of test_urllibnet fails with 'https://www.python.org/' != 'http://www.python.org/' In-Reply-To: <1394912477.16.0.0678033428019.issue20939@psf.upfronthosting.co.za> Message-ID: <1397590016.5.0.768158037744.issue20939@psf.upfronthosting.co.za> Changes by ddvento at ucar.edu : ---------- nosy: +ddvento at ucar.edu _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 21:28:02 2014 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Tue, 15 Apr 2014 19:28:02 +0000 Subject: [issue20438] inspect: Deprecate getfullargspec? In-Reply-To: <1391014813.06.0.594760406572.issue20438@psf.upfronthosting.co.za> Message-ID: <1397590082.58.0.224220180689.issue20438@psf.upfronthosting.co.za> St?phane Wirtel added the comment: Need your feedback for this patch Thank you ---------- Added file: http://bugs.python.org/file34890/issue20438_deprecate_inspect_getfullargspec-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 21:28:37 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 15 Apr 2014 19:28:37 +0000 Subject: [issue17660] mock.patch could whitelist builtins to not need create=True In-Reply-To: <1365418089.99.0.0976801798706.issue17660@psf.upfronthosting.co.za> Message-ID: <1397590117.53.0.362907845602.issue17660@psf.upfronthosting.co.za> ?ric Araujo added the comment: I noticed this in the commit; I don?t think the rendered output is really ugly, but the markup does look strange, as it?s two nested note(-like) directives. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 21:28:42 2014 From: report at bugs.python.org (Michael Foord) Date: Tue, 15 Apr 2014 19:28:42 +0000 Subject: [issue21222] Mock create_autospec with name argument fails In-Reply-To: <1397505251.05.0.288307474202.issue21222@psf.upfronthosting.co.za> Message-ID: <1397590122.74.0.0876374446815.issue21222@psf.upfronthosting.co.za> Michael Foord added the comment: Looks good to me, but please change qobj and add a NEWS entry. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 21:31:11 2014 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Tue, 15 Apr 2014 19:31:11 +0000 Subject: [issue12916] Add inspect.splitdoc In-Reply-To: <1315326747.38.0.43030903994.issue12916@psf.upfronthosting.co.za> Message-ID: <1397590271.01.0.0306279593333.issue12916@psf.upfronthosting.co.za> St?phane Wirtel added the comment: Yury, what's your feedback about this point? Thanks ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 21:32:10 2014 From: report at bugs.python.org (ddvento@ucar.edu) Date: Tue, 15 Apr 2014 19:32:10 +0000 Subject: [issue17160] test_urllib2net fails In-Reply-To: <1360341954.01.0.966595141063.issue17160@psf.upfronthosting.co.za> Message-ID: <1397590330.9.0.223479691434.issue17160@psf.upfronthosting.co.za> ddvento at ucar.edu added the comment: Reopening, since this is still broken in Python 2.7.6 I wonder why do we have to use real websites instead of mocks for this test. And if there are really really really really good reasons, if we can use example.com instead as in issue #20939 (maybe that is more stable than python.org) ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 21:38:31 2014 From: report at bugs.python.org (Caelyn McAulay) Date: Tue, 15 Apr 2014 19:38:31 +0000 Subject: [issue7850] platform.system() should be "macosx" instead of "Darwin" on OSX In-Reply-To: <1265236812.59.0.190434450591.issue7850@psf.upfronthosting.co.za> Message-ID: <1397590711.7.0.78150194.issue7850@psf.upfronthosting.co.za> Caelyn McAulay added the comment: Added aliased option to platform.system(). I used the same system_alias method as platform.platform(), so the result of the aliased version will match the system entry of the aliased platform.platform(). Added to platform.system unit test to test new functionality. Updated Documentation. I am not sure if there is anywhere else I need to update the documentation to add this, i.e. if it needs a whatsnews entry (and if so, a pointer to docs on how to add to a whatsnews entry would be appreciated). ---------- keywords: +patch nosy: +math_foo Added file: http://bugs.python.org/file34891/aliased_system7850.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 21:53:09 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 15 Apr 2014 19:53:09 +0000 Subject: [issue21222] Mock create_autospec with name argument fails In-Reply-To: <1397505251.05.0.288307474202.issue21222@psf.upfronthosting.co.za> Message-ID: <3g7cnJ4dLXzSRT@mail.python.org> Roundup Robot added the comment: New changeset d471b0d38516 by Kushal Das in branch '3.4': Closes Issue 21222. http://hg.python.org/cpython/rev/d471b0d38516 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 21:53:22 2014 From: report at bugs.python.org (Sam Kimbrel) Date: Tue, 15 Apr 2014 19:53:22 +0000 Subject: [issue18401] Tests for pdb import ~/.pdbrc In-Reply-To: <1373261746.39.0.598108958249.issue18401@psf.upfronthosting.co.za> Message-ID: <1397591602.67.0.722381028754.issue18401@psf.upfronthosting.co.za> Sam Kimbrel added the comment: Picked up Martin's patch and added docs, misc/NEWS entry, and a test for readrc=False behavior. ---------- nosy: +sam.kimbrel Added file: http://bugs.python.org/file34892/18401-pdb-readrc-kwarg-with-docs-and-tests.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 21:54:47 2014 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Tue, 15 Apr 2014 19:54:47 +0000 Subject: [issue5420] Queue deprecation warning patch In-Reply-To: <1236218557.32.0.700265695834.issue5420@psf.upfronthosting.co.za> Message-ID: <1397591687.43.0.650932641308.issue5420@psf.upfronthosting.co.za> St?phane Wirtel added the comment: No news for 2 years. ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 21:59:54 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Tue, 15 Apr 2014 19:59:54 +0000 Subject: [issue21225] io.py: Improve docstrings for classes In-Reply-To: <1397508646.21.0.210626779275.issue21225@psf.upfronthosting.co.za> Message-ID: <1397591994.26.0.129764773916.issue21225@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- components: +IO versions: +Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 22:09:25 2014 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 15 Apr 2014 20:09:25 +0000 Subject: [issue12916] Add inspect.splitdoc In-Reply-To: <1315326747.38.0.43030903994.issue12916@psf.upfronthosting.co.za> Message-ID: <1397592565.09.0.10107850638.issue12916@psf.upfronthosting.co.za> Yury Selivanov added the comment: David: > The precedent has already been set by the 'cleandoc' function, I think. This one seems to go right along with that one. What do you think if we keep the function in pydoc module, but document it and make it public? I agree, that there is a precedent of having non-introspection APIs in inspect, but I'd still like to keep it minimal. Having this function in pydoc also makes sense, as it's more about python docstring convention, than introspection (cleandoc() is used by getdoc(), which is why it is in inspect after all) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 22:12:01 2014 From: report at bugs.python.org (Michael Foord) Date: Tue, 15 Apr 2014 20:12:01 +0000 Subject: [issue18566] In unittest.TestCase docs for setUp() and tearDown() don't mention AssertionError In-Reply-To: <1374901937.1.0.747872580847.issue18566@psf.upfronthosting.co.za> Message-ID: <1397592721.88.0.371837820514.issue18566@psf.upfronthosting.co.za> Michael Foord added the comment: Patch looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 22:12:07 2014 From: report at bugs.python.org (Glenn Jones) Date: Tue, 15 Apr 2014 20:12:07 +0000 Subject: [issue15795] Zipfile.extractall does not preserve file permissions In-Reply-To: <1346106964.12.0.723201722432.issue15795@psf.upfronthosting.co.za> Message-ID: <1397592727.72.0.405122053403.issue15795@psf.upfronthosting.co.za> Glenn Jones added the comment: Patch with docs and tests fixed ---------- Added file: http://bugs.python.org/file34893/issue15795_test_and_doc_fixes.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 22:15:49 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 15 Apr 2014 20:15:49 +0000 Subject: [issue21199] Python on 64-bit Windows uses signed 32-bit type for read length In-Reply-To: <1397149133.44.0.946556558932.issue21199@psf.upfronthosting.co.za> Message-ID: <1397592949.32.0.10130835763.issue21199@psf.upfronthosting.co.za> Larry Hastings added the comment: I don't think we can fix this. file_read returns a str, and str can have at most SSIZE_T_MAX entries. So, file_read could read size_t characters, but it couldn't return them. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 22:16:02 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 15 Apr 2014 20:16:02 +0000 Subject: [issue15840] Ambiguity with regard to the effect of accessing a closed IOBase instance In-Reply-To: <1346524424.76.0.407141547435.issue15840@psf.upfronthosting.co.za> Message-ID: <3g7dHk0t9qz7Ljd@mail.python.org> Roundup Robot added the comment: New changeset 0c7cf0e598e7 by Andrew Kuchling in branch '2.7': #15840: make docs consistent by saying operations on closed files raise ValueError. http://hg.python.org/cpython/rev/0c7cf0e598e7 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 22:19:59 2014 From: report at bugs.python.org (Cameron Lee) Date: Tue, 15 Apr 2014 20:19:59 +0000 Subject: [issue21245] Logging Logger.exception documentation Message-ID: <1397593199.67.0.956489214078.issue21245@psf.upfronthosting.co.za> New submission from Cameron Lee: The documentation doesn't indicate that the Logger.exception method can accept kwargs like the other logging methods (Logger.debug, Logger.info, etc...) such as exc_info, stack_info, and extra. https://docs.python.org/2.7/library/logging.html#logging.Logger.exception The method signature is documented as: Logger.exception(msg, *args) It should be: Logger.exception(msg, *args, **kwargs) It appears that this functionality was added in between Python 2.7.3 and 2.7.4 (http://bugs.python.org/issue15541) but that the documentation was never changed for the newer versions. ---------- assignee: docs at python components: Documentation messages: 216379 nosy: Cameron.Lee, docs at python priority: normal severity: normal status: open title: Logging Logger.exception documentation versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 22:20:36 2014 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 15 Apr 2014 20:20:36 +0000 Subject: [issue21245] Logging Logger.exception documentation In-Reply-To: <1397593199.67.0.956489214078.issue21245@psf.upfronthosting.co.za> Message-ID: <1397593236.46.0.168400933024.issue21245@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +vinay.sajip, yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 22:22:28 2014 From: report at bugs.python.org (ddvento@ucar.edu) Date: Tue, 15 Apr 2014 20:22:28 +0000 Subject: [issue21246] test_ssl handshake failure Message-ID: <1397593348.91.0.829573885546.issue21246@psf.upfronthosting.co.za> New submission from ddvento at ucar.edu: Not sure if this is related with issue #13626 which is the only thing that Google knows about these handshake failures. In case it matters: $ openssl version OpenSSL 1.0.1f 6 Jan 2014 == CPython 2.7.6 (default, Apr 14 2014, 15:12:21) [GCC 4.8.2] == Linux-2.6.32-358.el6.x86_64-x86_64-with-redhat-6.4-Santiago little-endian == /glade/scratch/ddvento/build/Python-2.7.6/build/test_python_18521 Testing with flags: sys.flags(debug=0, py3k_warning=0, division_warning=0, division_new=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, tabcheck=0, verbose=0, unicode=0, bytes_warning=0, hash_randomization=0) test_ssl test_sslwrap_simple (test.test_ssl.BasicTests) ... ok test_DER_to_PEM (test.test_ssl.BasicSocketTests) ... ok test_ciphers (test.test_ssl.BasicSocketTests) ... ok test_constants (test.test_ssl.BasicSocketTests) ... ok test_openssl_version (test.test_ssl.BasicSocketTests) ... ok test_parse_cert (test.test_ssl.BasicSocketTests) ... {'notAfter': 'Oct 5 23:01:56 2020 GMT', 'subject': ((('countryName', u'XY'),), (('localityName', u'Castle Anthrax'),), (('organizationName', u'Python Software Foundation'),), (('commonName', u'localhost'),)), 'subjectAltName': (('DNS', 'localhost'),)} {'issuer': ((('countryName', u'US'),), (('organizationName', u'VeriSign, Inc.'),), (('organizationalUnitName', u'VeriSign Trust Network'),), (('organizationalUnitName', u'Terms of use at https://www.verisign.com/rpa (c)10'),), (('commonName', u'VeriSign Class 3 International Server CA - G3'),)), 'notAfter': 'Sep 20 23:59:59 2012 GMT', 'notBefore': 'Sep 21 00:00:00 2011 GMT', 'serialNumber': '2EE6EA7640A075CEE5005F4D7C79549A', 'subject': ((('countryName', u'FI'),), (('stateOrProvinceName', u'Espoo'),), (('localityName', u'Espoo'),), (('organizationName', u'Nokia'),), (('organizationalUnitName', u'BI'),), (('commonName', u'projects.developer.nokia.com'),)), 'subjectAltName': (('DNS', 'projects.developer.nokia.com'), ('DNS', 'projects.forum.nokia.com')), 'version': 3} ok test_parse_cert_CVE_2013_4238 (test.test_ssl.BasicSocketTests) ... {'issuer': ((('countryName', u'US'),), (('stateOrProvinceName', u'Oregon'),), (('localityName', u'Beaverton'),), (('organizationName', u'Python Software Foundation'),), (('organizationalUnitName', u'Python Core Development'),), (('commonName', u'null.python.org\x00example.org'),), (('emailAddress', u'python-dev at python.org'),)), 'notAfter': 'Aug 7 13:12:52 2013 GMT', 'notBefore': 'Aug 7 13:11:52 2013 GMT', 'serialNumber': '00', 'subject': ((('countryName', u'US'),), (('stateOrProvinceName', u'Oregon'),), (('localityName', u'Beaverton'),), (('organizationName', u'Python Software Foundation'),), (('organizationalUnitName', u'Python Core Development'),), (('commonName', u'null.python.org\x00example.org'),), (('emailAddress', u'python-dev at python.org'),)), 'subjectAltName': (('DNS', 'altnull.python.org\x00example.com'), ('email', 'null at python.org\x00user at example.org'), ('URI', 'http://null.python.org\x00http://example.org'), ('IP Address', '192.0.2.1'), ('IP Address', '2001:DB8:0:0:0:0:0:1\n')), 'version': 3} ok test_random (test.test_ssl.BasicSocketTests) ... RAND_status is 1 (sufficient randomness) ok test_refcycle (test.test_ssl.BasicSocketTests) ... ok test_wrapped_unconnected (test.test_ssl.BasicSocketTests) ... ok test_algorithms (test.test_ssl.NetworkedTests) ... skipped 'remote host needs SNI, only available on Python 3.2+' test_connect (test.test_ssl.NetworkedTests) ... ok test_connect_ex (test.test_ssl.NetworkedTests) ... ok test_connect_ex_error (test.test_ssl.NetworkedTests) ... ok test_get_server_certificate (test.test_ssl.NetworkedTests) ... ERROR test_makefile_close (test.test_ssl.NetworkedTests) ... ok test_non_blocking_connect_ex (test.test_ssl.NetworkedTests) ... ok test_non_blocking_handshake (test.test_ssl.NetworkedTests) ... Needed 3 calls to do_handshake() to establish session. ok test_timeout_connect_ex (test.test_ssl.NetworkedTests) ... ok test_asyncore_server (test.test_ssl.ThreadedTests) Check the example asyncore integration. ... server: new connection from 127.0.0.1:48912 client: sending 'TEST MESSAGE of mixed case\n'... client: read 'test message of mixed case\n' client: closing connection. cleanup: stopping server. cleanup: joining server thread. server: closed connection cleanup: successfully joined. ok test_default_ciphers (test.test_ssl.ThreadedTests) ... ok test_echo (test.test_ssl.ThreadedTests) Basic test of an SSL client connecting to a server ... server: new connection from ('127.0.0.1', 43993) server: connection cipher is now ('AES256-SHA', 'TLSv1/SSLv3', 256) client: sending 'FOO\n'... server: read 'FOO\n' (encrypted), sending back 'foo\n' (encrypted)... client: read 'foo\n' client: sending bytearray(b'FOO\n')... server: read 'FOO\n' (encrypted), sending back 'foo\n' (encrypted)... client: read 'foo\n' client: sending ... server: read 'FOO\n' (encrypted), sending back 'foo\n' (encrypted)... client: read 'foo\n' client: closing connection. server: client closed connection ok test_empty_cert (test.test_ssl.ThreadedTests) Connecting with an empty cert file ... SSLError is _ssl.c:354: error:140B0009:SSL routines:SSL_CTX_use_PrivateKey_file:PEM lib ok test_getpeercert (test.test_ssl.ThreadedTests) ... {'notAfter': 'Oct 5 23:01:56 2020 GMT', 'subject': ((('countryName', u'XY'),), (('localityName', u'Castle Anthrax'),), (('organizationName', u'Python Software Foundation'),), (('commonName', u'localhost'),)), 'subjectAltName': (('DNS', 'localhost'),)} Connection cipher is ('AES256-GCM-SHA384', 'TLSv1/SSLv3', 256). ok test_handshake_timeout (test.test_ssl.ThreadedTests) ... ok test_malformed_cert (test.test_ssl.ThreadedTests) Connecting with a badly formatted certificate (syntax error) ... SSLError is _ssl.c:368: error:140DC009:SSL routines:SSL_CTX_use_certificate_chain_file:PEM lib ok test_malformed_key (test.test_ssl.ThreadedTests) Connecting with a badly formatted key (syntax error) ... SSLError is _ssl.c:354: error:140B0009:SSL routines:SSL_CTX_use_PrivateKey_file:PEM lib ok test_nonexisting_cert (test.test_ssl.ThreadedTests) Connecting with a non-existing cert file ... SSLError is _ssl.c:507: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca ok test_protocol_sslv2 (test.test_ssl.ThreadedTests) Connecting to an SSLv2 server with various client options ... SSLv2->SSLv2 CERT_NONE SSLv2->SSLv2 CERT_OPTIONAL SSLv2->SSLv2 CERT_REQUIRED SSLv23->SSLv2 CERT_NONE {SSLv3->SSLv2} CERT_NONE {TLSv1->SSLv2} CERT_NONE ok test_protocol_sslv23 (test.test_ssl.ThreadedTests) Connecting to an SSLv23 server with various client options ... SSLv3->SSLv23 CERT_NONE SSLv23->SSLv23 CERT_NONE TLSv1->SSLv23 CERT_NONE SSLv3->SSLv23 CERT_OPTIONAL SSLv23->SSLv23 CERT_OPTIONAL TLSv1->SSLv23 CERT_OPTIONAL SSLv3->SSLv23 CERT_REQUIRED SSLv23->SSLv23 CERT_REQUIRED TLSv1->SSLv23 CERT_REQUIRED ok test_protocol_sslv3 (test.test_ssl.ThreadedTests) Connecting to an SSLv3 server with various client options ... SSLv3->SSLv3 CERT_NONE SSLv3->SSLv3 CERT_OPTIONAL SSLv3->SSLv3 CERT_REQUIRED {SSLv2->SSLv3} CERT_NONE {TLSv1->SSLv3} CERT_NONE ok test_protocol_tlsv1 (test.test_ssl.ThreadedTests) Connecting to a TLSv1 server with various client options ... TLSv1->TLSv1 CERT_NONE TLSv1->TLSv1 CERT_OPTIONAL TLSv1->TLSv1 CERT_REQUIRED {SSLv2->TLSv1} CERT_NONE {SSLv3->TLSv1} CERT_NONE ok test_recv_send (test.test_ssl.ThreadedTests) Test recv(), send() and friends. ... server: new connection from ('127.0.0.1', 56710) server: connection cipher is now ('AES256-SHA', 'TLSv1/SSLv3', 256) ok test_rude_shutdown (test.test_ssl.ThreadedTests) A brutal shutdown of an SSL server should raise an IOError ... ok test_socketserver (test.test_ssl.ThreadedTests) Using a SocketServer to create and manage SSL connections. ... server (('127.0.0.1', 42188):42188 ('AES256-GCM-SHA384', 'TLSv1/SSLv3', 256)): [15/Apr/2014 14:14:53] "GET /keycert.pem HTTP/1.0" 200 - client: read 1783 bytes from remote server '>' ok test_starttls (test.test_ssl.ThreadedTests) Switching from clear text to encrypted and back again. ... client: sending 'msg 1'... server: new connection from ('127.0.0.1', 50624) server: read 'msg 1' (unencrypted), sending back 'msg 1' (unencrypted)... client: read 'msg 1' from server client: sending 'MSG 2'... server: read 'MSG 2' (unencrypted), sending back 'msg 2' (unencrypted)... client: read 'msg 2' from server client: sending 'STARTTLS'... server: read STARTTLS from client, sending OK... client: read 'OK\n' from server, starting TLS... client: sending 'MSG 3'... server: read 'MSG 3' (encrypted), sending back 'msg 3' (encrypted)... client: read 'msg 3' from server client: sending 'msg 4'... server: read 'msg 4' (encrypted), sending back 'msg 4' (encrypted)... client: read 'msg 4' from server client: sending 'ENDTLS'... server: read ENDTLS from client, sending OK... client: read 'OK\n' from server, ending TLS... server: connection is now unencrypted... client: sending 'msg 5'... server: read 'msg 5' (unencrypted), sending back 'msg 5' (unencrypted)... client: read 'msg 5' from server client: sending 'msg 6'... server: read 'msg 6' (unencrypted), sending back 'msg 6' (unencrypted)... client: read 'msg 6' from server client: closing connection. server: client closed connection ok test_wrapped_accept (test.test_ssl.ThreadedTests) Check the accept() method on SSL sockets. ... test test_ssl failed -- Traceback (most recent call last): File "/glade/scratch/ddvento/build/Python-2.7.6/Lib/test/test_ssl.py", line 387, in test_get_server_certificate pem = ssl.get_server_certificate(("svn.python.org", 443)) File "/glade/scratch/ddvento/build/Python-2.7.6/Lib/ssl.py", line 448, in get_server_certificate s.connect(addr) File "/glade/scratch/ddvento/build/Python-2.7.6/Lib/ssl.py", line 333, in connect self._real_connect(addr, False) File "/glade/scratch/ddvento/build/Python-2.7.6/Lib/ssl.py", line 323, in _real_connect self.do_handshake() File "/glade/scratch/ddvento/build/Python-2.7.6/Lib/ssl.py", line 305, in do_handshake self._sslobj.do_handshake() SSLError: [Errno 1] _ssl.c:507: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure server: wrapped server socket as client: sending 'FOO\n'... server: new connection from ('127.0.0.1', 40291) client cert is {'notAfter': 'Oct 5 23:01:56 2020 GMT', 'subject': ((('countryName', u'XY'),), (('localityName', u'Castle Anthrax'),), (('organizationName', u'Python Software Foundation'),), (('commonName', u'localhost'),)), 'subjectAltName': (('DNS', 'localhost'),)} cert binary is 600 bytes server: connection cipher is now ('AES256-GCM-SHA384', 'TLSv1/SSLv3', 256) server: read 'FOO\n' (encrypted), sending back 'foo\n' (encrypted)... client: read 'foo\n' client: sending bytearray(b'FOO\n')... server: read 'FOO\n' (encrypted), sending back 'foo\n' (encrypted)... client: read 'foo\n' client: sending ... server: read 'FOO\n' (encrypted), sending back 'foo\n' (encrypted)... client: read 'foo\n' client: closing connection. server: client closed connection ok ====================================================================== ERROR: test_get_server_certificate (test.test_ssl.NetworkedTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/glade/scratch/ddvento/build/Python-2.7.6/Lib/test/test_ssl.py", line 387, in test_get_server_certificate pem = ssl.get_server_certificate(("svn.python.org", 443)) File "/glade/scratch/ddvento/build/Python-2.7.6/Lib/ssl.py", line 448, in get_server_certificate s.connect(addr) File "/glade/scratch/ddvento/build/Python-2.7.6/Lib/ssl.py", line 333, in connect self._real_connect(addr, False) File "/glade/scratch/ddvento/build/Python-2.7.6/Lib/ssl.py", line 323, in _real_connect self.do_handshake() File "/glade/scratch/ddvento/build/Python-2.7.6/Lib/ssl.py", line 305, in do_handshake self._sslobj.do_handshake() SSLError: [Errno 1] _ssl.c:507: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure ---------------------------------------------------------------------- Ran 37 tests in 4.950s FAILED (errors=1, skipped=1) 1 test failed: test_ssl ---------- messages: 216380 nosy: ddvento at ucar.edu priority: normal severity: normal status: open title: test_ssl handshake failure versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 22:32:03 2014 From: report at bugs.python.org (James Emerton) Date: Tue, 15 Apr 2014 20:32:03 +0000 Subject: [issue1677872] Efficient reverse line iterator Message-ID: <1397593923.05.0.0618311067785.issue1677872@psf.upfronthosting.co.za> James Emerton added the comment: Attached is an implementation of BufferedReader.readprevline(), as suggested by Antoine. At this point, it seems to be working but I would like to improve the tests when a single result spans multiple chunks. I would particularly like to ensure correct behaviour when a newline ends up as the last byte of a new chunk. ---------- nosy: +jemerton Added file: http://bugs.python.org/file34894/readprevline-20140415.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 22:34:27 2014 From: report at bugs.python.org (Eric Olson) Date: Tue, 15 Apr 2014 20:34:27 +0000 Subject: [issue2159] dbmmodule inquiry function is performance prohibitive In-Reply-To: <1203640875.82.0.736964888757.issue2159@psf.upfronthosting.co.za> Message-ID: <1397594067.94.0.373755804378.issue2159@psf.upfronthosting.co.za> Eric Olson added the comment: Make the changes backward compatible after getting input on possible problems from r.david.murray patch: dbm_bool_c.patch Now, the only change should be faster performance for bool(db). ---------- versions: +Python 3.5 Added file: http://bugs.python.org/file34895/dbm_bool_c.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 22:44:51 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 15 Apr 2014 20:44:51 +0000 Subject: [issue1704474] optparse tests fail under Jython Message-ID: <3g7dwy4hlLz7LjS@mail.python.org> Roundup Robot added the comment: New changeset a1ef419c0cfb by Andrew Kuchling in branch '2.7': #1704474: mark refleak test as specific to CPython http://hg.python.org/cpython/rev/a1ef419c0cfb ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 22:53:06 2014 From: report at bugs.python.org (Sam Kimbrel) Date: Tue, 15 Apr 2014 20:53:06 +0000 Subject: [issue6490] os.popen documentation is probably wrong In-Reply-To: <1247646939.28.0.091306950041.issue6490@psf.upfronthosting.co.za> Message-ID: <1397595186.8.0.810305165255.issue6490@psf.upfronthosting.co.za> Sam Kimbrel added the comment: Updated the patch as per Martin's notes in msg203483. ---------- nosy: +sam.kimbrel Added file: http://bugs.python.org/file34896/6490-os-popen-docs.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 23:04:38 2014 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 15 Apr 2014 21:04:38 +0000 Subject: [issue20438] inspect: Deprecate getfullargspec? In-Reply-To: <1391014813.06.0.594760406572.issue20438@psf.upfronthosting.co.za> Message-ID: <1397595878.66.0.38410059651.issue20438@psf.upfronthosting.co.za> Nick Coghlan added the comment: Note that getargspec() depends on getfullargspec() so deprecating the latter *will* cause issues for single-source code (unless they switch to using the funcsigs backport). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 23:17:15 2014 From: report at bugs.python.org (Vinay Sajip) Date: Tue, 15 Apr 2014 21:17:15 +0000 Subject: [issue21245] Logging Logger.exception documentation In-Reply-To: <1397593199.67.0.956489214078.issue21245@psf.upfronthosting.co.za> Message-ID: <1397596635.38.0.81457537323.issue21245@psf.upfronthosting.co.za> Vinay Sajip added the comment: Removed Python versions which are not receiving changes. ---------- versions: -Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 23:21:00 2014 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 15 Apr 2014 21:21:00 +0000 Subject: [issue20438] inspect: Deprecate getfullargspec? In-Reply-To: <1391014813.06.0.594760406572.issue20438@psf.upfronthosting.co.za> Message-ID: <1397596860.02.0.532073542025.issue20438@psf.upfronthosting.co.za> Yury Selivanov added the comment: Nick, good catch. OK, let's just deprecate it in the docs for 3.5, so people (hopefully) will not write new code with it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 23:22:29 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 15 Apr 2014 21:22:29 +0000 Subject: [issue21239] unittest.mock.patch.stopall intermittently doesn't work when the same thing is patched multiple times In-Reply-To: <1397577271.48.0.402954348215.issue21239@psf.upfronthosting.co.za> Message-ID: <3g7fmN6Mjkz7Ljf@mail.python.org> Roundup Robot added the comment: New changeset 727b7e9c40e3 by Michael Foord in branch '3.4': Closes issue 21239. unittest.mock.patch.stopall() did not work deterministically when the same name was patched multiple times. http://hg.python.org/cpython/rev/727b7e9c40e3 ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 23:24:04 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 15 Apr 2014 21:24:04 +0000 Subject: [issue21199] Python on 64-bit Windows uses signed 32-bit type for read length In-Reply-To: <1397592949.32.0.10130835763.issue21199@psf.upfronthosting.co.za> Message-ID: <534DA371.5060701@free.fr> Antoine Pitrou added the comment: > I don't think we can fix this. file_read returns a str, and str can have at most SSIZE_T_MAX entries. So, file_read could read size_t characters, but it couldn't return them. But at least it could read more than LONG_MAX characters. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 23:27:57 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 15 Apr 2014 21:27:57 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1397597277.23.0.418201624987.issue21233@psf.upfronthosting.co.za> STINNER Victor added the comment: Here is a first patch adding the following functions: void* PyMem_RawCalloc(size_t n); void* PyMem_Calloc(size_t n); void* PyObject_Calloc(size_t n); PyObject* _PyObject_GC_Calloc(size_t); It adds the following field after malloc field to PyMemAllocator structure: void* (*calloc) (void *ctx, size_t size); It changes the tracemalloc module to trace "calloc" allocations, add new tests and document new functions. The patch also contains an important change: PyType_GenericAlloc() uses calloc instead of malloc+memset(0). It may be faster, I didn't check. ---------- keywords: +patch Added file: http://bugs.python.org/file34897/calloc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 23:28:08 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 15 Apr 2014 21:28:08 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1397597288.06.0.800715347932.issue21233@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +neologix, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 23:29:53 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 15 Apr 2014 21:29:53 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1397597393.68.0.345269997263.issue16991@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 23:30:03 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Tue, 15 Apr 2014 21:30:03 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1397597403.43.0.11167967685.issue21233@psf.upfronthosting.co.za> Changes by Josh Rosenberg : ---------- nosy: +josh.rosenberg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 23:32:39 2014 From: report at bugs.python.org (Jeff Ramnani) Date: Tue, 15 Apr 2014 21:32:39 +0000 Subject: [issue21060] Better error message for setup.py upload command without sdist In-Reply-To: <1395737197.75.0.193444855893.issue21060@psf.upfronthosting.co.za> Message-ID: <1397597559.05.0.54823618417.issue21060@psf.upfronthosting.co.za> Jeff Ramnani added the comment: Attaching a patch with a (hopefully) more useful error message. I didn't find a good place to add this information in the "Distributing Python Modules" section of the docs, but let me know if you had a place in mind. ---------- keywords: +patch nosy: +jramnani Added file: http://bugs.python.org/file34898/issue21060-py35.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 23:33:53 2014 From: report at bugs.python.org (Orion Poplawski) Date: Tue, 15 Apr 2014 21:33:53 +0000 Subject: [issue21247] test_asyncio: test_subprocess_send_signal hangs on Fedora builders Message-ID: <1397597632.61.0.772376521638.issue21247@psf.upfronthosting.co.za> New submission from Orion Poplawski: Trying to build Python 3.4.0 for Fedora we are seeing test_asyncio test_subprocess_send_signal hang every time, on all architectures. Unfortunately I cannot reproduce this locally. These builds are done inside of chroots, and the host has the kernel version 3.12.8-300.fc20 which is used for all build targets. We see hangs building for Fedora Rawhide and RHEL 7. We do *not* see hangs on our COPR builders which among other possible differences use RHEL6 hosts with kernel 2.6.32-358.el6. I've attached an strace of the hanging test. The calling process seems to be stuck in epoll_wait(). Tried using the watchdog patch from issue #19652 but that doesn't seem to manage to kill things. In fact, the tests are never killed but the 1 hour timeout in the test runner. ---------- files: test_signal.out messages: 216392 nosy: opoplawski priority: normal severity: normal status: open title: test_asyncio: test_subprocess_send_signal hangs on Fedora builders type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file34899/test_signal.out _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 23:37:05 2014 From: report at bugs.python.org (David Turner) Date: Tue, 15 Apr 2014 21:37:05 +0000 Subject: [issue21248] BROWSER env var described inaccurately in webbrowser docs Message-ID: <1397597825.94.0.182594358629.issue21248@psf.upfronthosting.co.za> New submission from David Turner: https://docs.python.org/2/library/webbrowser.html says "If the environment variable BROWSER exists, it is interpreted to override the platform default list of browsers, as a os.pathsep-separated list of browsers to try in order." This is not actually what happens; instead, it is prepended to the platform-default list of browsers. ---------- assignee: docs at python components: Documentation messages: 216393 nosy: docs at python, dturner-tw priority: normal severity: normal status: open title: BROWSER env var described inaccurately in webbrowser docs versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 23:39:08 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 15 Apr 2014 21:39:08 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1397597948.59.0.0241492515644.issue21233@psf.upfronthosting.co.za> Antoine Pitrou added the comment: So what is the point of _PyObject_GC_Calloc ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 23:40:38 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Tue, 15 Apr 2014 21:40:38 +0000 Subject: [issue21248] BROWSER env var described inaccurately in webbrowser docs In-Reply-To: <1397597825.94.0.182594358629.issue21248@psf.upfronthosting.co.za> Message-ID: <1397598038.71.0.626350938362.issue21248@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Which may be sane thing thing do. So the docs could be made better. Like - the list of browsers specified in env var BROWSER is tried first before looking at the platform defaults. ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 23:42:25 2014 From: report at bugs.python.org (Matt Mackall) Date: Tue, 15 Apr 2014 21:42:25 +0000 Subject: [issue21199] Python on 64-bit Windows uses signed 32-bit type for read length In-Reply-To: <1397149133.44.0.946556558932.issue21199@psf.upfronthosting.co.za> Message-ID: <1397598145.68.0.000632317511877.issue21199@psf.upfronthosting.co.za> Matt Mackall added the comment: Actually, no, all the size_t types are 64-bit on Windows 64: https://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models To confirm this, I found someone nearby with a 64-bit Windows and he had no trouble allocating a 3G string with a = b'a' * 3000000000. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 15 23:49:47 2014 From: report at bugs.python.org (Orion Poplawski) Date: Tue, 15 Apr 2014 21:49:47 +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: <1397598587.31.0.668396346773.issue21247@psf.upfronthosting.co.za> Orion Poplawski added the comment: Hmm, looking at things a little closer, it looks like the SIGHUP is arriving very early, perhaps too early? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 00:04:59 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 15 Apr 2014 22:04:59 +0000 Subject: [issue21199] Python on 64-bit Windows uses signed 32-bit type for read length In-Reply-To: <1397149133.44.0.946556558932.issue21199@psf.upfronthosting.co.za> Message-ID: <1397599499.38.0.347444153094.issue21199@psf.upfronthosting.co.za> Larry Hastings added the comment: D'oh, yeah, you guys are right. SSIZE_T_MAX > LONG_MAX, so that's an improvement. We just can't do the full size_t range. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 00:05:23 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Tue, 15 Apr 2014 22:05:23 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1397599523.14.0.871147696193.issue21233@psf.upfronthosting.co.za> Josh Rosenberg added the comment: General comment on patch: For the flag value that toggles zero-ing, perhaps use a different name, e.g. setzero, clearmem, initzero or somesuch instead of calloc? calloc already gets used to refer to both the C standard function and the function pointer structure member; it's mildly confusing to have it *also* refer to a boolean flag as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 00:10:42 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Tue, 15 Apr 2014 22:10:42 +0000 Subject: [issue21069] test_fileno of test_urllibnet intermittently fails when using www.example.com In-Reply-To: <1395821437.54.0.612861702522.issue21069@psf.upfronthosting.co.za> Message-ID: <1397599842.68.0.322194951609.issue21069@psf.upfronthosting.co.za> Senthil Kumaran added the comment: I am getting to this late. >> I don't know whether the file descriptor read is expected to be meaningful for urllib2/urllib.request. >> Senthil, what do you think? It should be meaningful no matter what the length is. I am looking further into this now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 00:14:09 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 15 Apr 2014 22:14:09 +0000 Subject: [issue21245] Logging Logger.exception documentation In-Reply-To: <1397593199.67.0.956489214078.issue21245@psf.upfronthosting.co.za> Message-ID: <3g7gw100Dyz7LjM@mail.python.org> Roundup Robot added the comment: New changeset dcb5ca1f1b44 by Vinay Sajip in branch '2.7': Issue #21245: updated documentation on exception() method and function. http://hg.python.org/cpython/rev/dcb5ca1f1b44 New changeset eee4fd2012ae by Vinay Sajip in branch '3.4': Issue #21245: updated documentation on exception() method and function. http://hg.python.org/cpython/rev/eee4fd2012ae New changeset a0ec713964b1 by Vinay Sajip in branch 'default': Closes #21245: merged update from 3.4. http://hg.python.org/cpython/rev/a0ec713964b1 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 00:16:21 2014 From: report at bugs.python.org (Matthias Klose) Date: Tue, 15 Apr 2014 22:16:21 +0000 Subject: [issue21249] removing pythonXY.zip from sys.path results in additional test failures Message-ID: <1397600181.83.0.758754205227.issue21249@psf.upfronthosting.co.za> New submission from Matthias Klose: At least Linux distros never ship pythonXY.zip, so I'm removing it from sys.path to save the extra lookup for a file which never exists. This did work in 2.x and 3.x up to 3.3. In 3.4 it does cause additional test failures: Re-running test 'test_cmd_line_script' in verbose mode [...] test_zipfile_compiled (test.test_cmd_line_script.CmdLineTest) ... ok test_zipfile_error (test.test_cmd_line_script.CmdLineTest) ... FAIL ====================================================================== FAIL: test_directory_error (test.test_cmd_line_script.CmdLineTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/build/buildd/python3.4-3.4.0/Lib/test/test_cmd_line_script.py", line 213, in test_directory_error self._check_import_error(script_dir, msg) File "/build/buildd/python3.4-3.4.0/Lib/test/test_cmd_line_script.py", line 156, in _check_import_error self.assertIn(expected_msg.encode('utf-8'), err) AssertionError: b"can't find '__main__' module in '/tmp/tmpc2iybbmi'" not found in b"Could not import runpy module\nImportError: No module named 'runpy'" ====================================================================== FAIL: test_zipfile_error (test.test_cmd_line_script.CmdLineTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/build/buildd/python3.4-3.4.0/Lib/test/test_cmd_line_script.py", line 235, in test_zipfile_error self._check_import_error(zip_name, msg) File "/build/buildd/python3.4-3.4.0/Lib/test/test_cmd_line_script.py", line 156, in _check_import_error self.assertIn(expected_msg.encode('utf-8'), err) AssertionError: b"can't find '__main__' module in '/tmp/tmp34n7w8gj/test_zip.zip'" not found in b"Could not import runpy module\nImportError: No module named 'runpy'" ---------------------------------------------------------------------- Ran 24 tests in 1.906s FAILED (failures=2) test test_cmd_line_script failed Re-running test 'test_zipimport_support' in verbose mode test_doctest_issue4197 (test.test_zipimport_support.ZipSupportTests) ... ok test_doctest_main_issue4197 (test.test_zipimport_support.ZipSupportTests) ... FAIL test_inspect_getsource_issue4223 (test.test_zipimport_support.ZipSupportTests) ... ok test_pdb_issue4201 (test.test_zipimport_support.ZipSupportTests) ... ok ====================================================================== FAIL: test_doctest_main_issue4197 (test.test_zipimport_support.ZipSupportTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/build/buildd/python3.4-3.4.0/Lib/test/test_zipimport_support.py", line 209, in test_doctest_main_issue4197 rc, out, err = assert_python_ok(zip_name) File "/build/buildd/python3.4-3.4.0/Lib/test/script_helper.py", line 69, in assert_python_ok return _assert_python(True, *args, **env_vars) File "/build/buildd/python3.4-3.4.0/Lib/test/script_helper.py", line 55, in _assert_python "stderr follows:\n%s" % (rc, err.decode('ascii', 'ignore'))) AssertionError: Process return code is 1, stderr follows: Could not import runpy module ImportError: No module named 'runpy' ---------- components: Tests files: no-zip-on-sys.path.diff keywords: patch messages: 216402 nosy: brett.cannon, doko, eric.snow, ncoghlan priority: normal severity: normal status: open title: removing pythonXY.zip from sys.path results in additional test failures type: enhancement versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file34900/no-zip-on-sys.path.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 00:17:19 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Tue, 15 Apr 2014 22:17:19 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1397600239.11.0.927751332388.issue21233@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Additional comment on clarity: Might it make sense to make the calloc structure member take both the num and size arguments that the underlying calloc takes? That is, instead of: void* (*calloc) (void *ctx, size_t size); Declare it as: void* (*calloc) (void *ctx, size_t num, size_t size); Beyond potentially allowing more detailed tracing info at some later point (and much like the original calloc, potentially allowing us to verify that the components do not overflow on multiply, instead of assuming every caller must multiply and check for themselves), it also seems like it's a bit more friendly to have the prototype for the structure calloc to follow the same pattern as the other members for consistency (Principle of Least Surprise): A context pointer, plus the arguments expected by the equivalent C function. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 00:20:09 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Tue, 15 Apr 2014 22:20:09 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1397600409.13.0.112677372422.issue21233@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Sorry for breaking it up, but the same comment on consistent prototypes mirroring the C standard lib calloc would apply to all the API functions as well, e.g. PyMem_RawCalloc, PyMem_Calloc, PyObject_Calloc and _PyObject_GC_Calloc, not just the structure function pointer. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 00:22:22 2014 From: report at bugs.python.org (Cameron Lee) Date: Tue, 15 Apr 2014 22:22:22 +0000 Subject: [issue21245] Logging Logger.exception documentation In-Reply-To: <1397593199.67.0.956489214078.issue21245@psf.upfronthosting.co.za> Message-ID: <1397600542.25.0.210297113088.issue21245@psf.upfronthosting.co.za> Cameron Lee added the comment: Are you sure that Python 3.2 and Python 3.3 don't need updated documentation? I don't know for sure if these two version have the code change or not but the http://bugs.python.org/issue15541 seems to indicate that 3.2 at least does. Thanks for the amazing response! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 00:23:22 2014 From: report at bugs.python.org (Jeff Ramnani) Date: Tue, 15 Apr 2014 22:23:22 +0000 Subject: [issue17449] dev guide appears not to cover the benchmarking suite In-Reply-To: <1363579697.14.0.518781563777.issue17449@psf.upfronthosting.co.za> Message-ID: <1397600602.03.0.307291944351.issue17449@psf.upfronthosting.co.za> Jeff Ramnani added the comment: Now that bug #18586 is closed, could the Dev Guide point benchmarkers to the benchmarks repo and its README? http://hg.python.org/benchmarks/file/9a1136898539/README.txt ---------- nosy: +jramnani _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 00:23:43 2014 From: report at bugs.python.org (Orion Poplawski) Date: Tue, 15 Apr 2014 22:23:43 +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: <1397600623.52.0.816334346555.issue21247@psf.upfronthosting.co.za> Orion Poplawski added the comment: It may also be possible that something has set the SIGHUP handler to SIG_IGN when the test is run. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 00:36:31 2014 From: report at bugs.python.org (Vinay Sajip) Date: Tue, 15 Apr 2014 22:36:31 +0000 Subject: [issue21245] Logging Logger.exception documentation In-Reply-To: <1397593199.67.0.956489214078.issue21245@psf.upfronthosting.co.za> Message-ID: <1397601391.9.0.147767135792.issue21245@psf.upfronthosting.co.za> Vinay Sajip added the comment: > Are you sure that Python 3.2 and Python 3.3 don't need updated documentation? As I understand it, the policy is not to do documentation updates for Python versions that will never see new releases. If a 3.x release manager says otherwise, I can revisit it - obviously the changes are easy to make :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 00:38:58 2014 From: report at bugs.python.org (Orion Poplawski) Date: Tue, 15 Apr 2014 22:38:58 +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: <1397601538.32.0.213723441287.issue21247@psf.upfronthosting.co.za> Orion Poplawski added the comment: Looks like in the Fedora koji builds, the SIGHUP sigaction is set to SIG_IGN, which causes the processes that the python tests are trying to kill with SIGHUP not to die. Perhaps the koji builders should not be doing that, perhaps the python tests should reset the SIGHUP sigaction to SIG_DFL. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 02:00:36 2014 From: report at bugs.python.org (=?utf-8?q?Evens_Fortun=C3=A9?=) Date: Wed, 16 Apr 2014 00:00:36 +0000 Subject: [issue21229] Path used for HTTP PUT request doesn't match the description In-Reply-To: <1397522183.41.0.398189687255.issue21229@psf.upfronthosting.co.za> Message-ID: <1397606436.48.0.264874946888.issue21229@psf.upfronthosting.co.za> Evens Fortun? added the comment: Is it what you asked? ---------- keywords: +patch Added file: http://bugs.python.org/file34901/issue21229.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 02:30:14 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 16 Apr 2014 00:30:14 +0000 Subject: [issue20874] Tutorial section on starting python is out of date In-Reply-To: <1394379932.36.0.812758095306.issue20874@psf.upfronthosting.co.za> Message-ID: <3g7kwy5mlfz7LjV@mail.python.org> Roundup Robot added the comment: New changeset cbe0cf95fe37 by R David Murray in branch '3.4': #20874: update tutorial wording: sophisticated line editing is now standard. http://hg.python.org/cpython/rev/cbe0cf95fe37 New changeset b5f4ab357ff9 by R David Murray in branch '3.4': #20874: reflow paragraph. http://hg.python.org/cpython/rev/b5f4ab357ff9 New changeset d4e3bea03f9f by R David Murray in branch 'default': Merge #20874 fix. http://hg.python.org/cpython/rev/d4e3bea03f9f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 02:31:51 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 16 Apr 2014 00:31:51 +0000 Subject: [issue20874] Tutorial section on starting python is out of date In-Reply-To: <1394379932.36.0.812758095306.issue20874@psf.upfronthosting.co.za> Message-ID: <1397608311.33.0.572245933991.issue20874@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, Rafael. ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 03:02:55 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Wed, 16 Apr 2014 01:02:55 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1397610175.97.0.0602069427964.issue16991@psf.upfronthosting.co.za> Changes by Josh Rosenberg : ---------- nosy: +josh.rosenberg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 03:13:20 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 16 Apr 2014 01:13:20 +0000 Subject: [issue15840] Ambiguity with regard to the effect of accessing a closed IOBase instance In-Reply-To: <1346524424.76.0.407141547435.issue15840@psf.upfronthosting.co.za> Message-ID: <3g7ltl3sRpz7LjP@mail.python.org> Roundup Robot added the comment: New changeset 7a27039e4a42 by Andrew Kuchling in branch '3.4': #15840: make docs consistent by saying operations on closed files raise ValueError. http://hg.python.org/cpython/rev/7a27039e4a42 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 03:16:57 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 16 Apr 2014 01:16:57 +0000 Subject: [issue1704474] optparse tests fail under Jython Message-ID: <3g7lyx0Gvgz7LjR@mail.python.org> Roundup Robot added the comment: New changeset c76d782cb9df by Andrew Kuchling in branch '3.4': #1704474: mark refleak test as specific to CPython http://hg.python.org/cpython/rev/c76d782cb9df ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 03:30:54 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 16 Apr 2014 01:30:54 +0000 Subject: [issue15840] Ambiguity with regard to the effect of accessing a closed IOBase instance In-Reply-To: <1346524424.76.0.407141547435.issue15840@psf.upfronthosting.co.za> Message-ID: <1397611854.15.0.269634592811.issue15840@psf.upfronthosting.co.za> A.M. Kuchling added the comment: Committed to 2.7, 3.4, and default. Thanks for your patch! ---------- nosy: +akuchling resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 03:32:41 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Wed, 16 Apr 2014 01:32:41 +0000 Subject: [issue21069] test_fileno of test_urllibnet intermittently fails when using www.example.com In-Reply-To: <1395821437.54.0.612861702522.issue21069@psf.upfronthosting.co.za> Message-ID: <1397611961.32.0.714844350725.issue21069@psf.upfronthosting.co.za> Senthil Kumaran added the comment: This is the best way I found to reproduce the failure. I changed the resource to www.example.com and then ran this. $ ./python.exe -m test -m "*fileno*" -u all -v -F test_urllibnet ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 03:33:34 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 16 Apr 2014 01:33:34 +0000 Subject: [issue1704474] optparse tests fail under Jython Message-ID: <1397612014.51.0.955606948321.issue1704474@psf.upfronthosting.co.za> A.M. Kuchling added the comment: Committed to 2.7, 3.4, and default. Thanks for your patch! ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 03:37:06 2014 From: report at bugs.python.org (Ned Deily) Date: Wed, 16 Apr 2014 01:37:06 +0000 Subject: [issue21244] distutils fails to build C extensions with XCode 5.1 and OS X 10.9 (Mavericks) In-Reply-To: <1397589386.91.0.235020854992.issue21244@psf.upfronthosting.co.za> Message-ID: <1397612226.9.0.502545561545.issue21244@psf.upfronthosting.co.za> Ned Deily added the comment: This is a problem specifically with the Apple-supplied system Pythons in OS X 10.9. It's due to the obsolete configuration parameters used in their build of Python and due to changes in Xcode 5.1. Expect Apple to fix it in an upcoming maintenance release of OS X 10.9.x. ---------- nosy: +ned.deily resolution: -> 3rd party stage: -> committed/rejected status: open -> closed type: compile error -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 04:29:15 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 16 Apr 2014 02:29:15 +0000 Subject: [issue20103] Documentation of itertools.accumulate is confused In-Reply-To: <1388592720.87.0.970906154406.issue20103@psf.upfronthosting.co.za> Message-ID: <3g7nZL3zvyz7LkJ@mail.python.org> Roundup Robot added the comment: New changeset 9e1d2150fff2 by Andrew Kuchling in branch 'default': #20103: Rewrite description of itertools.accumulate(). http://hg.python.org/cpython/rev/9e1d2150fff2 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 04:30:21 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 16 Apr 2014 02:30:21 +0000 Subject: [issue20103] Documentation of itertools.accumulate is confused In-Reply-To: <1388592720.87.0.970906154406.issue20103@psf.upfronthosting.co.za> Message-ID: <1397615421.77.0.65718874246.issue20103@psf.upfronthosting.co.za> A.M. Kuchling added the comment: Thanks for your patch! ---------- assignee: rhettinger -> akuchling nosy: +akuchling resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 04:38:06 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 16 Apr 2014 02:38:06 +0000 Subject: [issue8931] '#' has no effect with 'c' type In-Reply-To: <1275865635.78.0.716511257083.issue8931@psf.upfronthosting.co.za> Message-ID: <3g7nmZ09KPz7LjS@mail.python.org> Roundup Robot added the comment: New changeset b1aba042b36c by Eric V. Smith in branch 'default': Close issue #8931: Make alternate formatting for 'c' raise an exception. Patch by Torsten Landschoff. http://hg.python.org/cpython/rev/b1aba042b36c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 04:40:56 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 16 Apr 2014 02:40:56 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1397616056.23.0.259994659332.issue21233@psf.upfronthosting.co.za> STINNER Victor added the comment: > So what is the point of _PyObject_GC_Calloc ? It calls calloc(size) instead of malloc(size), calloc() which can be faster than malloc()+memset(), see: https://mail.python.org/pipermail/python-dev/2014-April/133985.html _PyObject_GC_Calloc() is used by PyType_GenericAlloc(). If I understand directly, it is the default allocator to allocate Python objects. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 04:41:59 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 16 Apr 2014 02:41:59 +0000 Subject: [issue21246] test_ssl handshake failure In-Reply-To: <1397593348.91.0.829573885546.issue21246@psf.upfronthosting.co.za> Message-ID: <1397616119.68.0.986294385737.issue21246@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Very old version of openssl? ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 04:48:22 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 16 Apr 2014 02:48:22 +0000 Subject: [issue6490] os.popen documentation is probably wrong In-Reply-To: <1247646939.28.0.091306950041.issue6490@psf.upfronthosting.co.za> Message-ID: <1397616502.67.0.458893554324.issue6490@psf.upfronthosting.co.za> A.M. Kuchling added the comment: I thought the discussion of the return code was rather complicated and tried rewriting it; new patch attached. Is it an improvement? The new version also specifies the function's parameters. ---------- nosy: +akuchling Added file: http://bugs.python.org/file34902/6490-os-popen-docs.diff-2.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 04:49:46 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 16 Apr 2014 02:49:46 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1397616586.54.0.302641658541.issue21233@psf.upfronthosting.co.za> STINNER Victor added the comment: In numpy, I found the two following functions: /*NUMPY_API * Allocates memory for array data. */ void* PyDataMem_NEW(size_t size); /*NUMPY_API * Allocates zeroed memory for array data. */ void* PyDataMem_NEW_ZEROED(size_t size, size_t elsize); So it looks like it needs two size_t parameters. Prototype of the C function calloc(): void *calloc(size_t nmemb, size_t size); I agree that it's better to provide the same prototype than calloc(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 04:52:16 2014 From: report at bugs.python.org (Sam Kimbrel) Date: Wed, 16 Apr 2014 02:52:16 +0000 Subject: [issue6490] os.popen documentation is probably wrong In-Reply-To: <1247646939.28.0.091306950041.issue6490@psf.upfronthosting.co.za> Message-ID: <1397616736.48.0.324184299881.issue6490@psf.upfronthosting.co.za> Sam Kimbrel added the comment: Yes, I think that wording works a lot better. Thanks for the touch-up. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 05:28:58 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 16 Apr 2014 03:28:58 +0000 Subject: [issue18566] In unittest.TestCase docs for setUp() and tearDown() don't mention AssertionError In-Reply-To: <1374901937.1.0.747872580847.issue18566@psf.upfronthosting.co.za> Message-ID: <1397618938.81.0.120863988412.issue18566@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- assignee: docs at python -> terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 05:45:22 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 16 Apr 2014 03:45:22 +0000 Subject: [issue18566] In unittest.TestCase docs for setUp() and tearDown() don't mention AssertionError In-Reply-To: <1374901937.1.0.747872580847.issue18566@psf.upfronthosting.co.za> Message-ID: <3g7qG970Ztz7LjM@mail.python.org> Roundup Robot added the comment: New changeset fdadc152b964 by Terry Jan Reedy in branch '2.7': Issue #18566: Clarify unittest setUp, tearDown doc. Patch by Nitika Agarwal. http://hg.python.org/cpython/rev/fdadc152b964 New changeset 9ab66a7f654a by Terry Jan Reedy in branch '3.4': Issue #18566: Clarify unittest setUp, tearDown doc. Patch by Nitika Agarwal. http://hg.python.org/cpython/rev/9ab66a7f654a New changeset 72b1715e18c1 by Terry Jan Reedy in branch '2.7': #18566: Whitespace http://hg.python.org/cpython/rev/72b1715e18c1 New changeset a37440dec1b6 by Terry Jan Reedy in branch '3.4': #18566: Whitespace http://hg.python.org/cpython/rev/a37440dec1b6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 05:47:01 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 16 Apr 2014 03:47:01 +0000 Subject: [issue18566] In unittest.TestCase docs for setUp() and tearDown() don't mention AssertionError In-Reply-To: <1374901937.1.0.747872580847.issue18566@psf.upfronthosting.co.za> Message-ID: <1397620021.22.0.91383268902.issue18566@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Nitika, congrats on first patch. One minor problem: spaces at end of lines. It it my fault for not checking, but try to avoid them anyway. ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 05:53:02 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Wed, 16 Apr 2014 03:53:02 +0000 Subject: [issue21069] test_fileno of test_urllibnet intermittently fails when using www.example.com In-Reply-To: <1395821437.54.0.612861702522.issue21069@psf.upfronthosting.co.za> Message-ID: <1397620382.47.0.0839031714288.issue21069@psf.upfronthosting.co.za> Senthil Kumaran added the comment: This is turning out be trickier than I ever thought. fileno() returning b'' is just random error. The underlying issue is, *directly* reading from the fp of the socket() is returning a incomplete output at all times. The correct way to read the output is by using HTTPResponse read() method only it seems. Here is a small snippet that will fail for every url. from urllib.request import urlopen import os web = "http://www.example.org" open_url = urlopen(web) fd = open_url.fileno() with os.fdopen(fd, 'rb') as f: file_read_len = len(f.read()) req = urlopen(web) res_len = len(req.read()) assert file_read_len == res_len ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 06:00:14 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Wed, 16 Apr 2014 04:00:14 +0000 Subject: [issue21069] test_fileno of test_urllibnet intermittently fails when using www.example.com In-Reply-To: <1395821437.54.0.612861702522.issue21069@psf.upfronthosting.co.za> Message-ID: <1397620814.87.0.624275555903.issue21069@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Ned Deily had done the correct analysis in the msg214947 and has this question - > I don't know whether the file descriptor read is expected to be meaningful for urllib2/urllib.request. I can see that this test case was for the old behavior where we created a file like object to read using addinfourl and fileno /fp was explicitly set. We have to determine if this expectation that we can access the socket's fp using HTTPResponse object is a right one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 06:21:26 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 16 Apr 2014 04:21:26 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1397622086.41.0.689282739943.issue21233@psf.upfronthosting.co.za> STINNER Victor added the comment: New patch: - replace "size_t size" with "size_t nelem, size_t elsize" in the prototype of calloc functions (the parameter names come from the POSIX standard) - replace "int calloc" with "int zero" in helper functions ---------- Added file: http://bugs.python.org/file34903/calloc-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 06:43:51 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 16 Apr 2014 04:43:51 +0000 Subject: [issue21139] Idle: change default reformat width from 70 to 72 In-Reply-To: <1396492163.57.0.51526901235.issue21139@psf.upfronthosting.co.za> Message-ID: <1397623431.67.0.315902957049.issue21139@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I am puzzled at the differences between the 2.7 and 3.4 patches. There are only three differences between the files - from Tkinter import Tk, Text, TclError + from tkinter import Tk, Text, TclError ? ^ - from test.test_support import requires + from test.support import requires ? ^ - get_selection_indices = EditorWindow.get_selection_indices.im_func + get_selection_indices = EditorWindow. get_selection_indices and none of these should affect the patch. The attached patch adds a limit parameter to the FormatParagraph.format_paragraph_event method ReformatParagraph.py that is called as self.formatter in the tests. cls.formatter = fp.FormatParagraph(editor).format_paragraph_event With this change, we can augment the calls to self.formatter('ParameterDoesNothing', 72) and the tests will ignore the configured value. ---------- Added file: http://bugs.python.org/file34904/21139-34-fpe.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 07:08:55 2014 From: report at bugs.python.org (=?utf-8?q?Evens_Fortun=C3=A9?=) Date: Wed, 16 Apr 2014 05:08:55 +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: <1397624935.65.0.55454867175.issue21228@psf.upfronthosting.co.za> Changes by Evens Fortun? : Added file: http://bugs.python.org/file34905/urllib.request.rst _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 07:34:58 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 16 Apr 2014 05:34:58 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397616056.23.0.259994659332.issue21233@psf.upfronthosting.co.za> Message-ID: <534E167F.3060200@free.fr> Antoine Pitrou added the comment: Le 16/04/2014 04:40, STINNER Victor a ?crit : > > STINNER Victor added the comment: > >> So what is the point of _PyObject_GC_Calloc ? > > It calls calloc(size) instead of malloc(size) No, the question is why you didn't simply change _PyObject_GC_Malloc (which is a private function). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 07:42:56 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 16 Apr 2014 05:42: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: <1397626976.6.0.137171129461.issue21247@psf.upfronthosting.co.za> STINNER Victor added the comment: This issue is a race condition or bug in the unit test, not in asyncio. The test doesn't check if echo.py is running, if Python started. Python doesn't setup an handler for SIGHUP, it uses the current handler. On my Fedora 20, it looks to be "SIG_DFL": Python 3.5.0a0 (default:795d90c7820d+, Apr 16 2014, 00:18:50) [GCC 4.8.2 20131212 (Red Hat 4.8.2-7)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import signal >>> signal.getsignal(signal.SIGHUP) Extract of the attached strace: --- clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f9d1e8cba10) = 24719 Process 24719 attached ... [pid 24719] rt_sigaction(SIGHUP, NULL, {SIG_IGN, [], 0}, 8) = 0 ... [pid 24625] kill(24719, SIGHUP) = 0 [pid 24719] --- SIGHUP {si_signo=SIGHUP, si_code=SI_USER, si_pid=24625, si_uid=1000} --- --- So the child process has SIGHUP configured to SIG_IGN on your platform. ---------- nosy: +gvanrossum, haypo, yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 07:53:51 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 16 Apr 2014 05:53:51 +0000 Subject: [issue21199] Python on 64-bit Windows uses signed 32-bit type for read length In-Reply-To: <1397149133.44.0.946556558932.issue21199@psf.upfronthosting.co.za> Message-ID: <1397627631.07.0.606788436671.issue21199@psf.upfronthosting.co.za> STINNER Victor added the comment: On Windows, the type of the size parameter of read() is an unsigned int, not long nor size_t: http://msdn.microsoft.com/en-us/library/1570wh78.aspx FileIO.read() of Python 3 uses a size_t type but also: #ifdef MS_WINDOWS if (size > INT_MAX) size = INT_MAX; #endif ... #ifdef MS_WINDOWS n = read(self->fd, ptr, (int)size); #else n = read(self->fd, ptr, size); #endif Using a size_t to parse the Python parameter would avoid an OverflowError and the function would be more portable. But it would not permit to read more than 2 GB at once. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 08:09:45 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 16 Apr 2014 06:09:45 +0000 Subject: [issue21199] Python on 64-bit Windows uses signed 32-bit type for read length In-Reply-To: <1397149133.44.0.946556558932.issue21199@psf.upfronthosting.co.za> Message-ID: <1397628585.43.0.929567598463.issue21199@psf.upfronthosting.co.za> STINNER Victor added the comment: "It is much simpler for Mercurial to add a workaround (which they already did, apparently :-)), than to risk introducing regressions by fixing this. AFAIK nobody else complained before." We fixed a lot of issues for 32-bit long and 64-bit size_t types (Windows 64 bits) in Python 3.3 and 3.4. I don't think that they were fixed in Python 2.7, because the required changes are large and it would be risky to backport them. At least, I don't feel confortable to backport them. I suggest to switch to Python 3 if you would like to handle large objects (bigger than 2 GB) on Windows 64-bit. See the issue #9566 for examples of fixes, but there were many other changes related to 64-bit Windows issues. I see for example that send() & send_bytes() methods of multiprocessing connection doesn't truncate the length to DWORD_MAX bytes on Windows in Python 2.7, whereas it was fixed in Python 3: http://hg.python.org/cpython/rev/c75ab7b802df (On UNIX, the same methods loop on write() to ensure that all bytes are written.) If you want to announce that Python 2.7.x supports large objects on Windows 64 bits, be prepared to have to fix Python in various different places. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 08:19:18 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 16 Apr 2014 06:19:18 +0000 Subject: [issue21199] Python on 64-bit Windows uses signed 32-bit type for read length In-Reply-To: <1397149133.44.0.946556558932.issue21199@psf.upfronthosting.co.za> Message-ID: <1397629158.2.0.672605843294.issue21199@psf.upfronthosting.co.za> STINNER Victor added the comment: > On Windows, the type of the size parameter of read() is an unsigned int, not long nor size_t (...) Oh, I read the wrong function. In fact, file_read() of Python 2.7 calls fread() and fread() uses size_t types, even on Windows. To make sure that we are talking about the same thing, I wrote the attached file_read_size_t.patch file which replaces "l" with "n" in file_read(). Note: os.read() uses int types, even on Python 3.5, whereas read() uses a size_t type for the number of bytes on Linux. ---------- keywords: +patch Added file: http://bugs.python.org/file34906/file_read_size_t.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 08:19:19 2014 From: report at bugs.python.org (Ned Deily) Date: Wed, 16 Apr 2014 06:19:19 +0000 Subject: [issue21069] test_fileno of test_urllibnet intermittently fails when using www.example.com In-Reply-To: <1395821437.54.0.612861702522.issue21069@psf.upfronthosting.co.za> Message-ID: <1397629159.62.0.184964434175.issue21069@psf.upfronthosting.co.za> Ned Deily added the comment: Senthil, thanks for looking into this. Since it is turning out to be more of a urllib design issue, I'm going to deassign myself from it. ---------- assignee: ned.deily -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 08:36:27 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 16 Apr 2014 06:36:27 +0000 Subject: [issue21199] Python on 64-bit Windows uses signed 32-bit type for read length In-Reply-To: <1397149133.44.0.946556558932.issue21199@psf.upfronthosting.co.za> Message-ID: <1397630187.46.0.680387413327.issue21199@psf.upfronthosting.co.za> STINNER Victor added the comment: "If you want to announce that Python 2.7.x supports large objects on Windows 64 bits, be prepared to have to fix Python in various different places." You can compare which modules define PY_SSIZE_T_CLEAN in Python 2.7 and 3.x. For example, it looks like bz2 and zlib modules handle correctly 64-bit lengths in Python 3, but don't in Python 2. By the way, BZ2File_read() in Python 2.7 uses also the "l" format to parse the input length. It looks like the code was copied from fileobject.c. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 08:40:18 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 16 Apr 2014 06:40:18 +0000 Subject: [issue21220] Enhance obmalloc allocation strategy In-Reply-To: <1397499786.06.0.606856949694.issue21220@psf.upfronthosting.co.za> Message-ID: <1397630418.28.0.225572655073.issue21220@psf.upfronthosting.co.za> STINNER Victor added the comment: It was also discussed to replace pymalloc with Windows Low Fragementation Heap (LFH) allocator on Windows: http://bugs.python.org/issue13483#msg148605 ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 08:44:08 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 16 Apr 2014 06:44:08 +0000 Subject: [issue21220] Enhance obmalloc allocation strategy In-Reply-To: <1397499786.06.0.606856949694.issue21220@psf.upfronthosting.co.za> Message-ID: <1397630648.38.0.443989476497.issue21220@psf.upfronthosting.co.za> STINNER Victor added the comment: It would also be interesting to compare fragmentation and performances of Python with and without pymalloc, maybe with other heap allocators like FreeBSD jemalloc and Google TCMalloc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 08:44:30 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 16 Apr 2014 06:44:30 +0000 Subject: [issue21075] fileinput should use stdin.buffer for "rb" mode In-Reply-To: <1395927763.6.0.283357087125.issue21075@psf.upfronthosting.co.za> Message-ID: <1397630670.04.0.0031956842208.issue21075@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 08:47:56 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 16 Apr 2014 06:47:56 +0000 Subject: [issue1191964] asynchronous Subprocess Message-ID: <1397630876.47.0.277987098054.issue1191964@psf.upfronthosting.co.za> STINNER Victor added the comment: I suggest to change the title of the issue to: "subprocess: add non-blocking read and write methods" to avoid the confusion with asyncio subprocess module which runs read and write "in the background" for you. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 09:03:37 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Wed, 16 Apr 2014 07:03:37 +0000 Subject: [issue21220] Enhance obmalloc allocation strategy In-Reply-To: <1397581194.56.0.274160051799.issue21220@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > In Python 3, arenas are allocated using mmap(), so wherever the arena ends up in the address space shouldn't matter, should it? Indeed, although the effect on cache locality isn't clear. Also, I don't think this solves the problem of having a single object allocated inside a high address arena preventing the heap from shrinking (which was the original reason for having the arenas allocated by mmap). Anyway, we can only go that far with reference counting (I mean that you'd need a proper moving garbage collector for this). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 09:18:37 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Wed, 16 Apr 2014 07:18:37 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397616056.23.0.259994659332.issue21233@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: >> So what is the point of _PyObject_GC_Calloc ? > > It calls calloc(size) instead of malloc(size), calloc() which can be faster than malloc()+memset(), see: > https://mail.python.org/pipermail/python-dev/2014-April/133985.html It will only make a difference if the allocated region is large enough to be allocated by mmap (so not for 90% of objects). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 09:28:27 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 16 Apr 2014 07:28:27 +0000 Subject: [issue1191964] asynchronous Subprocess Message-ID: <1397633307.92.0.404191877838.issue1191964@psf.upfronthosting.co.za> STINNER Victor added the comment: I started to review the patch 5: http://bugs.python.org/review/1191964/#ps11598 When I read unit tests, I realized that I don't like "write_nonblocking" name. It's too generic. A process has many files (more than just stdin, stdout, stderr: see pass_fds parameter of Popen). I would like an explicit "write_stdin_nonblocking" and "read_stdout_nonblocking". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 09:30:51 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 16 Apr 2014 07:30:51 +0000 Subject: [issue21207] urandom persistent fd - not re-openned after fd close In-Reply-To: <1397316819.31.0.463593532744.issue21207@psf.upfronthosting.co.za> Message-ID: <1397633451.38.0.988919574716.issue21207@psf.upfronthosting.co.za> STINNER Victor added the comment: > I agree in part, but it's quite common to close fd's in some cases like in a child process after using "os.fork()" Which project or Python module does that? Can you show me the code? ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 09:33:52 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 16 Apr 2014 07:33:52 +0000 Subject: [issue21111] Add a new PyLong_AsUnsignedLongAndOverflow function In-Reply-To: <1396272396.7.0.644063349125.issue21111@psf.upfronthosting.co.za> Message-ID: <1397633632.54.0.0458191909322.issue21111@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: PyLong_AsUnsignedLongAndOverflow does not exist -> Add a new PyLong_AsUnsignedLongAndOverflow function _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 09:43:43 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 16 Apr 2014 07:43:43 +0000 Subject: [issue20434] Fix error handler of _PyString_Resize() on allocation failure In-Reply-To: <1390984600.38.0.476358983499.issue20434@psf.upfronthosting.co.za> Message-ID: <1397634223.93.0.000884184673276.issue20434@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: Process crashes if not enough memory to import module -> Fix error handler of _PyString_Resize() on allocation failure _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 09:45:30 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 16 Apr 2014 07:45:30 +0000 Subject: [issue21180] Efficiently create empty array.array, consistent with bytearray In-Reply-To: <1396963926.18.0.0845457465299.issue21180@psf.upfronthosting.co.za> Message-ID: <1397634330.45.0.0166154821071.issue21180@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 09:48:06 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 16 Apr 2014 07:48:06 +0000 Subject: [issue21216] getaddrinfo is wrongly considered thread safe on linux In-Reply-To: <1397496103.55.0.0681287877532.issue21216@psf.upfronthosting.co.za> Message-ID: <1397634486.24.0.703271248264.issue21216@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 09:51:27 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 16 Apr 2014 07:51:27 +0000 Subject: [issue21216] getaddrinfo is wrongly considered thread safe on linux In-Reply-To: <1397496103.55.0.0681287877532.issue21216@psf.upfronthosting.co.za> Message-ID: <1397634687.97.0.995650431877.issue21216@psf.upfronthosting.co.za> STINNER Victor added the comment: > It may only be reproductible when your getaddrinfo use a NETLINK to get informations about your interfaces before doing the DNS query. What is your operation system? Name and version. What is your version of the C library? What is your Python version? Can you provide an example to reproduce the issue? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 09:52:41 2014 From: report at bugs.python.org (Alex Lord) Date: Wed, 16 Apr 2014 07:52:41 +0000 Subject: [issue21250] sqlite3 doesn't have unit tests for 'insert or [algorithm]' functionality. Message-ID: <1397634761.6.0.834429340049.issue21250@psf.upfronthosting.co.za> New submission from Alex Lord: In Lib/sqlite3/tests/dbapi.py there are no unit tests which test out sqlite3's 'insert or [algorithm].' These algorithms are also referred to as SQL 'insert on conflict.' More details at, https://www.sqlite.org/lang_conflict.html Not having unit tests for these features, especially 'insert or rollback,' seems like an easy way for timing and threading bugs to get lost in the database api. ---------- components: Tests messages: 216448 nosy: Alex.Lord priority: normal severity: normal status: open title: sqlite3 doesn't have unit tests for 'insert or [algorithm]' functionality. type: enhancement versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 09:58:50 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 16 Apr 2014 07:58:50 +0000 Subject: [issue21216] getaddrinfo is wrongly considered thread safe on linux In-Reply-To: <1397496103.55.0.0681287877532.issue21216@psf.upfronthosting.co.za> Message-ID: <1397635130.78.0.692993838.issue21216@psf.upfronthosting.co.za> STINNER Victor added the comment: test_getaddrinfo.c: C program to run getaddrinfo() concurrently in different threads, it comes from the Debian issue. I ran this program with 10 threads, I stopped it after between 3000 and 5000 tries (depending on the thread). I'm running Fedora 20: Linux kernel 3.13.9-200.fc20.x86_64 and glibc 2.18. ---------- Added file: http://bugs.python.org/file34907/test_getaddrinfo.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 09:59:12 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 16 Apr 2014 07:59:12 +0000 Subject: [issue21216] getaddrinfo is wrongly considered thread safe on linux In-Reply-To: <1397496103.55.0.0681287877532.issue21216@psf.upfronthosting.co.za> Message-ID: <1397635152.28.0.745120871457.issue21216@psf.upfronthosting.co.za> STINNER Victor added the comment: Can you provide the C and Python backtrace of all threads of your program? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 10:04:31 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 16 Apr 2014 08:04:31 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <534E167F.3060200@free.fr> Message-ID: STINNER Victor added the comment: >>> So what is the point of _PyObject_GC_Calloc ? >> >> It calls calloc(size) instead of malloc(size) > > No, the question is why you didn't simply change _PyObject_GC_Malloc > (which is a private function). Oh ok, I didn't understand. I don't like changing the behaviour of functions, but it's maybe fine if the function is private. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 10:06:13 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 16 Apr 2014 08:06:13 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: Message-ID: STINNER Victor added the comment: 2014-04-16 3:18 GMT-04:00 Charles-Fran?ois Natali : >> It calls calloc(size) instead of malloc(size), calloc() which can be faster than malloc()+memset(), see: >> https://mail.python.org/pipermail/python-dev/2014-April/133985.html > > It will only make a difference if the allocated region is large enough > to be allocated by mmap (so not for 90% of objects). Even if there are only 10% of cases where it may be faster, I think that it's interesting to use calloc() to allocate Python objects. You may create large Python objects ;-) I didn't check which objects use (indirectly) _PyObject_GC_Calloc(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 10:40:24 2014 From: report at bugs.python.org (Wolfgang Maier) Date: Wed, 16 Apr 2014 08:40:24 +0000 Subject: [issue21234] __contains__ and friends should check "is" for all elements first In-Reply-To: <1397567063.59.0.649029276797.issue21234@psf.upfronthosting.co.za> Message-ID: <1397637624.92.0.217280179059.issue21234@psf.upfronthosting.co.za> Wolfgang Maier added the comment: ???? I don't even know where to start with this. a) this recipe is not working b) it's hardly readable c) it is pointless Why are you complicating things by testing for != ? What advantage does this offer over == ? You do not need class methods at all to achieve what you want (in fact the __ne__ as a method of the container is just wrong), instead use the one-liner: any(element == value for element in container) to find out if any element of your container equals value without doing the identity check, but then: the identity check is anyway the fast part compared to the equality check (at least you assumed that in your first post). and in fact with: >>> l=list(range(20000000)) >>> 20000000 in l False is much faster than: >>> any(e == 20000000 for e in l) False despite checking identity AND equality, simply because it isn't doing things in Python. So while the current docs say this about the in operator: """ For container types such as list, tuple, set, frozenset, dict, or collections.deque, the expression x in y is equivalent to any(x is e or x == e for e in y). """ I guess, that doesn't mean it is actually implemented like that, but only that the result is equivalent. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 11:20:13 2014 From: report at bugs.python.org (=?utf-8?b?SHJ2b2plIE5pa8WhacSH?=) Date: Wed, 16 Apr 2014 09:20:13 +0000 Subject: [issue21167] float('nan') returns 0.0 on Python compiled with icc In-Reply-To: <1396864952.24.0.891595123462.issue21167@psf.upfronthosting.co.za> Message-ID: <1397640013.46.0.914874090788.issue21167@psf.upfronthosting.co.za> Hrvoje Nik?i? added the comment: Using -fp-model strict (or other appropriate icc flag) seems like a reasonable resolution. It should likely also be applied to Python 3.x, despite the version field of this issue. (Even if float('nan') happens to work in current 3.x, internal code that returns Py_NAN can and will break.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 11:54:37 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 16 Apr 2014 09:54:37 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1397642077.2.0.824683134819.issue21233@psf.upfronthosting.co.za> Stefan Krah added the comment: I left a Rietveld comment, which probably did not get mailed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 12:07:08 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 16 Apr 2014 10:07:08 +0000 Subject: [issue21015] support SSL_CTX_set_ecdh_auto on newer OpenSSLs In-Reply-To: <1395455671.92.0.144736574461.issue21015@psf.upfronthosting.co.za> Message-ID: <1397642828.18.0.568697336604.issue21015@psf.upfronthosting.co.za> Stefan Krah added the comment: In case anyone wonders why the FreeBSD bot works again: I've installed OpenSSL from source. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 12:30:57 2014 From: report at bugs.python.org (Jurjen N.E. Bos) Date: Wed, 16 Apr 2014 10:30:57 +0000 Subject: [issue21234] __contains__ and friends should check "is" for all elements first In-Reply-To: <1397567063.59.0.649029276797.issue21234@psf.upfronthosting.co.za> Message-ID: <1397644257.49.0.443729812866.issue21234@psf.upfronthosting.co.za> Jurjen N.E. Bos added the comment: Oops. That was a hard lesson: 1) don't haste when posting 2) always run what you post. The point was the trick to define a custom __ne__ and not an __eq__ for an object (not for the container it is in!) so you can use "in" at full speed. Then not all(map(ne, repeat(obj), container)) or not all(map(obj.__ne__, container)) can be used if you really what to check for equality. This does make a difference in my case, where I only sometimes check for a non-identical object in the container, and I know when I do that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 13:04:58 2014 From: report at bugs.python.org (Chris Rose) Date: Wed, 16 Apr 2014 11:04:58 +0000 Subject: [issue20752] Difflib should provide the option of overriding the SequenceMatcher In-Reply-To: <1393193816.17.0.662615840954.issue20752@psf.upfronthosting.co.za> Message-ID: <1397646298.42.0.339177911493.issue20752@psf.upfronthosting.co.za> Changes by Chris Rose : ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 13:17:04 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Wed, 16 Apr 2014 11:17:04 +0000 Subject: [issue21237] Update Python 2/3 porting HOWTO's suggestion for dealing with map() In-Reply-To: <1397576750.55.0.0117658136784.issue21237@psf.upfronthosting.co.za> Message-ID: <1397647024.56.0.205268352345.issue21237@psf.upfronthosting.co.za> Josh Rosenberg added the comment: I think the suggestion is intended for "how do I keep Python 2 semantics in Python 3?", not "how can I write my Python 2 code so it will run equivalently in Python 3?" It wouldn't be a bad idea to point out that you can adopt Py3 semantics initially so as to avoid surprises later on; sadly, unlike a __future__ import, if you want cross compatible code you have to do stupid stuff like: try: from future_builtins import * except ImportError: # Py3 is already the future pass ---------- nosy: +josh.rosenberg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 13:43:21 2014 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Wed, 16 Apr 2014 11:43:21 +0000 Subject: [issue21235] importlib's spec module create algorithm is not exposed In-Reply-To: <1397571881.77.0.850697644958.issue21235@psf.upfronthosting.co.za> Message-ID: <1397648601.02.0.426680856404.issue21235@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- nosy: +tshepang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 14:42:17 2014 From: report at bugs.python.org (Martin Kolman) Date: Wed, 16 Apr 2014 12:42:17 +0000 Subject: [issue21251] Standard library trace module crashes with exception Message-ID: <1397652137.22.0.406999160837.issue21251@psf.upfronthosting.co.za> New submission from Martin Kolman: We are currently working on adding tracing support to Anaconda, the Fedora/Red Hat Enterprise Linux installer and we have encountered some pretty strange behavior of the trace module. Anaconda (or to be concrete the Blivet storage library used by Anaconda) uses the pyblock module, but just importing it crashes the trace module with a strange exception. It can be reproduced like this: 0. install pyblock (on Fedora is is provided by the python-pyblock package) 1. write some python code that imports the "block" module provided by pyblock echo "import block" > pyblock_trace.py 2. try to trace the code python -m trace -t pyblock_trace.py The trace module starts tracing but after a few seconds it crashes with the following traceback: Traceback (most recent call last): File "/usr/lib64/python2.7/runpy.py", line 162, in _run_module_as_main "__main__", fname, loader, pkg_name) File "/usr/lib64/python2.7/runpy.py", line 72, in _run_code exec code in run_globals File "/usr/lib64/python2.7/trace.py", line 830, in main() File "/usr/lib64/python2.7/trace.py", line 818, in main t.runctx(code, globs, globs) File "/usr/lib64/python2.7/trace.py", line 513, in runctx exec cmd in globals, locals File "pyblock_trace.py", line 1, in import block File "/usr/lib64/python2.7/site-packages/block/__init__.py", line 47, in import dmraid File "", line 1, in File "/usr/lib64/python2.7/trace.py", line 609, in globaltrace_lt filename = frame.f_globals.get('__file__', None) AttributeError: 'module' object has no attribute 'get' The dmraid module is written in C and we have looked though its source[1] code but have found nothing extraordinary. Most importantly there is no code touching the globals, but it still fails. When looking what actually is in frame.f_globals we found that in all successful calls it has the globals dictionary but for the dmraid module it for some reason contains the module instance instead. Module instance is not a dictionary, so it doesn't have the get method and this leads to the exception above. This is not the only C module we use, but this is the only one that triggers the crash in trace. Additional information Python version: 2.7.5 architecture: X86_64 OS: Fedora 20 [1] https://git.fedorahosted.org/cgit/pyblock.git/tree/dmraid.c ---------- components: Library (Lib) files: trace.log messages: 216459 nosy: mkolman priority: normal severity: normal status: open title: Standard library trace module crashes with exception type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file34908/trace.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 14:57:29 2014 From: report at bugs.python.org (Eric Snow) Date: Wed, 16 Apr 2014 12:57:29 +0000 Subject: [issue21211] pkgutil.find_loader() raises ImportError instead of returning None In-Reply-To: <1397440098.66.0.10150246835.issue21211@psf.upfronthosting.co.za> Message-ID: <1397653049.6.0.543936096554.issue21211@psf.upfronthosting.co.za> Eric Snow added the comment: Ah, it's ValueError rather than ImportError that causes the problem. Regardless, handling it would be necessary. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 15:11:08 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 16 Apr 2014 13:11:08 +0000 Subject: [issue6490] os.popen documentation is probably wrong In-Reply-To: <1247646939.28.0.091306950041.issue6490@psf.upfronthosting.co.za> Message-ID: <3g83pz21Fpz7Ljg@mail.python.org> Roundup Robot added the comment: New changeset 3417a95df7e2 by Andrew Kuchling in branch 'default': #6490: Expand documentation for os.popen(). http://hg.python.org/cpython/rev/3417a95df7e2 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 15:11:39 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 16 Apr 2014 13:11:39 +0000 Subject: [issue6490] os.popen documentation is probably wrong In-Reply-To: <1247646939.28.0.091306950041.issue6490@psf.upfronthosting.co.za> Message-ID: <1397653899.23.0.272625199368.issue6490@psf.upfronthosting.co.za> A.M. Kuchling added the comment: Thanks for your patch! ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed title: os.popen documentation is probably wrong -> os.popen documentation is probably wrong _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 15:20:59 2014 From: report at bugs.python.org (Wolfgang Maier) Date: Wed, 16 Apr 2014 13:20:59 +0000 Subject: [issue21234] __contains__ and friends should check "is" for all elements first In-Reply-To: <1397567063.59.0.649029276797.issue21234@psf.upfronthosting.co.za> Message-ID: <1397654459.17.0.288434153166.issue21234@psf.upfronthosting.co.za> Wolfgang Maier added the comment: that clarifies things, thanks. I would still not usually go that way though as it means defining __ne__ with no accompanying __eq__, which means that, in a simple case, you can't use == on instances of your class and, in the case that your class inherits __eq__ from a parent, that == and != give inconsistent answers. A much simpler solution is to not use the x in y idiom if you know it is slowed down by expensive equality checks in the elements of y and you're only interested in the identity check. Simply replace it with any(element is x for element in y) , which will run at decent speed. A quick illustration: class myObj(object): def __eq__(self, other): for i in range(10000): pass # simulate an expensive check return False l=[myObj() for x in range(10000)] now compare: >>> 1 in m # slowed down by myObj.__eq__ False >>> any(e is 1 for e in m) # identity checks only False => no class-level hacking required, but still a good performance gain. Of course, if you really need bets performance with identity *and* equality checks, then your solution may make sense, but that looks like a pretty special requirement. (and even then I would replace the ugly not all(map(ne, repeat(obj), container)) # requires 2 imports to be so hard to read with: not all(element != obj for element in container) ) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 15:26:08 2014 From: report at bugs.python.org (Wolfgang Maier) Date: Wed, 16 Apr 2014 13:26:08 +0000 Subject: [issue21234] __contains__ and friends should check "is" for all elements first In-Reply-To: <1397567063.59.0.649029276797.issue21234@psf.upfronthosting.co.za> Message-ID: <1397654768.05.0.42122341061.issue21234@psf.upfronthosting.co.za> Wolfgang Maier added the comment: > l=[myObj() for x in range(10000)] > > now compare: > > >>> 1 in m # slowed down by myObj.__eq__ > False > > >>> any(e is 1 for e in m) # identity checks only > False oops, sorry for the inconsistency here. the first line should read: m = [myObj() for x in range(10000)] for this to work, of course. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 15:26:40 2014 From: report at bugs.python.org (Christian Theune) Date: Wed, 16 Apr 2014 13:26:40 +0000 Subject: [issue15002] urllib2 does not download 4 MB file completely using ftp In-Reply-To: <1338840881.84.0.164546182047.issue15002@psf.upfronthosting.co.za> Message-ID: <1397654800.03.0.775578620266.issue15002@psf.upfronthosting.co.za> Christian Theune added the comment: Looking into this. It seems that it doesn't happen for all servers, I can download large files reliably from other sources. I'll make another wireshark recording to get more details for me to analyze. ---------- nosy: +ctheune _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 15:28:49 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Wed, 16 Apr 2014 13:28:49 +0000 Subject: [issue15002] urllib2 does not download 4 MB file completely using ftp In-Reply-To: <1338840881.84.0.164546182047.issue15002@psf.upfronthosting.co.za> Message-ID: <1397654929.83.0.873825515658.issue15002@psf.upfronthosting.co.za> Senthil Kumaran added the comment: > I'll make another wireshark recording to get more details for me to analyze. Thank you! That will be useful. Please test it against 3.x version as it has seen cleanups recently. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 15:58:03 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 16 Apr 2014 13:58:03 +0000 Subject: [issue21121] -Werror=declaration-after-statement is added even for extension modules through setup.py In-Reply-To: <1396348933.92.0.0275278232722.issue21121@psf.upfronthosting.co.za> Message-ID: <1397656683.92.0.467675750145.issue21121@psf.upfronthosting.co.za> Stefan Krah added the comment: Here is a patch. I do not see a really nice way to deal with the problem. The cleanest way I found was to introduce a new Makefile variable CFLAGS_NODIST and use that in the interpreter and stdlib build. ---------- keywords: +patch nosy: +skrah Added file: http://bugs.python.org/file34909/issue21121.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 16:06:53 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 16 Apr 2014 14:06:53 +0000 Subject: [issue21167] float('nan') returns 0.0 on Python compiled with icc In-Reply-To: <1396864952.24.0.891595123462.issue21167@psf.upfronthosting.co.za> Message-ID: <1397657213.48.0.158026878389.issue21167@psf.upfronthosting.co.za> Stefan Krah added the comment: Mark, if you agree that "fp-model strict" should not show up in the distutils CFLAGS once Python is installed, the issue now depends on #21121. ---------- dependencies: +-Werror=declaration-after-statement is added even for extension modules through setup.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 16:07:27 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 16 Apr 2014 14:07:27 +0000 Subject: [issue12916] Add inspect.splitdoc In-Reply-To: <1315326747.38.0.43030903994.issue12916@psf.upfronthosting.co.za> Message-ID: <1397657247.72.0.831338599096.issue12916@psf.upfronthosting.co.za> R. David Murray added the comment: Well, perhaps inspect needs a get_doc_synopsis method :) Actually, I'm not sure that should be a smiley. I don't really have a strong opinion on this myself (say I'm +0 for inspect), so I asked a couple other core devs here at the sprint (Eric Smith and Eric Snow), and they both thought it should be in inspect rather than pydoc. (Eric's Snow reason is that pydoc is not really a user facing library (actually what he said is "it's a mess"), and both thought it was more appropriate for inspect anyway). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 16:11:08 2014 From: report at bugs.python.org (Eric Snow) Date: Wed, 16 Apr 2014 14:11:08 +0000 Subject: [issue12916] Add inspect.splitdoc In-Reply-To: <1315326747.38.0.43030903994.issue12916@psf.upfronthosting.co.za> Message-ID: <1397657468.0.0.468550189105.issue12916@psf.upfronthosting.co.za> Eric Snow added the comment: I agree with ?ric that exposing splidoc publicly in the inspect module is the right thing. inspect already has other similar functions. If it doesn't land in inspect then the only other place that makes real sense to me would be a new module (docstring?). However, that seems like overkill to me. Furthermore, pydoc doesn't seem like a good place to expose the function (or perhaps any function ). It isn't a module relating explicitly to docstrings so much as to exposing API documentation. The use of splitdoc there is an implementation detail while splitdoc itself is generally useful. That said, I would still expect splitdoc to be exposed in pydoc for backward compatibility (via "from inspect import splitdoc"). ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 16:19:40 2014 From: report at bugs.python.org (Caelyn McAulay) Date: Wed, 16 Apr 2014 14:19:40 +0000 Subject: [issue12523] 'str' object has no attribute 'more' [/usr/lib/python3.2/asynchat.py|initiate_send|245] In-Reply-To: <1310256264.97.0.142665013721.issue12523@psf.upfronthosting.co.za> Message-ID: <1397657980.7.0.409218844462.issue12523@psf.upfronthosting.co.za> Caelyn McAulay added the comment: Here is a small script that runs fine under 2.7 but demonstrates the error when run at 3.5. If, at all the points annotated with '#not bytes :-(', the unicode strings are replaced with bytes objects, the example then successfully runs at 3.5. ---------- nosy: +math_foo Added file: http://bugs.python.org/file34910/asynchat_example.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 16:22:37 2014 From: report at bugs.python.org (Christian Theune) Date: Wed, 16 Apr 2014 14:22:37 +0000 Subject: [issue15002] urllib2 does not download 4 MB file completely using ftp In-Reply-To: <1338840881.84.0.164546182047.issue15002@psf.upfronthosting.co.za> Message-ID: <1397658157.33.0.00832702901333.issue15002@psf.upfronthosting.co.za> Christian Theune added the comment: This is actually the same problem as #18879. Changing the sample to keep a reference to the addinfourl object avoids this issue. This is even worse than #18879 in the sense that the error goes undetected and just leaves you with partial data. Looking at the solution in #18879 I think we can reuse that, maybe even better by refactoring that to a common file proxy object. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 16:24:28 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 16 Apr 2014 14:24:28 +0000 Subject: [issue21015] support SSL_CTX_set_ecdh_auto on newer OpenSSLs In-Reply-To: <1397642828.18.0.568697336604.issue21015@psf.upfronthosting.co.za> Message-ID: <1397658264.2368.0.camel@fsol> Antoine Pitrou added the comment: > In case anyone wonders why the FreeBSD bot works again: I've > installed OpenSSL from source. Did you install the same version? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 16:28:31 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 16 Apr 2014 14:28:31 +0000 Subject: [issue21015] support SSL_CTX_set_ecdh_auto on newer OpenSSLs In-Reply-To: <1397658264.2368.0.camel@fsol> Message-ID: <20140416142830.GA32715@sleipnir.bytereef.org> Stefan Krah added the comment: Antoine Pitrou wrote: > Did you install the same version? No, I used the latest version + FIPS. Since FreeBSD 9.0 is EOL, I did not feel like investigating too much. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 16:49:04 2014 From: report at bugs.python.org (ddvento@ucar.edu) Date: Wed, 16 Apr 2014 14:49:04 +0000 Subject: [issue21246] test_ssl handshake failure In-Reply-To: <1397616119.68.0.986294385737.issue21246@psf.upfronthosting.co.za> Message-ID: <534E9863.8070002@ucar.edu> ddvento at ucar.edu added the comment: Despite this being Red Hat, this is not at all the case! OpenSSL 1.0.1f has been released on Jan 6th, 2014 at 15:39:19 -- see https://www.openssl.org/source/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 16:59:50 2014 From: report at bugs.python.org (Wolfgang Maier) Date: Wed, 16 Apr 2014 14:59:50 +0000 Subject: [issue21121] -Werror=declaration-after-statement is added even for extension modules through setup.py In-Reply-To: <1396348933.92.0.0275278232722.issue21121@psf.upfronthosting.co.za> Message-ID: <1397660390.28.0.36710346621.issue21121@psf.upfronthosting.co.za> Wolfgang Maier added the comment: I ran into this issue right after 3.4 got released. I solved it by adding extra_compile_args=["-Wno-error=declaration-after-statement"] as an argument to the Extension() call in the package's setup.py . ---------- nosy: +wolma _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 17:15:06 2014 From: report at bugs.python.org (ddvento@ucar.edu) Date: Wed, 16 Apr 2014 15:15:06 +0000 Subject: [issue21246] test_ssl handshake failure In-Reply-To: <534E9863.8070002@ucar.edu> Message-ID: <534E9E7D.3050203@ucar.edu> ddvento at ucar.edu added the comment: Just to make sure I'm using the right version: Python 2.7.6 (default, Apr 14 2014, 15:12:21) [GCC 4.8.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import ssl >>> ssl.OPENSSL_VERSION 'OpenSSL 1.0.1f 6 Jan 2014' >>> On 04/16/2014 08:49 AM, Davide Del Vento wrote: > > ddvento at ucar.edu added the comment: > > Despite this being Red Hat, this is not at all the case! > > OpenSSL 1.0.1f has been released on Jan 6th, 2014 at 15:39:19 -- see > https://www.openssl.org/source/ > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 17:20:40 2014 From: report at bugs.python.org (Martin Dengler) Date: Wed, 16 Apr 2014 15:20:40 +0000 Subject: [issue15414] os.path.join behavior on Windows (ntpath.join) is unexpected and not well documented In-Reply-To: <1342903268.21.0.193498975528.issue15414@psf.upfronthosting.co.za> Message-ID: <1397661640.01.0.0788809989932.issue15414@psf.upfronthosting.co.za> Changes by Martin Dengler : ---------- nosy: +mdengler _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 17:20:58 2014 From: report at bugs.python.org (Martin Dengler) Date: Wed, 16 Apr 2014 15:20:58 +0000 Subject: [issue1669539] Improve Windows os.path.join (ntpath.join) "smart" joining Message-ID: <1397661658.76.0.44224823089.issue1669539@psf.upfronthosting.co.za> Changes by Martin Dengler : ---------- nosy: +mdengler _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 17:34:14 2014 From: report at bugs.python.org (Alex Gaynor) Date: Wed, 16 Apr 2014 15:34:14 +0000 Subject: [issue21252] Lib/asyncio/events.py has tons of docstrings which are just "XXX" Message-ID: <1397662454.57.0.604020798852.issue21252@psf.upfronthosting.co.za> New submission from Alex Gaynor: It would be nice if these said something useful. (http://hg.python.org/cpython/file/default/Lib/asyncio/events.py) ---------- components: Library (Lib) messages: 216478 nosy: alex priority: normal severity: normal status: open title: Lib/asyncio/events.py has tons of docstrings which are just "XXX" versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 17:54:46 2014 From: report at bugs.python.org (Nina Zakharenko) Date: Wed, 16 Apr 2014 15:54:46 +0000 Subject: [issue21253] Difflib Message-ID: <1397663686.19.0.71446048811.issue21253@psf.upfronthosting.co.za> New submission from Nina Zakharenko: When difflib.compare() is used on two moderately large sequences with little or no common elements, a RuntimeError: maximum recursion depth exceeded occurs. This error became apparent when testing another bug (see: issue 19217) in the AssertEquals() method of the unit test library. A sample program to reproduce this issue in 3.4 is attached. To repo in 2.7 remove the list() wrapper from the range call. ---------- components: Library (Lib) files: diff_bug34.py messages: 216479 nosy: gregory.p.smith, nnja, r.david.murray priority: normal severity: normal status: open title: Difflib type: crash versions: Python 2.7, Python 3.4 Added file: http://bugs.python.org/file34911/diff_bug34.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 17:55:44 2014 From: report at bugs.python.org (Nina Zakharenko) Date: Wed, 16 Apr 2014 15:55:44 +0000 Subject: [issue21253] Difflib.compare() crashes when sequences contain little or no common elements In-Reply-To: <1397663686.19.0.71446048811.issue21253@psf.upfronthosting.co.za> Message-ID: <1397663744.22.0.0474933695767.issue21253@psf.upfronthosting.co.za> Changes by Nina Zakharenko : ---------- title: Difflib -> Difflib.compare() crashes when sequences contain little or no common elements _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 17:57:05 2014 From: report at bugs.python.org (Nina Zakharenko) Date: Wed, 16 Apr 2014 15:57:05 +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: <1397663825.68.0.736116274224.issue19217@psf.upfronthosting.co.za> Nina Zakharenko added the comment: The cause of this has been identified as a bug in libdiff.compare(). See issue 21253 for more information. ---------- nosy: +nnja _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 18:00:43 2014 From: report at bugs.python.org (Kushal Das) Date: Wed, 16 Apr 2014 16:00:43 +0000 Subject: [issue21238] unittest.mock.Mock should not allow you to use non-existent assert methods In-Reply-To: <1397577078.96.0.678735725627.issue21238@psf.upfronthosting.co.za> Message-ID: <1397664043.77.0.431552829601.issue21238@psf.upfronthosting.co.za> Kushal Das added the comment: Patch with docs and test changes. ---------- keywords: +patch Added file: http://bugs.python.org/file34912/issue21238.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 18:01:51 2014 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 16 Apr 2014 16:01:51 +0000 Subject: [issue21252] Lib/asyncio/events.py has tons of docstrings which are just "XXX" In-Reply-To: <1397662454.57.0.604020798852.issue21252@psf.upfronthosting.co.za> Message-ID: <1397664111.31.0.0790956311327.issue21252@psf.upfronthosting.co.za> Yury Selivanov added the comment: I had plans to copy some documentation from python docs to asyncio docstrings. I'll try to do this sometime this week. Thanks for reminding us about the issue! ---------- assignee: -> yselivanov nosy: +gvanrossum, haypo, yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 18:04:23 2014 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 16 Apr 2014 16:04:23 +0000 Subject: [issue21252] Lib/asyncio/events.py has tons of docstrings which are just "XXX" In-Reply-To: <1397664111.31.0.0790956311327.issue21252@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: My bad. But I think docstrings should NOT be just copies of the separate docs. On Apr 16, 2014 9:01 AM, "Yury Selivanov" wrote: > > Yury Selivanov added the comment: > > I had plans to copy some documentation from python docs to asyncio > docstrings. I'll try to do this sometime this week. Thanks for reminding us > about the issue! > > ---------- > assignee: -> yselivanov > nosy: +gvanrossum, haypo, yselivanov > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 18:06:57 2014 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 16 Apr 2014 16:06:57 +0000 Subject: [issue21252] Lib/asyncio/events.py has tons of docstrings which are just "XXX" In-Reply-To: <1397662454.57.0.604020798852.issue21252@psf.upfronthosting.co.za> Message-ID: <1397664417.61.0.915281937605.issue21252@psf.upfronthosting.co.za> Yury Selivanov added the comment: > My bad. But I think docstrings should NOT be just copies of the separate docs. I agree. I didn't want to blindly copy them, but rather use existing documentation as guidance & baseline. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 18:08:52 2014 From: report at bugs.python.org (Caelyn McAulay) Date: Wed, 16 Apr 2014 16:08:52 +0000 Subject: [issue12523] 'str' object has no attribute 'more' [/usr/lib/python3.2/asynchat.py|initiate_send|245] In-Reply-To: <1310256264.97.0.142665013721.issue12523@psf.upfronthosting.co.za> Message-ID: <1397664532.6.0.672411015786.issue12523@psf.upfronthosting.co.za> Caelyn McAulay added the comment: I was unable to locate a point in the code where we could be certain that the error was ultimately caused by trying to use (unicode) strings instead of bytes object. The patch adds a logging statement suggesting what the trouble is when the error is (probably) encountered. Someone with more experience than me will need to make the call about whether this is a useful addition or not. ---------- keywords: +patch Added file: http://bugs.python.org/file34913/issue12523.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 18:09:59 2014 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 16 Apr 2014 16:09:59 +0000 Subject: [issue12916] Add inspect.splitdoc In-Reply-To: <1315326747.38.0.43030903994.issue12916@psf.upfronthosting.co.za> Message-ID: <1397664599.59.0.724041479057.issue12916@psf.upfronthosting.co.za> Yury Selivanov added the comment: OK, since it's two-and-a-half votes against one, let's do this. I'll do the final review of the patch and commit it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 18:15:17 2014 From: report at bugs.python.org (Michael Foord) Date: Wed, 16 Apr 2014 16:15:17 +0000 Subject: [issue21254] PropertyMock refuses to raise AttributeErrror as a side effect Message-ID: <1397664917.5.0.84660783066.issue21254@psf.upfronthosting.co.za> New submission from Michael Foord: What steps will reproduce the problem? >>> import mock >>> a_mock = mock.MagicMock() >>> no_attribute = mock.PropertyMock(side_effect=AttributeError) >>> type(a_mock).property = no_attribute What is the expected output? What do you see instead? I would expect the above to raise an AttributeError. Instead it returns a MagicMock instance. >>> a_mock.property I would expect it to have the same effect as calling a PropertyMock with any other exception as a side effect: >>> mock_value_error = mock.PropertyMock(side_effect=ValueError) >>> type(a_mock).other_property = mock_value_error >>> a_mock.other_property Traceback (most recent call last): File "", line 1, in File "/home/ahammel/bin/python/mock-1.0.1-py2.6.egg/mock.py", line 2365, in __get__ return self() File "/home/ahammel/bin/python/mock-1.0.1-py2.6.egg/mock.py", line 955, in __call__ return _mock_self._mock_call(*args, **kwargs) File "/home/ahammel/bin/python/mock-1.0.1-py2.6.egg/mock.py", line 1010, in _mock_call raise effect ValueError What version of the product are you using? On what operating system? Using version mock-1.0.1-py2.6 on CentOS 6.4 Please provide any additional information below. PropertyMock objects apparently won't raise sublcasses of AttributeError either: >>> class MockAttributeError(AttributeError): pass ... >>> no_attr = mock.PropertyMock(side_effect=MockAttributeError) >>> type(a_mock).property = no_attr >>> a_mock.property Works fine for subclasses of other Exceptions: >>> class MockKeyError(KeyError): pass ... >>> no_key = mock.PropertyMock(side_effect=MockKeyError) >>> type(a_mock).property = no_key >>> a_mock.property Traceback (most recent call last): File "", line 1, in File "/home/ahammel/bin/python/mock-1.0.1-py2.6.egg/mock.py", line 2365, in __get__ return self() File "/home/ahammel/bin/python/mock-1.0.1-py2.6.egg/mock.py", line 955, in __call__ return _mock_self._mock_call(*args, **kwargs) File "/home/ahammel/bin/python/mock-1.0.1-py2.6.egg/mock.py", line 1010, in _mock_call raise effect __main__.MockKeyError ---------- assignee: michael.foord keywords: easy messages: 216487 nosy: kushal.das, michael.foord priority: normal severity: normal stage: needs patch status: open title: PropertyMock refuses to raise AttributeErrror as a side effect type: behavior versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 18:19:15 2014 From: report at bugs.python.org (Michael Foord) Date: Wed, 16 Apr 2014 16:19:15 +0000 Subject: [issue21255] Attaching a PropertyMock records calls Message-ID: <1397665155.65.0.579203534798.issue21255@psf.upfronthosting.co.za> New submission from Michael Foord: What steps will reproduce the problem? >>> foo = Mock(name='foo') >>> prop = PropertyMock(name='prop') >>> type(foo).prop = prop >>> foo.attach_mock(prop, 'prop') >>> foo.mock_calls [call.prop()] Expected: >>> foo.mock_calls [] What version of the product are you using? On what operating system? % pip freeze | grep mock mock==1.0.1 OS X 10.8.4 Please provide any additional information below. It would be even cooler if attaching a property mock made calls to the property appear in the mock_calls for the hosting mock without having to attach it, the way it does with a non-property method :) I use mock every day now and am firmly of the opinion it is far, far more awesome than sliced bread. Thanks for making it available to the Python community :) ---------- assignee: michael.foord components: Library (Lib) messages: 216488 nosy: kushal.das, michael.foord priority: normal severity: normal stage: needs patch status: open title: Attaching a PropertyMock records calls type: behavior versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 18:29:30 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 16 Apr 2014 16:29:30 +0000 Subject: [issue5420] Queue deprecation warning patch In-Reply-To: <1236218557.32.0.700265695834.issue5420@psf.upfronthosting.co.za> Message-ID: <1397665770.48.0.538441020198.issue5420@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Martin von L?wis successfully lobbied to keep these methods. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 18:34:08 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 16 Apr 2014 16:34:08 +0000 Subject: [issue21015] support SSL_CTX_set_ecdh_auto on newer OpenSSLs In-Reply-To: <1395455671.92.0.144736574461.issue21015@psf.upfronthosting.co.za> Message-ID: <3g88KC1fPwz7LkR@mail.python.org> Roundup Robot added the comment: New changeset d6501421b86b by Antoine Pitrou in branch '3.4': Try to fix buildbot failures on old OpenSSLs (< 1.0.0) - followup to issue #21015 http://hg.python.org/cpython/rev/d6501421b86b New changeset 1305410bff2d by Antoine Pitrou in branch 'default': Try to fix buildbot failures on old OpenSSLs (< 1.0.0) - followup to issue #21015 http://hg.python.org/cpython/rev/1305410bff2d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 18:34:24 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 16 Apr 2014 16:34:24 +0000 Subject: [issue21234] __contains__ and friends should check "is" for all elements first In-Reply-To: <1397567063.59.0.649029276797.issue21234@psf.upfronthosting.co.za> Message-ID: <1397666064.2.0.204832202367.issue21234@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 18:37:06 2014 From: report at bugs.python.org (Michael Foord) Date: Wed, 16 Apr 2014 16:37:06 +0000 Subject: [issue21256] Sort keyword arguments in mock _format_call_signature Message-ID: <1397666226.17.0.060483995874.issue21256@psf.upfronthosting.co.za> New submission from Michael Foord: Printing call args produces non-deterministic results, making them more or less useless in doctests. kwargs_string = ', '.join([ '%s=%r' % (key, value) for key, value in kwargs.items() ]) should be: kwargs_string = ', '.join([ '%s=%r' % (key, value) for key, value in sorted(kwargs.items()) ]) ---------- assignee: michael.foord keywords: easy messages: 216491 nosy: kushal.das, michael.foord priority: normal severity: normal stage: needs patch status: open title: Sort keyword arguments in mock _format_call_signature type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 18:38:51 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 16 Apr 2014 16:38:51 +0000 Subject: [issue21227] Decimal class error messages for integer division aren't good In-Reply-To: <1397520159.39.0.440264883295.issue21227@psf.upfronthosting.co.za> Message-ID: <1397666331.08.0.987567264205.issue21227@psf.upfronthosting.co.za> Stefan Krah added the comment: It is hard to get fine grained error messages in _decimal, since the errors come from libmpdec. A clean solution would require changes to libmpdec, and I'm reluctant to do that right now. It is certainly possible to document DivisionImpossible etc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 18:41:09 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 16 Apr 2014 16:41:09 +0000 Subject: [issue21015] support SSL_CTX_set_ecdh_auto on newer OpenSSLs In-Reply-To: <1395455671.92.0.144736574461.issue21015@psf.upfronthosting.co.za> Message-ID: <1397666469.47.0.276231910317.issue21015@psf.upfronthosting.co.za> Antoine Pitrou added the comment: So, I think I've found the issue. On OpenSSL < 1.0.0, the ECDH ciphers exist but the "ECDH" cipher alias doesn't. I've committed a patch which should fix the issue, although the set_ciphers() call may be entirely useless given our current default cipher list. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 18:44:59 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Wed, 16 Apr 2014 16:44:59 +0000 Subject: [issue21257] Document parse_headers function of http.client Message-ID: <1397666699.47.0.0992171618243.issue21257@psf.upfronthosting.co.za> New submission from Senthil Kumaran: It is undocumented. While fixing a doc issue issue18229 for http.server I noticed that I referenced that function and when I looked up for the documentation, it was lacking. ---------- assignee: orsenthil messages: 216494 nosy: orsenthil priority: normal severity: normal status: open title: Document parse_headers function of http.client type: behavior versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 18:47:48 2014 From: report at bugs.python.org (Ned Deily) Date: Wed, 16 Apr 2014 16:47:48 +0000 Subject: [issue21015] support SSL_CTX_set_ecdh_auto on newer OpenSSLs In-Reply-To: <1395455671.92.0.144736574461.issue21015@psf.upfronthosting.co.za> Message-ID: <1397666868.93.0.532157283789.issue21015@psf.upfronthosting.co.za> Ned Deily added the comment: That does indeed make the test now pass on OS X 10.9: test_default_ecdh_curve (test.test_ssl.ThreadedTests) ... server: new connection from ('127.0.0.1', 60758) server: connection cipher is now ('AECDH-AES256-SHA', 'TLSv1/SSLv3', 256) server: selected protocol is now None ok Thsnks, Antoine! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 18:48:14 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 16 Apr 2014 16:48:14 +0000 Subject: [issue21227] Decimal class error messages for integer division aren't good In-Reply-To: <1397520159.39.0.440264883295.issue21227@psf.upfronthosting.co.za> Message-ID: <1397666894.57.0.3999180999.issue21227@psf.upfronthosting.co.za> Stefan Krah added the comment: Meanwhile, the pure Python decimal versions prior to Python 3.2 have better error messages. Right now in Python 3.3+ it is hard to import the Python version without going into contortions, but that may be fixed in #19232. ---------- dependencies: +Speed up _decimal import _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 18:50:05 2014 From: report at bugs.python.org (Adnan Umer) Date: Wed, 16 Apr 2014 16:50:05 +0000 Subject: [issue21192] Idle: Print filename when running a file from editor In-Reply-To: <1397078686.2.0.0309283772804.issue21192@psf.upfronthosting.co.za> Message-ID: <1397667005.87.0.0595828877667.issue21192@psf.upfronthosting.co.za> Adnan Umer added the comment: I tried to replace RESTART by doing these little changing # PyShell.Py class ModifiedInterpreter(InteractiveInterpreter): def restart_subprocess(self, with_cwd=False, with_msg=True): ... if with_msg: halfbar = ((int(console.width) - 16) // 2) * '=' console.write(halfbar + ' RESTART ' + halfbar) def runcode(self, code): with_msg = True if code.co_filename[0] != '<': self.tkconsole.write('Executing ' + code.co_filename + '\n') with_msg = False if self.tkconsole.executing: self.interp.restart_subprocess(with_msg) # ScriptBinding.Py class ScriptBinding: def _run_module_event(self, event): filename = self.getfilename() if not filename: return 'break' code = self.checksyntax(filename) if not code: return 'break' if not self.tabnanny(filename): return 'break' interp = self.shell.interp if PyShell.use_subprocess: interp.restart_subprocess(with_cwd=False, with_msg=False) This works fine and replaces RESTART with Execute when file is executed in Python Shell. Also instead of this halfbar = ((int(console.width) - 16) // 2) * '=' console.write(halfbar + ' RESTART ' + halfbar) my recomemdation is: console.write('[SHELL RESTART]') ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 18:50:21 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 16 Apr 2014 16:50:21 +0000 Subject: [issue21246] test_ssl handshake failure In-Reply-To: <1397593348.91.0.829573885546.issue21246@psf.upfronthosting.co.za> Message-ID: <1397667021.19.0.851622865434.issue21246@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This was fixed in #20896 by a certain Benjamin Peterson. ---------- nosy: +pitrou resolution: -> duplicate status: open -> closed superseder: -> test_ssl.test_get_server_certificate() should use PROTOCOL_SSLv23, not PROTOCOL_SSLv3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 18:51:09 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 16 Apr 2014 16:51:09 +0000 Subject: [issue21015] support SSL_CTX_set_ecdh_auto on newer OpenSSLs In-Reply-To: <1395455671.92.0.144736574461.issue21015@psf.upfronthosting.co.za> Message-ID: <1397667069.35.0.624633412924.issue21015@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The buildbots seem happy as well, so I'm closing this. ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 18:54:06 2014 From: report at bugs.python.org (Orion Poplawski) Date: Wed, 16 Apr 2014 16:54:06 +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: <1397667246.86.0.585504731491.issue21247@psf.upfronthosting.co.za> Orion Poplawski added the comment: We have determined that the koji builder is indeed setting the SIGHUP sigaction to SIG_IGN, which the python test is inheriting, and are working on trying to get that fixed. However, it may be worth considering something like https://github.com/pexpect/pexpect/commit/1fbfddf33d196fd1f211fb95efdaa810b8b5dad3 in the python tests to ensure that the test run properly in situations like this (I can imagine someone running them under "nohup"). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 18:57:30 2014 From: report at bugs.python.org (Eric Snow) Date: Wed, 16 Apr 2014 16:57:30 +0000 Subject: [issue21256] Sort keyword arguments in mock _format_call_signature In-Reply-To: <1397666226.17.0.060483995874.issue21256@psf.upfronthosting.co.za> Message-ID: Eric Snow added the comment: Ordered kwargs anyone? :) ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 18:57:34 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 16 Apr 2014 16:57:34 +0000 Subject: [issue20896] test_ssl.test_get_server_certificate() should use PROTOCOL_SSLv23, not PROTOCOL_SSLv3 In-Reply-To: <1394623240.06.0.245086264312.issue20896@psf.upfronthosting.co.za> Message-ID: <3g88rF4k3Bz7Lk7@mail.python.org> Roundup Robot added the comment: New changeset 55f62fa5bebc by Antoine Pitrou in branch 'default': Issue #20896: ssl.get_server_certificate() now uses PROTOCOL_SSLv23, not PROTOCOL_SSLv3, for maximum compatibility. http://hg.python.org/cpython/rev/55f62fa5bebc ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 18:58:56 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 16 Apr 2014 16:58:56 +0000 Subject: [issue20896] test_ssl.test_get_server_certificate() should use PROTOCOL_SSLv23, not PROTOCOL_SSLv3 In-Reply-To: <1394623240.06.0.245086264312.issue20896@psf.upfronthosting.co.za> Message-ID: <1397667536.39.0.010930213462.issue20896@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 19:03:19 2014 From: report at bugs.python.org (Eric Snow) Date: Wed, 16 Apr 2014 17:03:19 +0000 Subject: [issue21254] PropertyMock refuses to raise AttributeErrror as a side effect In-Reply-To: <1397664917.5.0.84660783066.issue21254@psf.upfronthosting.co.za> Message-ID: Eric Snow added the comment: Perhaps related to #1615? ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 19:04:23 2014 From: report at bugs.python.org (Kushal Das) Date: Wed, 16 Apr 2014 17:04:23 +0000 Subject: [issue21256] Sort keyword arguments in mock _format_call_signature In-Reply-To: <1397666226.17.0.060483995874.issue21256@psf.upfronthosting.co.za> Message-ID: <1397667863.51.0.592885405608.issue21256@psf.upfronthosting.co.za> Kushal Das added the comment: Patch uploaded for the same. ---------- keywords: +patch Added file: http://bugs.python.org/file34914/issue21256.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 19:20:33 2014 From: report at bugs.python.org (Christian Theune) Date: Wed, 16 Apr 2014 17:20:33 +0000 Subject: [issue15002] urllib2 does not download 4 MB file completely using ftp In-Reply-To: <1338840881.84.0.164546182047.issue15002@psf.upfronthosting.co.za> Message-ID: <1397668833.6.0.431498306935.issue15002@psf.upfronthosting.co.za> Changes by Christian Theune : ---------- versions: +Python 3.4, Python 3.5 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 19:24:54 2014 From: report at bugs.python.org (paul j3) Date: Wed, 16 Apr 2014 17:24:54 +0000 Subject: [issue17218] support title and description in argparse add_mutually_exclusive_group In-Reply-To: <1361061502.09.0.252084655816.issue17218@psf.upfronthosting.co.za> Message-ID: <1397669094.27.0.069294280446.issue17218@psf.upfronthosting.co.za> paul j3 added the comment: While mutually exclusive groups are a subclass of argument groups, they have very different uses. Argument groups are used solely to organize the help section. Groups are not used at all during parsing. 'parse_args' doesn't even pay attention to those 2 default groups (positionals and optionals). 'parse_args' just uses the master list of actions ('parser._actions'). Mutually exclusive groups are not used at all while formatting the help lines. They are used to format the usage line. They also implement argument tests during parsing. Groups are not set up for nesting. However it is possible to define a mutually exclusive group within an argument group, and effectively give it a title and description. p=argparse.ArgumentParser() g=p.add_argument_group('title') g1=g.add_mutually_exclusive_group() g1.add_argument('--foo') p.print_help() producing: usage: ipython [-h] [--foo FOO] optional arguments: -h, --help show this help message and exit title: --foo FOO Both kinds of groups are a superficial addition to argparse. I argue in http://bugs.python.org/issue11588 that they aren't adequate for handling more complicated groupings (inclusive, nesting, etc). While I'm not convinced the change proposed in this issue is necessary, if we are going implement it, I'd suggest a simple addition to 'add_mutually_exclusive_group()'. If there's a title argument, add this group to '_action_groups' as well as '_mutually_exclusive_groups'. def add_mutually_exclusive_group(self, **kwargs): group = _MutuallyExclusiveGroup(self, **kwargs) self._mutually_exclusive_groups.append(group) try: kwargs.title self._action_groups.append(group) except AttributeError: pass return group This should do the job without adding much complexity. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 19:26:02 2014 From: report at bugs.python.org (Christian Theune) Date: Wed, 16 Apr 2014 17:26:02 +0000 Subject: [issue18879] tempfile.NamedTemporaryFile can close the file too early, if not assigning to a variablwe In-Reply-To: <1377807943.36.0.898364678904.issue18879@psf.upfronthosting.co.za> Message-ID: <1397669162.01.0.79166183953.issue18879@psf.upfronthosting.co.za> Christian Theune added the comment: #15002 uses this patch to fix a similar wrapping problem in urllib. Also, this affects 2.7 as well and #15002 does report the problem for 2.7. I'd like to get this fix backported. Would that be OK? ---------- nosy: +ctheune title: tempfile.NamedTemporaryFile can close the file too early, if not assigning to a variable -> tempfile.NamedTemporaryFile can close the file too early, if not assigning to a variablwe versions: +Python 2.7, Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 19:27:17 2014 From: report at bugs.python.org (Christian Theune) Date: Wed, 16 Apr 2014 17:27:17 +0000 Subject: [issue15002] urllib2 does not download 4 MB file completely using ftp In-Reply-To: <1338840881.84.0.164546182047.issue15002@psf.upfronthosting.co.za> Message-ID: <1397669237.63.0.357136273976.issue15002@psf.upfronthosting.co.za> Christian Theune added the comment: I wasn't able to come up with a good testcase. :( I tried similar approaches as in #18879 but I wasn't able to make them trigger the behaviour as it also seems to be an issue regarding actual network performance ... :/ Backport to 2.7 is currently missing as I'd need #18879 to be backported. If that is OK (I'd like to have this in 2.7) then I'd be happy to port both. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 19:28:05 2014 From: report at bugs.python.org (Christian Theune) Date: Wed, 16 Apr 2014 17:28:05 +0000 Subject: [issue15002] urllib2 does not download 4 MB file completely using ftp In-Reply-To: <1338840881.84.0.164546182047.issue15002@psf.upfronthosting.co.za> Message-ID: <1397669285.65.0.322119544328.issue15002@psf.upfronthosting.co.za> Changes by Christian Theune : ---------- hgrepos: +237 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 19:30:29 2014 From: report at bugs.python.org (Christian Theune) Date: Wed, 16 Apr 2014 17:30:29 +0000 Subject: [issue15002] urllib2 does not download 4 MB file completely using ftp In-Reply-To: <1338840881.84.0.164546182047.issue15002@psf.upfronthosting.co.za> Message-ID: <1397669429.38.0.474161649193.issue15002@psf.upfronthosting.co.za> Changes by Christian Theune : ---------- keywords: +patch Added file: http://bugs.python.org/file34915/d3c6ab639306.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 19:31:43 2014 From: report at bugs.python.org (Thomas Wouters) Date: Wed, 16 Apr 2014 17:31:43 +0000 Subject: [issue15002] urllib2 does not download 4 MB file completely using ftp In-Reply-To: <1338840881.84.0.164546182047.issue15002@psf.upfronthosting.co.za> Message-ID: <1397669503.45.0.0630978672466.issue15002@psf.upfronthosting.co.za> Changes by Thomas Wouters : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 19:34:33 2014 From: report at bugs.python.org (Christian Theune) Date: Wed, 16 Apr 2014 17:34:33 +0000 Subject: [issue15002] urllib2 does not download 4 MB file completely using ftp In-Reply-To: <1338840881.84.0.164546182047.issue15002@psf.upfronthosting.co.za> Message-ID: <1397669673.48.0.0527979248583.issue15002@psf.upfronthosting.co.za> Christian Theune added the comment: Antoine, I'm adding you here as I'm leveraging your patch from #18879. I'd need some feedback about the backport, but this patch should be OK for 3.4. Also, if you had an idea how to test this - I tried, but failed so far. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 19:35:29 2014 From: report at bugs.python.org (Christian Theune) Date: Wed, 16 Apr 2014 17:35:29 +0000 Subject: [issue15002] urllib2 does not download 4 MB file completely using ftp In-Reply-To: <1338840881.84.0.164546182047.issue15002@psf.upfronthosting.co.za> Message-ID: <1397669729.11.0.254152077016.issue15002@psf.upfronthosting.co.za> Christian Theune added the comment: Antoine, could you check my last comment in here? (The nosy list got reset accidentally when I made that comment and got a conflict from the tracker). ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 19:35:52 2014 From: report at bugs.python.org (leewz) Date: Wed, 16 Apr 2014 17:35:52 +0000 Subject: [issue21227] Decimal class error messages for integer division aren't good In-Reply-To: <1397520159.39.0.440264883295.issue21227@psf.upfronthosting.co.za> Message-ID: <1397669752.09.0.1867148711.issue21227@psf.upfronthosting.co.za> leewz added the comment: Fine grained? Do you mean that the error can't be distinguished from other such errors? Or that it's difficult to attach the message to DivisionError? I thought DivisionError was always about precision. I looked up the error in libmpdec: "This occurs and signals invalid-operation if the integer result of a divide-integer or remainder operation had too many digits (would be longer than precision). The result is [0,qNaN]." (http://speleotrove.com/decimal/daexcep.html) Now I'm more confused. Though it mentions precision, it is talking about the *result's* precision being too large (something which shouldn't happen with Python's unbounded ints, right?), rather than being unable to give a sane answer due to not having *enough* digits. That's also what the 2.7 error is: decimal.InvalidOperation: quotient too large in //, % or divmod I'm very much content with documenting it, but if possible, I'd like to understand whether this is an issue to take up with libmpdec. P.S.: As a side-note to others, Python floats allows float%int even when precision isn't high enough, and seems to always returns 0.0 with no warning. So behavior is inconsistent, if that's important to anyone here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 19:39:03 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Wed, 16 Apr 2014 17:39:03 +0000 Subject: [issue15002] urllib2 does not download 4 MB file completely using ftp In-Reply-To: <1338840881.84.0.164546182047.issue15002@psf.upfronthosting.co.za> Message-ID: <1397669943.38.0.385684832825.issue15002@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Christian , with respect to patch, I agree with the logic (using something similar to #18879). Does all current unittests succeed with this? (I suspect not) A unittest for coverage would be helpful. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 19:42:32 2014 From: report at bugs.python.org (Michael Foord) Date: Wed, 16 Apr 2014 17:42:32 +0000 Subject: [issue21256] Sort keyword arguments in mock _format_call_signature In-Reply-To: <1397666226.17.0.060483995874.issue21256@psf.upfronthosting.co.za> Message-ID: <1397670152.54.0.960788875597.issue21256@psf.upfronthosting.co.za> Michael Foord added the comment: Yes to ordered kwargs! I would very much like to be able to order the keyword args in the order they were passed in, information which is currently lost. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 19:42:36 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 16 Apr 2014 17:42:36 +0000 Subject: [issue15002] urllib2 does not download 4 MB file completely using ftp In-Reply-To: <1338840881.84.0.164546182047.issue15002@psf.upfronthosting.co.za> Message-ID: <1397670156.8.0.987870461766.issue15002@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Well, this looks ok on the principle, but I haven't investigated the urllib-specific parts, so I'll let Senthil delve into this :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 19:43:01 2014 From: report at bugs.python.org (Thomas Wouters) Date: Wed, 16 Apr 2014 17:43:01 +0000 Subject: [issue17752] many distutils tests fail when run from the installed location In-Reply-To: <1366109374.8.0.221213577793.issue17752@psf.upfronthosting.co.za> Message-ID: <1397670181.24.0.0694884933072.issue17752@psf.upfronthosting.co.za> Thomas Wouters added the comment: Matthias, I think this is already fixed for Python 3.3 and later (at least.) There may still be problems in 2.7, but I'm not sure if it's worth fixing them there. Can you see if you still have problems, and if so, show us how to reproduce them? (Is it just 'python -m test.regrtest'? Is it just test_distutils or also other tests?) ---------- nosy: +twouters versions: +Python 2.7 -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 19:47:13 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 16 Apr 2014 17:47:13 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: Message-ID: <1397670431.2368.2.camel@fsol> Antoine Pitrou added the comment: On mer., 2014-04-16 at 08:06 +0000, STINNER Victor wrote: > I didn't check which objects use (indirectly) _PyObject_GC_Calloc(). I've checked: lists, tuples, dicts and sets at least seem to use it. Obviously, objects which are not tracked by the GC (such as str and bytes) won't use it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 19:48:13 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 16 Apr 2014 17:48:13 +0000 Subject: [issue17449] dev guide appears not to cover the benchmarking suite In-Reply-To: <1363579697.14.0.518781563777.issue17449@psf.upfronthosting.co.za> Message-ID: <1397670493.93.0.508563983046.issue17449@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Jeff: yes it could :) Do you want to provide a patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 19:49:44 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 16 Apr 2014 17:49:44 +0000 Subject: [issue21068] Make ssl.PROTOCOL_* an enum In-Reply-To: <1395789227.19.0.206884350375.issue21068@psf.upfronthosting.co.za> Message-ID: <1397670584.61.0.852093072208.issue21068@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Anyone else has an opinion on this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 19:50:21 2014 From: report at bugs.python.org (Michael Foord) Date: Wed, 16 Apr 2014 17:50:21 +0000 Subject: [issue21238] unittest.mock.Mock should not allow you to use non-existent assert methods In-Reply-To: <1397577078.96.0.678735725627.issue21238@psf.upfronthosting.co.za> Message-ID: <1397670621.24.0.82070888407.issue21238@psf.upfronthosting.co.za> Michael Foord added the comment: It needs a NEWS entry, but looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 19:50:49 2014 From: report at bugs.python.org (Eric Olson) Date: Wed, 16 Apr 2014 17:50:49 +0000 Subject: [issue2159] dbmmodule inquiry function is performance prohibitive In-Reply-To: <1203640875.82.0.736964888757.issue2159@psf.upfronthosting.co.za> Message-ID: <1397670649.01.0.806301801677.issue2159@psf.upfronthosting.co.za> Eric Olson added the comment: New patch with Pep 7 fix - no c++ // style comments. -Thanks johansen. ---------- Added file: http://bugs.python.org/file34916/dbm_bool_d.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 19:51:16 2014 From: report at bugs.python.org (Steven Hiscocks) Date: Wed, 16 Apr 2014 17:51:16 +0000 Subject: [issue21207] urandom persistent fd - not re-openned after fd close In-Reply-To: <1397316819.31.0.463593532744.issue21207@psf.upfronthosting.co.za> Message-ID: <1397670676.36.0.309741837569.issue21207@psf.upfronthosting.co.za> Steven Hiscocks added the comment: Issue where I hit this is in Fail2Ban: https://github.com/fail2ban/fail2ban/issues/687 Lines of code where this occurs: https://github.com/fail2ban/fail2ban/blob/1c65b946171c3bbc626ddcd9320ea2515018677b/fail2ban/server/server.py#L518-530 There are other examples of closing file descriptors in other packages which create daemon processes, as well as code snippets about, as it is typical behaviour to close files. (http://en.wikipedia.org/wiki/Daemon_%28computing%29#Creation) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 19:55:08 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 16 Apr 2014 17:55:08 +0000 Subject: [issue21227] Decimal class error messages for integer division aren't good In-Reply-To: <1397669752.09.0.1867148711.issue21227@psf.upfronthosting.co.za> Message-ID: <20140416175507.GA21044@sleipnir.bytereef.org> Stefan Krah added the comment: My apologies if that wasn't clear: "fine grained" refers to the exception messages. A function can raise InvalidOperation for different reasons. decimal.py gives a specific error message in each case. libmpdec just signals the standard conforming InvalidOperation. The relevant passage from the standard is here: http://speleotrove.com/decimal/daops.html#refremain "This operation will fail under the same conditions as integer division." decimal.py, decNumber and libmpdec all do the same thing, so there is no libmpdec issue other than that the error *messages* could be improved. I fully understand if you find the behavior surprising (after all the remainder fits in the precision), but as long as we follow the standard we can't change that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 19:56:45 2014 From: report at bugs.python.org (Michael Foord) Date: Wed, 16 Apr 2014 17:56:45 +0000 Subject: [issue21258] Add __iter__ support for mock_open Message-ID: <1397671005.18.0.0743040241878.issue21258@psf.upfronthosting.co.za> New submission from Michael Foord: mock_open returns a mock object suitable for using as a mock file handle. File handles support iteration, so mock_open should support that. If possible it should be integrated with the current read/readlines support (only if possible), so the suggested patch may not be enough. 1. Want to mock this: with open(source_file, 'r') as f: for line_num, line_text in enumerate(f): print line_text 2. Tried this: with patch('__builtin__.open', mock_open(read_data='text'), create=True) as p: 3. enumerate causes a call to __iter__() which is not handled by the mock_open code. What is the expected output? What do you see instead? The __iter__ is allowed on the returned file handle What version of the product are you using? On what operating system? latest Please provide any additional information below. Patch would have mock_open setup handle.__iter__.return_value to a passed in parm or if none, possibly a iter(StringIO(read_data)) on the existing read_data parm to keep the interface unchanged. ---------- assignee: michael.foord components: Library (Lib) files: 213.patch keywords: patch messages: 216522 nosy: kushal.das, michael.foord priority: normal severity: normal stage: patch review status: open title: Add __iter__ support for mock_open type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file34917/213.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 19:56:55 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 16 Apr 2014 17:56:55 +0000 Subject: [issue18229] attribute headers of http.server.BaseHTTPRequestHandler sometimes does not exists In-Reply-To: <1371376761.5.0.41138715811.issue18229@psf.upfronthosting.co.za> Message-ID: <3g8B8k4dDYz7LkZ@mail.python.org> Roundup Robot added the comment: New changeset 104fab0143e9 by Senthil Kumaran in branch '3.4': Address issue 18229 - Explain http.server.BaseHTTPRequestHandler's .headers attribute further. http://hg.python.org/cpython/rev/104fab0143e9 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 19:56:55 2014 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 16 Apr 2014 17:56:55 +0000 Subject: [issue21259] replace "except: pass" by "except Exception: pass" Message-ID: <1397671015.92.0.0555120458036.issue21259@psf.upfronthosting.co.za> New submission from St?phane Wirtel: Hi guys, Via this issue, I will attach a patch where I replace all the "except: pass" in the source code by a clear "except Exception: pass". ---------- components: Library (Lib) messages: 216524 nosy: matrixise priority: normal severity: normal status: open title: replace "except: pass" by "except Exception: pass" versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 19:57:43 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 16 Apr 2014 17:57:43 +0000 Subject: [issue21192] Idle: Print filename when running a file from editor In-Reply-To: <1397078686.2.0.0309283772804.issue21192@psf.upfronthosting.co.za> Message-ID: <1397671063.15.0.546522115122.issue21192@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I took another look and tried the patch and discovered that my comments are partly wrong because restart_shell is called before runcode when runcode is use to run a file. (I am not sure how it is called otherwise with self.tkconsole.executing == True.) This happens in ScriptBinding.ScriptBinding._run_module_event and that is where filename could be added to the restart_shell call. The rest of my comment was about not printing fake prompts that the user can never respond to. In particular, Run F5 is like python -i, and for that the console interpreter does not print a prompt until it is done running the script and ready for user input. C:\Programs\Python34>python -i tem.py start stop >>> ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 19:57:48 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 16 Apr 2014 17:57:48 +0000 Subject: [issue21207] urandom persistent fd - not re-openned after fd close In-Reply-To: <1397316819.31.0.463593532744.issue21207@psf.upfronthosting.co.za> Message-ID: <1397671068.76.0.346403384029.issue21207@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Well, on the one hand this does sound like a valid use case. On the other hand, once the urandom file descriptor is closed by third-party code, it can very well be re-opened to point to another file, and then os.urandom() will start behaving in a very bad way. Here is a possible solution in Python: - when opening the urandom fd for the first time, record its st_ino and st_dev - when calling urandom() a second time, call fstat() on the fd and check the st_ino and st_dev with the known values - if the values have changed (or if fstat() fails with EBADF), open a new fd to /dev/urandom, again ---------- nosy: +neologix type: crash -> behavior versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 19:58:02 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Wed, 16 Apr 2014 17:58:02 +0000 Subject: [issue18229] attribute headers of http.server.BaseHTTPRequestHandler sometimes does not exists In-Reply-To: <1371376761.5.0.41138715811.issue18229@psf.upfronthosting.co.za> Message-ID: <1397671082.0.0.173168470651.issue18229@psf.upfronthosting.co.za> Changes by Senthil Kumaran : ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed versions: +Python 3.5 -Python 2.7, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 19:58:07 2014 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 16 Apr 2014 17:58:07 +0000 Subject: [issue21259] replace "except: pass" by "except Exception: pass" In-Reply-To: <1397671015.92.0.0555120458036.issue21259@psf.upfronthosting.co.za> Message-ID: <1397671087.76.0.975025290244.issue21259@psf.upfronthosting.co.za> St?phane Wirtel added the comment: I attach the patch. Need review. Thanks ---------- keywords: +patch nosy: +haypo Added file: http://bugs.python.org/file34918/issue21259-replace_except_pass.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 20:01:33 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 16 Apr 2014 18:01:33 +0000 Subject: [issue21259] replace "except: pass" by "except Exception: pass" In-Reply-To: <1397671015.92.0.0555120458036.issue21259@psf.upfronthosting.co.za> Message-ID: <1397671293.78.0.752324504393.issue21259@psf.upfronthosting.co.za> Antoine Pitrou added the comment: You shouldn't change the grammar the tests, nor the pybench source. Also, in some places it would probably be interesting to narrow down the exception type more. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 20:01:58 2014 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Wed, 16 Apr 2014 18:01:58 +0000 Subject: [issue21220] Enhance obmalloc allocation strategy In-Reply-To: <1397499786.06.0.606856949694.issue21220@psf.upfronthosting.co.za> Message-ID: <1397671318.76.0.953355488687.issue21220@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Antoine: The location of the arenas when they're individually allocated with mmap does not matter, no, but preferring to keep low address ones reduces vmem fragmentation, since they end up being clustered together in memory. For the usable-arenas list, there is no extra O(n) because they were ordered anyway. the effect of ARENA_STRATEGY is minor, but it helps for it to be consistent with POOL_STRATEGY. The real win however is with POOL_STRATEGY. Fragmentation is dramatically reduced. This is demonstrated with the tools/scripts/memcrunch.py which you can use to experiment with it. Performance e.g. of unittests also goes up. The fact that there is a new O(n) sort operation when a pool becomes 'used' does not seem to matter for that. Victor: I've tested using windows LFH many times before, the python obmalloc generally is much faster than that. Annoying :). It is actually a very good allocator. The innovation here is the "lowest address strategy" which I have never seen before (it might be known, but then I'm not a CS) but is one that I have experimented with for often in the past. It is suprisingly effective. When there is memory churn, memory usage tends to migrate towards low addresses and free up memory. Go ahead, try the scripts and see what happens. The proof is in the pudding :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 20:02:41 2014 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Wed, 16 Apr 2014 18:02:41 +0000 Subject: [issue21220] Enhance obmalloc allocation strategy In-Reply-To: <1397499786.06.0.606856949694.issue21220@psf.upfronthosting.co.za> Message-ID: <1397671361.54.0.166154740019.issue21220@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: sorry, I meant of course "performance of pybench.py goes up" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 20:04:46 2014 From: report at bugs.python.org (leewz) Date: Wed, 16 Apr 2014 18:04:46 +0000 Subject: [issue21227] Decimal class error messages for integer division aren't good In-Reply-To: <1397520159.39.0.440264883295.issue21227@psf.upfronthosting.co.za> Message-ID: <1397671486.29.0.194582292222.issue21227@psf.upfronthosting.co.za> leewz added the comment: Nah. I found it surprising at first, but like I said, it's like the computer is given the first 28 digits of a number and then asked to figure out the 30th digit. What I'm confused about is how it fits the definition of "division impossible" given by libmpdec's docs (about the result size), and whether you're saying it's difficult to translate the `[]` part to an error message. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 20:06:02 2014 From: report at bugs.python.org (ddvento@ucar.edu) Date: Wed, 16 Apr 2014 18:06:02 +0000 Subject: [issue20896] test_ssl.test_get_server_certificate() should use PROTOCOL_SSLv23, not PROTOCOL_SSLv3 In-Reply-To: <1394623240.06.0.245086264312.issue20896@psf.upfronthosting.co.za> Message-ID: <1397671562.49.0.916213715008.issue20896@psf.upfronthosting.co.za> ddvento at ucar.edu added the comment: This bug affected also the other versions I marked. Updating it, so people don't open duplicate bugs as I did with issue #21246 ---------- nosy: +ddvento at ucar.edu versions: +Python 2.7, Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 20:06:08 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 16 Apr 2014 18:06:08 +0000 Subject: [issue21220] Enhance obmalloc allocation strategy In-Reply-To: <1397671361.54.0.166154740019.issue21220@psf.upfronthosting.co.za> Message-ID: <1397671565.2368.3.camel@fsol> Antoine Pitrou added the comment: > sorry, I meant of course "performance of pybench.py goes up" pybench is really a very poor (extremely low-level) benchmark. It would be nice if you could test with the benchmark suite at http://hg.python.org/benchmarks ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 20:06:58 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 16 Apr 2014 18:06:58 +0000 Subject: [issue21238] unittest.mock.Mock should not allow you to use non-existent assert methods In-Reply-To: <1397577078.96.0.678735725627.issue21238@psf.upfronthosting.co.za> Message-ID: <3g8BNK56W6z7LjW@mail.python.org> Roundup Robot added the comment: New changeset e4ee0b15cc4f by Kushal Das in branch 'default': Closes Issue 21238: New keyword argument `unsafe` to Mock. http://hg.python.org/cpython/rev/e4ee0b15cc4f ---------- nosy: +python-dev resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 20:07:32 2014 From: report at bugs.python.org (ddvento@ucar.edu) Date: Wed, 16 Apr 2014 18:07:32 +0000 Subject: [issue21246] test_ssl handshake failure In-Reply-To: <1397667021.19.0.851622865434.issue21246@psf.upfronthosting.co.za> Message-ID: <534EC6E7.9070006@ucar.edu> ddvento at ucar.edu added the comment: Thanks. The reason why I overlook it is that #20896 did not list 2.7 as an affected version. I changed #20896 to prevent other people doing the same mistake ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 20:10:23 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 16 Apr 2014 18:10:23 +0000 Subject: [issue6727] ImportError when package is symlinked on Windows In-Reply-To: <1250608383.93.0.471187637916.issue6727@psf.upfronthosting.co.za> Message-ID: <1397671823.96.0.999271887887.issue6727@psf.upfronthosting.co.za> R. David Murray added the comment: As far as I can tell from the messages, there is nothing left to do here, so I'm closing it. ---------- nosy: +r.david.murray resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 20:11:54 2014 From: report at bugs.python.org (Michael Foord) Date: Wed, 16 Apr 2014 18:11:54 +0000 Subject: [issue21256] Sort keyword arguments in mock _format_call_signature In-Reply-To: <1397666226.17.0.060483995874.issue21256@psf.upfronthosting.co.za> Message-ID: <1397671914.51.0.111366430134.issue21256@psf.upfronthosting.co.za> Michael Foord added the comment: Needs a test. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 20:16:38 2014 From: report at bugs.python.org (Ned Deily) Date: Wed, 16 Apr 2014 18:16:38 +0000 Subject: [issue21250] sqlite3 doesn't have unit tests for 'insert or [algorithm]' functionality. In-Reply-To: <1397634761.6.0.834429340049.issue21250@psf.upfronthosting.co.za> Message-ID: <1397672198.14.0.121442828317.issue21250@psf.upfronthosting.co.za> Ned Deily added the comment: Are you interested in submitting a patch? ---------- nosy: +ghaering, ned.deily stage: -> needs patch versions: -Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 20:16:50 2014 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 16 Apr 2014 18:16:50 +0000 Subject: [issue21260] python malloc mach_vm_map failed Message-ID: <1397672210.34.0.991766687359.issue21260@psf.upfronthosting.co.za> New submission from St?phane Wirtel: Hi all, Sometimes, I get this error on my laptop : OSX 10.9 with Python 3.5 [386/388] test_io python.exe(33496,0x7fff7367d310) malloc: *** mach_vm_map(size=9223372036854779904) failed (error code=3) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug python.exe(33496,0x7fff7367d310) malloc: *** mach_vm_map(size=9223372036854779904) failed (error code=3) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug python.exe(33496,0x7fff7367d310) malloc: *** mach_vm_map(size=9223372036854779904) failed (error code=3) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug [387/388] test_tokenize Stephane ---------- components: Interpreter Core messages: 216539 nosy: matrixise priority: normal severity: normal status: open title: python malloc mach_vm_map failed versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 20:20:19 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 16 Apr 2014 18:20:19 +0000 Subject: [issue20840] AttributeError: 'module' object has no attribute 'ArgumentParser' In-Reply-To: <1393837548.4.0.445191461545.issue20840@psf.upfronthosting.co.za> Message-ID: <1397672419.31.0.580469150543.issue20840@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- resolution: -> works for me stage: -> committed/rejected status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 20:20:58 2014 From: report at bugs.python.org (Ethan Furman) Date: Wed, 16 Apr 2014 18:20:58 +0000 Subject: [issue21068] Make ssl.PROTOCOL_* an enum In-Reply-To: <1395789227.19.0.206884350375.issue21068@psf.upfronthosting.co.za> Message-ID: <1397672458.06.0.742577877056.issue21068@psf.upfronthosting.co.za> Ethan Furman added the comment: Looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 20:21:10 2014 From: report at bugs.python.org (Ned Deily) Date: Wed, 16 Apr 2014 18:21:10 +0000 Subject: [issue21260] python malloc mach_vm_map failed In-Reply-To: <1397672210.34.0.991766687359.issue21260@psf.upfronthosting.co.za> Message-ID: <1397672470.25.0.0839938096337.issue21260@psf.upfronthosting.co.za> Ned Deily added the comment: See Issue5614. That's normal when running the test suite on 64-bit versions on OS X. Unfortunately, we haven't found a way to suppress the messages. ---------- nosy: +ned.deily resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> Malloc errors in test_io _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 20:21:12 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 16 Apr 2014 18:21:12 +0000 Subject: [issue21261] Teach IDLE to Autocomplete dictionary keys Message-ID: <1397672472.64.0.119805531416.issue21261@psf.upfronthosting.co.za> New submission from Raymond Hettinger: IDLE can autocomplete global variable, method names, and filenames. But, it cannot complete dictionary keys. Here's what we want: >>> d = {'long_key': '10, 'short_key': 20} >>> d['lo ---------- components: IDLE messages: 216542 nosy: rhettinger priority: normal severity: normal status: open title: Teach IDLE to Autocomplete dictionary keys type: enhancement versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 20:21:43 2014 From: report at bugs.python.org (Ethan Furman) Date: Wed, 16 Apr 2014 18:21:43 +0000 Subject: [issue20421] expose SSL socket protocol version In-Reply-To: <1390927014.41.0.169425093715.issue20421@psf.upfronthosting.co.za> Message-ID: <1397672503.01.0.489609140707.issue20421@psf.upfronthosting.co.za> Ethan Furman added the comment: Sounds good to me. ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 20:21:49 2014 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Wed, 16 Apr 2014 18:21:49 +0000 Subject: [issue21220] Enhance obmalloc allocation strategy In-Reply-To: <1397499786.06.0.606856949694.issue21220@psf.upfronthosting.co.za> Message-ID: <1397672509.16.0.588629207147.issue21220@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Sure. I'm flying home from PyCon this afternoon. I?ll produce and tabulate data once I'm home on my workstation again. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 20:26:55 2014 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 16 Apr 2014 18:26:55 +0000 Subject: [issue21259] replace "except: pass" by "except Exception: pass" In-Reply-To: <1397671015.92.0.0555120458036.issue21259@psf.upfronthosting.co.za> Message-ID: <1397672815.55.0.896811359664.issue21259@psf.upfronthosting.co.za> St?phane Wirtel added the comment: I disabled the patch for pybench and the grammar. Thanks for your review. ---------- Added file: http://bugs.python.org/file34919/issue21259-replace_except_pass-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 20:30:14 2014 From: report at bugs.python.org (Michael Foord) Date: Wed, 16 Apr 2014 18:30:14 +0000 Subject: [issue21262] assert_not_called method for mocks Message-ID: <1397673013.96.0.498096187317.issue21262@psf.upfronthosting.co.za> New submission from Michael Foord: A shortcut for asserting that the call_count of a mock is 0. ---------- assignee: kushal.das messages: 216546 nosy: kushal.das, michael.foord priority: normal severity: normal stage: needs patch status: open title: assert_not_called method for mocks type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 20:30:26 2014 From: report at bugs.python.org (Michael Foord) Date: Wed, 16 Apr 2014 18:30:26 +0000 Subject: [issue21262] assert_not_called method for mocks In-Reply-To: <1397673013.96.0.498096187317.issue21262@psf.upfronthosting.co.za> Message-ID: <1397673026.65.0.737332957119.issue21262@psf.upfronthosting.co.za> Changes by Michael Foord : ---------- components: +Library (Lib) versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 20:34:31 2014 From: report at bugs.python.org (Tim Golden) Date: Wed, 16 Apr 2014 18:34:31 +0000 Subject: [issue19962] Create a 'python.bat' script to invoke interpreter from source root In-Reply-To: <1386862429.77.0.358851450829.issue19962@psf.upfronthosting.co.za> Message-ID: <1397673271.17.0.790176410618.issue19962@psf.upfronthosting.co.za> Tim Golden added the comment: +1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 20:38:50 2014 From: report at bugs.python.org (Thomas Fenzl) Date: Wed, 16 Apr 2014 18:38:50 +0000 Subject: [issue8690] multiprocessing.dummy.Queue does not expose same interface as multiprocessing.Queue In-Reply-To: <1273603184.02.0.789462329458.issue8690@psf.upfronthosting.co.za> Message-ID: <1397673530.54.0.535312710031.issue8690@psf.upfronthosting.co.za> Thomas Fenzl added the comment: Considering public API elements, there are more inconsistencies. E.g. Pool: 'imap' 'apply' 'join' 'map_async' 'Process' 'terminate' 'close' 'starmap_async' 'starmap' 'apply_async' 'map' 'imap_unordered' : Pool misses some public elements. What level of compatibility would users reasonably expect? Should the methods raise NotImplemented? ---------- nosy: +Thomas Fenzl, sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 20:42:28 2014 From: report at bugs.python.org (Giampaolo Rodola') Date: Wed, 16 Apr 2014 18:42:28 +0000 Subject: [issue12523] 'str' object has no attribute 'more' [/usr/lib/python3.2/asynchat.py|initiate_send|245] In-Reply-To: <1310256264.97.0.142665013721.issue12523@psf.upfronthosting.co.za> Message-ID: <1397673748.09.0.0535724564712.issue12523@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: The part of the code where that is more likely to happen is the push() method. One might also submit a producer (push_with_producer()) erroneously returning strings on more() though; how to properly fix this one is not clear to me because of the bad asynchat design. I'd be for simply raising an exception in push() as in: diff --git a/Lib/asynchat.py b/Lib/asynchat.py --- a/Lib/asynchat.py +++ b/Lib/asynchat.py @@ -181,6 +181,8 @@ self.close() def push (self, data): + if not isinstance(data, bytes): + raise TypeError("data must be a bytes object") sabs = self.ac_out_buffer_size if len(data) > sabs: for i in range(0, len(data), sabs): ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 20:47:11 2014 From: report at bugs.python.org (Matthias Klose) Date: Wed, 16 Apr 2014 18:47:11 +0000 Subject: [issue21249] removing pythonXY.zip from sys.path results in additional test failures In-Reply-To: <1397600181.83.0.758754205227.issue21249@psf.upfronthosting.co.za> Message-ID: <1397674031.86.0.334174342827.issue21249@psf.upfronthosting.co.za> Matthias Klose added the comment: Brett mentioned this optimization might not be worth doing. Exactly one stat call for the python zip file is saved. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 20:50:57 2014 From: report at bugs.python.org (Sam Kimbrel) Date: Wed, 16 Apr 2014 18:50:57 +0000 Subject: [issue21263] test_gdb failures on os x 10.9.2 Message-ID: <1397674257.45.0.239061101467.issue21263@psf.upfronthosting.co.za> New submission from Sam Kimbrel: test_gdb fails under OS X 10.9.2 and gdb 7.6.1 (built with homebrew on Apple LLVM version 5.1 (clang-503.0.40)): FAIL: test_pycfunction (test.test_gdb.PyBtTests) Verify that "py-bt" displays invocations of PyCFunction instances ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/skimbrel/cpython/Lib/test/test_gdb.py", line 789, in test_pycfunction cmds_after_breakpoint=['bt', 'py-bt'], File "/Users/skimbrel/cpython/Lib/test/test_gdb.py", line 182, in get_stack_trace self.assertEqual(unexpected_errlines, []) AssertionError: Lists differ: ['No stack.', "Python Exception No frame is currently selected.: ", - 'Error occurred in Python command: No frame is currently selected.'] ====================================================================== FAIL: test_threads (test.test_gdb.PyBtTests) Verify that "py-bt" indicates threads that are waiting for the GIL ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/skimbrel/cpython/Lib/test/test_gdb.py", line 736, in test_threads self.assertIn('Waiting for the GIL', gdb_output) AssertionError: 'Waiting for the GIL' not found in 'Breakpoint 1 at 0x1001c78f0: file Python/bltinmodule.c, line 991.\n[New Thread 0x170b of process 41733]\n[New Thread 0x1803 of process 41733]\n[New Thread 0x1903 of process 41733]\n[New Thread 0x1a03 of process 41733]\n\nBreakpoint 1, builtin_id (self=, v=42) at Python/bltinmodule.c:991\n991\t return PyLong_FromVoidPtr(v);\n\nThread 5 (Thread 0x1a03 of process 41733):\nTraceback (most recent call first):\n\nThread 4 (Thread 0x1903 of process 41733):\nTraceback (most recent call first):\n\nThread 3 (Thread 0x1803 of process 41733):\nTraceback (most recent call first):\n\nThread 2 (Thread 0x170b of process 41733):\nTraceback (most recent call first):\n\nThread 1 (Thread 0x1503 of process 41733):\nTraceback (most recent call first):\n File "", line 18, in \n' ---------------------------------------------------------------------- Ran 45 tests in 19.277s FAILED (failures=2) ---------- assignee: ronaldoussoren components: Macintosh, Tests messages: 216551 nosy: ronaldoussoren, sam.kimbrel priority: normal severity: normal status: open title: test_gdb failures on os x 10.9.2 versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 20:53:35 2014 From: report at bugs.python.org (Matthias Klose) Date: Wed, 16 Apr 2014 18:53:35 +0000 Subject: [issue17752] many distutils tests fail when run from the installed location In-Reply-To: <1366109374.8.0.221213577793.issue17752@psf.upfronthosting.co.za> Message-ID: <1397674415.2.0.26918040766.issue17752@psf.upfronthosting.co.za> Matthias Klose added the comment: three are still failing with 3.4: cc-4.9.real: error: /tmp/tmpdjxmlia5/xx.cpython-34m.so: No such file or directory gcc-4.9.real: error: /tmp/tmp4zpi6ktg/foo.cpython-34m.so: No such file or directory gcc-4.9.real: error: build/lib.linux-x86_64-3.4/xx.cpython-34m.so: No such file or directory test test_distutils failed -- multiple errors occurred; run in verbose mode for details 1 test failed: test_distutils test_build_ext (distutils.tests.test_build_ext.BuildExtTestCase) test_get_outputs (distutils.tests.test_build_ext.BuildExtTestCase) test_record_extensions (distutils.tests.test_install.InstallTestCase) The reason here is that the xx module is not found (where should it be installed in the installed testsuite?). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 20:59:40 2014 From: report at bugs.python.org (Matthias Klose) Date: Wed, 16 Apr 2014 18:59:40 +0000 Subject: [issue21264] test_compileall fails to build in the installed location Message-ID: <1397674780.07.0.532661626869.issue21264@psf.upfronthosting.co.za> New submission from Matthias Klose: the installation directory is non-writable, and the byte code files don't exist. [1/1] test_compileall test test_compileall failed -- Traceback (most recent call last): File "/usr/lib/python3.4/test/test_compileall.py", line 194, in test_no_args_respects_force_flag self.assertRunOK('-f', PYTHONPATH=self.directory) File "/usr/lib/python3.4/test/test_compileall.py", line 144, in assertRunOK *self._get_run_args(args), **env_vars) File "/usr/lib/python3.4/test/script_helper.py", line 69, in assert_python_ok return _assert_python(True, *args, **env_vars) File "/usr/lib/python3.4/test/script_helper.py", line 55, in _assert_python "stderr follows:\n%s" % (rc, err.decode('ascii', 'ignore'))) AssertionError: Process return code is 1, stderr follows: 1 test failed: test_compileall Re-running failed tests in verbose mode Re-running test 'test_compileall' in verbose mode ====================================================================== FAIL: test_no_args_respects_force_flag (test.test_compileall.CommandLineTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python3.4/test/test_compileall.py", line 194, in test_no_args_respects_force_flag self.assertRunOK('-f', PYTHONPATH=self.directory) File "/usr/lib/python3.4/test/test_compileall.py", line 144, in assertRunOK *self._get_run_args(args), **env_vars) File "/usr/lib/python3.4/test/script_helper.py", line 69, in assert_python_ok return _assert_python(True, *args, **env_vars) File "/usr/lib/python3.4/test/script_helper.py", line 55, in _assert_python "stderr follows:\n%s" % (rc, err.decode('ascii', 'ignore'))) AssertionError: Process return code is 1, stderr follows: ---------- messages: 216553 nosy: doko priority: normal severity: normal status: open title: test_compileall fails to build in the installed location _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 21:00:12 2014 From: report at bugs.python.org (Matthias Klose) Date: Wed, 16 Apr 2014 19:00:12 +0000 Subject: [issue17750] allow the testsuite to run in the installed location In-Reply-To: <1366108780.66.0.667292537865.issue17750@psf.upfronthosting.co.za> Message-ID: <1397674812.36.0.551649085147.issue17750@psf.upfronthosting.co.za> Changes by Matthias Klose : ---------- dependencies: +test_compileall fails to build in the installed location _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 21:00:24 2014 From: report at bugs.python.org (metagriffin) Date: Wed, 16 Apr 2014 19:00:24 +0000 Subject: [issue21265] ConfigParser allows "get(*, raw=True), but no corresponding "set(*, raw=True)" Message-ID: <1397674824.07.0.686320086238.issue21265@psf.upfronthosting.co.za> New submission from metagriffin: the ConfigParser classes allow option values with interpolation syntax violations to be loaded from an INI file, and to be extracted as long as the `raw` parameter is set to True in the get*() methods. the following code demonstrates this asymmetry: ``` python import configparser import io buf = io.StringIO('[time]\nfmt = %H:%M:%S\n') cfg = configparser.SafeConfigParser() cfg.readfp(buf) # prove that "%H:%M:%S" is valid in a SafeConfigParser: assert cfg.get('time', 'fmt', raw=True) == '%H:%M:%S' # but it cannot be set: cfg.set('time', 'fmt', '%I:%M %p') # => raises configparser.InterpolationSyntaxError: '%' must be followed by '%' or '(', found: '%I:%M %p' ``` the intuitive resolution to this asymmetry is to add a `raw` parameter to set(), which would allow: ``` python cfg.set('time', 'fmt', '%I:%M %p', raw=True) assert cfg.get('time', 'fmt', raw=True) == '%I:%M %p' ``` note that this is a new problem to python 3, which added the following lines to the ConfigParser.set() method: ``` python if value: value = self._interpolation.before_set(self, section, option, value) ``` ---------- components: Library (Lib) messages: 216554 nosy: metagriffin priority: normal severity: normal status: open title: ConfigParser allows "get(*, raw=True), but no corresponding "set(*, raw=True)" type: enhancement versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 21:01:26 2014 From: report at bugs.python.org (Berker Peksag) Date: Wed, 16 Apr 2014 19:01:26 +0000 Subject: [issue21240] Add an abstactmethod directive to the Python ReST domain In-Reply-To: <1397577446.45.0.129673687933.issue21240@psf.upfronthosting.co.za> Message-ID: <1397674886.61.0.921722274333.issue21240@psf.upfronthosting.co.za> Berker Peksag added the comment: Here's patch. The new PyAbstractMethod class is basically a subclass of the sphinx.domains.python.PyClassmember class which implements the method, classmethod and staticmethod directives. ---------- keywords: +patch nosy: +berker.peksag stage: -> patch review Added file: http://bugs.python.org/file34920/issue21240.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 21:03:23 2014 From: report at bugs.python.org (Matthias Klose) Date: Wed, 16 Apr 2014 19:03:23 +0000 Subject: [issue21266] test_zipfile fails to run in the installed location Message-ID: <1397675003.86.0.260943331629.issue21266@psf.upfronthosting.co.za> New submission from Matthias Klose: the installation directory is non-writable, and the byte code files don't exist. test_write_filtered_python_package (test.test_zipfile.PyZipFileTests) ... ERROR test_write_pyfile (test.test_zipfile.PyZipFileTests) ... ERROR test_write_with_optimization (test.test_zipfile.PyZipFileTests) ... ERROR ====================================================================== ERROR: test_write_filtered_python_package (test.test_zipfile.PyZipFileTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python3.4/test/test_zipfile.py", line 638, in test_write_filtered_python_package zipfp.writepy(packagedir) File "/usr/lib/python3.4/zipfile.py", line 1628, in writepy basename) File "/usr/lib/python3.4/zipfile.py", line 1705, in _get_codename if _compile(file_py): File "/usr/lib/python3.4/zipfile.py", line 1670, in _compile py_compile.compile(file, doraise=True, optimize=optimize) File "/usr/lib/python3.4/py_compile.py", line 142, in compile importlib._bootstrap._write_atomic(cfile, bytecode, mode) File "", line 106, in _write_atomic PermissionError: [Errno 13] Permission denied: '/usr/lib/python3.4/test/__pycache__/memory_watchdog.cpython-34.pyc.139687366844208' ====================================================================== ERROR: test_write_pyfile (test.test_zipfile.PyZipFileTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python3.4/test/test_zipfile.py", line 599, in test_write_pyfile zipfp.writepy(fn) File "/usr/lib/python3.4/zipfile.py", line 1653, in writepy fname, arcname = self._get_codename(pathname[0:-3], basename) File "/usr/lib/python3.4/zipfile.py", line 1705, in _get_codename if _compile(file_py): File "/usr/lib/python3.4/zipfile.py", line 1670, in _compile py_compile.compile(file, doraise=True, optimize=optimize) File "/usr/lib/python3.4/py_compile.py", line 142, in compile importlib._bootstrap._write_atomic(cfile, bytecode, mode) File "", line 106, in _write_atomic PermissionError: [Errno 13] Permission denied: '/usr/lib/python3.4/test/__pycache__/test_zipfile.cpython-34.pyc.139687366825440' ====================================================================== ERROR: test_write_with_optimization (test.test_zipfile.PyZipFileTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python3.4/test/test_zipfile.py", line 667, in test_write_with_optimization zipfp.writepy(packagedir) File "/usr/lib/python3.4/zipfile.py", line 1607, in writepy fname, arcname = self._get_codename(initname[0:-3], basename) File "/usr/lib/python3.4/zipfile.py", line 1720, in _get_codename if not _compile(file_py, optimize=self._optimize): File "/usr/lib/python3.4/zipfile.py", line 1670, in _compile py_compile.compile(file, doraise=True, optimize=optimize) File "/usr/lib/python3.4/py_compile.py", line 142, in compile importlib._bootstrap._write_atomic(cfile, bytecode, mode) File "", line 106, in _write_atomic PermissionError: [Errno 13] Permission denied: '/usr/lib/python3.4/email/__pycache__/__init__.cpython-34.pyo.139687366825104' ---------- components: Tests messages: 216556 nosy: doko priority: normal severity: normal status: open title: test_zipfile fails to run in the installed location versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 21:03:57 2014 From: report at bugs.python.org (Kushal Das) Date: Wed, 16 Apr 2014 19:03:57 +0000 Subject: [issue21262] assert_not_called method for mocks In-Reply-To: <1397673013.96.0.498096187317.issue21262@psf.upfronthosting.co.za> Message-ID: <1397675037.56.0.198211466085.issue21262@psf.upfronthosting.co.za> Kushal Das added the comment: Patch with required changes. Code, docs, test and Misc/NEWS entry. ---------- keywords: +patch Added file: http://bugs.python.org/file34921/issue21262.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 21:12:57 2014 From: report at bugs.python.org (Matthias Klose) Date: Wed, 16 Apr 2014 19:12:57 +0000 Subject: [issue17750] allow the testsuite to run in the installed location In-Reply-To: <1366108780.66.0.667292537865.issue17750@psf.upfronthosting.co.za> Message-ID: <1397675577.57.0.756444065081.issue17750@psf.upfronthosting.co.za> Changes by Matthias Klose : ---------- dependencies: +test_zipfile fails to run in the installed location _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 21:13:44 2014 From: report at bugs.python.org (metagriffin) Date: Wed, 16 Apr 2014 19:13:44 +0000 Subject: [issue21265] ConfigParser allows "get(*, raw=True), but no corresponding "set(*, raw=True)" In-Reply-To: <1397674824.07.0.686320086238.issue21265@psf.upfronthosting.co.za> Message-ID: <1397675624.61.0.673456879285.issue21265@psf.upfronthosting.co.za> Changes by metagriffin : ---------- keywords: +patch Added file: http://bugs.python.org/file34922/issue-21265.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 21:14:04 2014 From: report at bugs.python.org (Alok Singhal) Date: Wed, 16 Apr 2014 19:14:04 +0000 Subject: [issue6305] islice doesn't accept large stop values In-Reply-To: <1245309263.43.0.625809679675.issue6305@psf.upfronthosting.co.za> Message-ID: <1397675644.87.0.0671158578651.issue6305@psf.upfronthosting.co.za> Alok Singhal added the comment: I started working on this bug as a part of PyCon US 2014 sprints. Should the bugfix include a fast path (basically the current implementation) for when the values involved can fit in an int, and a slow path for larger values? Or should the bugfix just have one path which works for all the cases (using PyObject * for "next", "stop" etc.)? ---------- nosy: +AlokSinghal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 21:15:20 2014 From: report at bugs.python.org (paul j3) Date: Wed, 16 Apr 2014 19:15:20 +0000 Subject: [issue17218] support title and description in argparse add_mutually_exclusive_group In-Reply-To: <1361061502.09.0.252084655816.issue17218@psf.upfronthosting.co.za> Message-ID: <1397675720.22.0.0833451645629.issue17218@psf.upfronthosting.co.za> paul j3 added the comment: Using a mutually_exclusive_group is a little more complicated than I implied in the previous post. p=argparse.ArgumentParser() g=p.add_mutually_exclusive_group() # currently the code objects to 'title' and 'description' keywords g.add_argument('--foo') g.add_argument('--bar') # but a title can be added after creation g.title='test' g.description='description' # now add the group to the list that is used for help formatting p._action_groups.append(g) p.print_help() producing: usage: ipython [-h] [--foo FOO | --bar BAR] optional arguments: -h, --help show this help message and exit --foo FOO --bar BAR test: description --foo FOO --bar BAR Now the arguments appear in both the 'optional arguments' group (a default one), and the new group. That's not what we want. So the mutually_exclusive_group has to be changed so it accepts title and description. And it also has to block the addition of arguments to one of the existing groups. A key difference is in how _add_action is implemented for the 2 group classes: For argument_group: def _add_action(self, action): action = super(_ArgumentGroup, self)._add_action(action) self._group_actions.append(action) return action for mutually exclusive group def _add_action(self, action): ... action = self._container._add_action(action) self._group_actions.append(action) return action The first uses 'super' to add the action to itself. The second adds the action to its 'container'. That difference allows you to add a mutually_exclusive_group to an argument_group (or to another mutually_exclusive_group), but you can't add an argument_group to another argument_group (no nesting). I don't like the idea of using a different _add_action method depending on whether group has a 'title' or not. That's too kludgy. Another possibility is to have 'parser.add_mutually_exclusive_group()' do what I first demonstrated - first create an 'argument_group' with the title, and add the mutually_exclusive_group to that. This is still kludgy, but the change is limited to one function. For demonstration purposes it probably could be implemented in a new function (add_titled_mutually_exclusive_group). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 21:18:53 2014 From: report at bugs.python.org (Caelyn McAulay) Date: Wed, 16 Apr 2014 19:18:53 +0000 Subject: [issue12523] 'str' object has no attribute 'more' [/usr/lib/python3.2/asynchat.py|initiate_send|245] In-Reply-To: <1310256264.97.0.142665013721.issue12523@psf.upfronthosting.co.za> Message-ID: <1397675933.08.0.795639977026.issue12523@psf.upfronthosting.co.za> Caelyn McAulay added the comment: I like that approach decidedly more than my original one. Suggested revision patch attached. The sample script will not produce the following: error: uncaptured python exception, closing channel <__main__.fake_asynchat 127.0.0.1:8000 at 0x7f10a85b4ae8> (:data must be a bytes object [/home/caelyn/CPython/async_chat_error/Lib/asyncore.py|write|91] [/home/caelyn/CPython/async_chat_error/Lib/asyncore.py|handle_write_event|460] [/home/caelyn/CPython/async_chat_error/Lib/asyncore.py|handle_connect_event|448] [asynchat_example.py|handle_connect|16] [/home/caelyn/CPython/async_chat_error/Lib/asynchat.py|push|185]) Which is, I think, is a bit more useful. ---------- Added file: http://bugs.python.org/file34923/issue12523_r2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 21:20:04 2014 From: report at bugs.python.org (Caelyn McAulay) Date: Wed, 16 Apr 2014 19:20:04 +0000 Subject: [issue12523] 'str' object has no attribute 'more' [/usr/lib/python3.2/asynchat.py|initiate_send|245] In-Reply-To: <1310256264.97.0.142665013721.issue12523@psf.upfronthosting.co.za> Message-ID: <1397676004.86.0.868520815261.issue12523@psf.upfronthosting.co.za> Caelyn McAulay added the comment: *will now produce. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 21:39:57 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 16 Apr 2014 19:39:57 +0000 Subject: [issue19232] Speed up _decimal import In-Reply-To: <1381579399.63.0.316110193187.issue19232@psf.upfronthosting.co.za> Message-ID: <1397677197.23.0.608362753403.issue19232@psf.upfronthosting.co.za> Stefan Krah added the comment: I would like to go ahead with this. As Antoine mentioned, most people don't diagnose import problems, especially when they compare Python 2 against Python 3. As it turns out, the slowdown is even significant in a simple tcpserver application that starts a Python script. Another benefit is that it will be possible to import the Python version easily, e.g. to check error messages (currently _decimal justs displays the signal in tracebacks). I've often wanted that myself instead of going through the import_fresh_module() ordeal. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 21:40:03 2014 From: report at bugs.python.org (Nitika Agarwal) Date: Wed, 16 Apr 2014 19:40:03 +0000 Subject: [issue18566] In unittest.TestCase docs for setUp() and tearDown() don't mention AssertionError In-Reply-To: <1374901937.1.0.747872580847.issue18566@psf.upfronthosting.co.za> Message-ID: <1397677203.01.0.597798451277.issue18566@psf.upfronthosting.co.za> Nitika Agarwal added the comment: @Terry J.Reedy Thanks a lot.And yes, I will take care of it next time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 21:45:38 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 16 Apr 2014 19:45:38 +0000 Subject: [issue6305] islice doesn't accept large stop values In-Reply-To: <1245309263.43.0.625809679675.issue6305@psf.upfronthosting.co.za> Message-ID: <1397677538.11.0.155754120285.issue6305@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Yes, you should add a fastpath and a slow path. Take a look at itertools.count() or builtins.enumerate() to see how to do it. This is a bit tricky to switch between modes, so you will need a thorough set of test cases. ---------- versions: +Python 3.5 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 21:46:18 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 16 Apr 2014 19:46:18 +0000 Subject: [issue21227] Decimal class error messages for integer division aren't good In-Reply-To: <1397671486.29.0.194582292222.issue21227@psf.upfronthosting.co.za> Message-ID: <20140416194617.GA17983@sleipnir.bytereef.org> Stefan Krah added the comment: In the case of DivisionImpossible it would actually be possible to use the error message 'quotient too large in //, % or divmod'. But that's just one condition. In the case of InvalidOperation there are something like 30 different error messages. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 21:47:16 2014 From: report at bugs.python.org (Nitika Agarwal) Date: Wed, 16 Apr 2014 19:47:16 +0000 Subject: [issue4744] asynchat documentation needs to be more precise In-Reply-To: <1230168171.56.0.381937953807.issue4744@psf.upfronthosting.co.za> Message-ID: <1397677636.03.0.535771612789.issue4744@psf.upfronthosting.co.za> Nitika Agarwal added the comment: @St?phane Wirtel (matrixise) I am really sorry but i just couldn't find where have i done a typo and have written 'asychat' insstead of asynchat.Will you please help me out in pointing out my error. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 21:48:02 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 16 Apr 2014 19:48:02 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1397677682.58.0.634690184444.issue21233@psf.upfronthosting.co.za> STINNER Victor added the comment: Patch version 3: remove _PyObject_GC_Calloc(), modify _PyObject_GC_Malloc() instead of use calloc() instead of malloc()+memset(0). ---------- Added file: http://bugs.python.org/file34924/calloc-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 21:49:09 2014 From: report at bugs.python.org (Alok Singhal) Date: Wed, 16 Apr 2014 19:49:09 +0000 Subject: [issue6305] islice doesn't accept large stop values In-Reply-To: <1245309263.43.0.625809679675.issue6305@psf.upfronthosting.co.za> Message-ID: <1397677749.23.0.956819194437.issue6305@psf.upfronthosting.co.za> Alok Singhal added the comment: OK. I have written the "slow path" version and tested it a bit. I will add the code to switch between the paths and also add test cases as well. Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 21:51:27 2014 From: report at bugs.python.org (Nitika Agarwal) Date: Wed, 16 Apr 2014 19:51:27 +0000 Subject: [issue19316] devguide: compiler - wording In-Reply-To: <1382272126.03.0.859419260116.issue19316@psf.upfronthosting.co.za> Message-ID: <1397677887.17.0.493737013454.issue19316@psf.upfronthosting.co.za> Nitika Agarwal added the comment: Hi, anyone please review my patch attached. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 21:53:00 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 16 Apr 2014 19:53:00 +0000 Subject: [issue21259] replace "except: pass" by "except Exception: pass" In-Reply-To: <1397671015.92.0.0555120458036.issue21259@psf.upfronthosting.co.za> Message-ID: <1397677980.37.0.176996487898.issue21259@psf.upfronthosting.co.za> Raymond Hettinger added the comment: FYI, the two are not equivalent. A bare except is equivalent to BaseException. Even then, the new code would be slower than the original, so I'm not sure this change should be made at all (it makes the code more verbose, slower, and risks introducing a semantic change). Also, Guido traditionally tries to discourage across the board changes like this. Instead, we aim for "holistic refactoring" where code improvements are being made one module at a time by someone who deeply groks the code and is thinking through all the changes. The problem with across-the-board edits is that they tend to be very shallow "change thing x to thing y" without looking at what the surrounding code is doing or whether the code ever made sense in the first place. Another part of the risk of semantic change is that we likely do not have specific tests for Exception vs BaseException so it would be easy to make a mistake and not have the test suite catch it. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 21:58:58 2014 From: report at bugs.python.org (Tim Golden) Date: Wed, 16 Apr 2014 19:58:58 +0000 Subject: [issue9291] mimetypes initialization fails on Windows because of non-Latin characters in registry In-Reply-To: <1279454095.41.0.733053669611.issue9291@psf.upfronthosting.co.za> Message-ID: <1397678338.57.0.322262829284.issue9291@psf.upfronthosting.co.za> Tim Golden added the comment: The attached patch issue9291.7.patch (which is essentially an amalgam of 9291.patch & 9291a.patch with some tweaks of my own) does appear to solve the issue. My Windows setup is UK, so if any of the people still watching this issue could test against a non-English Windows, that would be useful. Even this fix does leave some room for encoding mismatches between the stored values (mbcs encoded) and any string passed to guess_type. But it's not clear how that should be handled, and at least it doesn't crash out on .init. ---------- Added file: http://bugs.python.org/file34925/issue9291.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 22:00:03 2014 From: report at bugs.python.org (akira) Date: Wed, 16 Apr 2014 20:00:03 +0000 Subject: [issue21267] mktime_tz may return wrong result for past dates before Python 2.7.4 Message-ID: <1397678403.49.0.851331817917.issue21267@psf.upfronthosting.co.za> New submission from akira: >>> from email.utils import mktime_tz, parsedate_tz >>> mktime_tz(parsedate_tz('Thu, 1 Jan 1970 00:00:00 GMT')) 3600.0 It must returns `0` instead of `3600.0` assuming POSIX timestamp. UTC offsets in 1970 and today are different from each other by one hour in my local timezone (`time.mktime(1970, ..)` uses one UTC offset and `time.timezone` another). There are around a hundred such timezones. Note: `time.timezone == time.altzone` in my local timezone i.e., it can't be the documented DST issue. The bug is present in Python 2.6.9 (the last 2.6 release). The bug is present in Python 2.7.3 (Ubuntu 12.04 LTS supported until 2017) It is fixed in Python 2.7.4+ while replacing `time.mktime` with `calendar.timegm` in issue 14653. ---------- components: email messages: 216572 nosy: akira, barry, r.david.murray priority: normal severity: normal status: open title: mktime_tz may return wrong result for past dates before Python 2.7.4 type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 22:00:27 2014 From: report at bugs.python.org (akira) Date: Wed, 16 Apr 2014 20:00:27 +0000 Subject: [issue21267] mktime_tz may return wrong result for past dates before Python 2.7.4 In-Reply-To: <1397678403.49.0.851331817917.issue21267@psf.upfronthosting.co.za> Message-ID: <1397678427.92.0.830070629178.issue21267@psf.upfronthosting.co.za> Changes by akira <4kir4.1i at gmail.com>: ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 22:03:30 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 16 Apr 2014 20:03:30 +0000 Subject: [issue21227] Decimal class error messages for integer division aren't good In-Reply-To: <1397520159.39.0.440264883295.issue21227@psf.upfronthosting.co.za> Message-ID: <1397678610.97.0.368024294246.issue21227@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > It is certainly possible to document DivisionImpossible etc. This should not be done. We've made strong efforts to not extend the Decimal Arithmetic Specification. Also, the API already suffers from high complexity. Adding more exceptions to the mix just makes the module harder to learn. Instead, you are welcome to add more specific text messages to the existing (and standards compliant) exceptions: raise InvalidOperation("Not enough precision to compute the answer.") > I found it surprising at first, but like I said, it's like > the computer is given the first 28 digits of a number and > then asked to figure out the 30th digit. People are always surprised when their mental model conflicts with the actual design model. That doesn't mean the implementation should change. There may be a documentation issue, but then again, people who are "surprised" usually haven't studied the docs in detail. My overall sense for this bug report is that there isn't a real problem that needs to be solved. AFAICT, this particular "confusion" has never arisen before (i.e. bug reports, questions in python classes, posts on stackoverlow, blog posts, etc). Likewise, the issue does not seem to have ever arisen in the many other non-Python implementations of the decimal spec. I recommend that this either be closed or be limited to tweaking some of the error messages for existing exceptions. ---------- nosy: +facundobatista, rhettinger, tim.peters priority: normal -> low versions: +Python 3.5 -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 22:03:49 2014 From: report at bugs.python.org (paul j3) Date: Wed, 16 Apr 2014 20:03:49 +0000 Subject: [issue17218] support title and description in argparse add_mutually_exclusive_group In-Reply-To: <1361061502.09.0.252084655816.issue17218@psf.upfronthosting.co.za> Message-ID: <1397678629.82.0.663089879605.issue17218@psf.upfronthosting.co.za> paul j3 added the comment: The attached file implements a solution using a subclassed ArgumentParser and a .add_titled_mutually_exclusive_group method (two versions). I changed the test conditions a bit, removing a blank line, and making the usage 'exclusive'. ---------- Added file: http://bugs.python.org/file34926/test_argparse_mutex_with_title1.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 22:03:59 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 16 Apr 2014 20:03:59 +0000 Subject: [issue21261] Teach IDLE to Autocomplete dictionary keys In-Reply-To: <1397672472.64.0.119805531416.issue21261@psf.upfronthosting.co.za> Message-ID: <1397678639.42.0.604953456295.issue21261@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- keywords: +easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 22:05:44 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 16 Apr 2014 20:05:44 +0000 Subject: [issue21207] urandom persistent fd - not re-openned after fd close In-Reply-To: <1397316819.31.0.463593532744.issue21207@psf.upfronthosting.co.za> Message-ID: <1397678744.78.0.866951371862.issue21207@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Christian, do you see a security risk with the proposed change? ---------- nosy: +christian.heimes, rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 22:06:22 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 16 Apr 2014 20:06:22 +0000 Subject: [issue21262] assert_not_called method for mocks In-Reply-To: <1397673013.96.0.498096187317.issue21262@psf.upfronthosting.co.za> Message-ID: <3g8F260GGzz7Ljj@mail.python.org> Roundup Robot added the comment: New changeset 9e5cbc46e916 by Kushal Das in branch 'default': Closes Issue 21262: New method assert_not_called for Mock. http://hg.python.org/cpython/rev/9e5cbc46e916 ---------- nosy: +python-dev resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 22:08:34 2014 From: report at bugs.python.org (Ned Deily) Date: Wed, 16 Apr 2014 20:08:34 +0000 Subject: [issue21263] test_gdb failures on os x 10.9.2 In-Reply-To: <1397674257.45.0.239061101467.issue21263@psf.upfronthosting.co.za> Message-ID: <1397678914.66.0.199224420992.issue21263@psf.upfronthosting.co.za> Ned Deily added the comment: Since Apple no longer ships gdb or GNU gcc as part of Xcode and since lldb is the native debugger for clang/LLVM, this test is usually skipped on OS X these days unless you go to the trouble of explicitly installing gdb. Does anyone know if python support works when using gdb with clang? ---------- assignee: ronaldoussoren -> nosy: +dmalcolm, ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 22:08:54 2014 From: report at bugs.python.org (Ned Deily) Date: Wed, 16 Apr 2014 20:08:54 +0000 Subject: [issue21263] test_gdb failures on os x 10.9.2 In-Reply-To: <1397674257.45.0.239061101467.issue21263@psf.upfronthosting.co.za> Message-ID: <1397678934.17.0.406064671511.issue21263@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- components: -Macintosh _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 22:14:01 2014 From: report at bugs.python.org (Caelyn McAulay) Date: Wed, 16 Apr 2014 20:14:01 +0000 Subject: [issue20928] xml.etree.ElementInclude does not include nested xincludes In-Reply-To: <1394829606.55.0.5394943571.issue20928@psf.upfronthosting.co.za> Message-ID: <1397679241.94.0.601498266068.issue20928@psf.upfronthosting.co.za> Caelyn McAulay added the comment: xml.etree.ElementInclude.include now checks the inserted subtree to see if contains any Xincludes itself. And adds them. Also added a unit test to check for the new functionality (which will fail without the change to ElementInclude.py). ---------- keywords: +patch nosy: +math_foo Added file: http://bugs.python.org/file34927/issue20928.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 22:16:44 2014 From: report at bugs.python.org (Tim Golden) Date: Wed, 16 Apr 2014 20:16:44 +0000 Subject: [issue18314] Have os.unlink remove junction points In-Reply-To: <1372335321.1.0.479247042071.issue18314@psf.upfronthosting.co.za> Message-ID: <1397679404.32.0.224130419119.issue18314@psf.upfronthosting.co.za> Tim Golden added the comment: All tests pass on 3.5 and in an unelevated prompt. I'll have a closer look at the code tomorrow. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 22:23:31 2014 From: report at bugs.python.org (Alex Lord) Date: Wed, 16 Apr 2014 20:23:31 +0000 Subject: [issue21250] sqlite3 doesn't have unit tests for 'insert or [algorithm]' functionality. In-Reply-To: <1397634761.6.0.834429340049.issue21250@psf.upfronthosting.co.za> Message-ID: <1397679811.79.0.663447524392.issue21250@psf.upfronthosting.co.za> Alex Lord added the comment: Yes, I'm going to work on one after I fix Issue16864 today. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 22:26:52 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 16 Apr 2014 20:26:52 +0000 Subject: [issue21268] Update pydoc module docstring Message-ID: <1397680012.16.0.887791975702.issue21268@psf.upfronthosting.co.za> New submission from ?ric Araujo: ?In the Python interpreter, do "from pydoc import help" to provide online help.? ?online? has changed meaning in the last decades, and help is a semi-builtin automatically added by the site module on startup. ---------- assignee: docs at python components: Documentation keywords: easy messages: 216581 nosy: docs at python, eric.araujo priority: normal severity: normal stage: needs patch status: open title: Update pydoc module docstring versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 22:28:42 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 16 Apr 2014 20:28:42 +0000 Subject: [issue21227] Decimal class error messages for integer division aren't good In-Reply-To: <1397678610.97.0.368024294246.issue21227@psf.upfronthosting.co.za> Message-ID: <20140416202841.GA18310@sleipnir.bytereef.org> Stefan Krah added the comment: Raymond Hettinger wrote: > > It is certainly possible to document DivisionImpossible etc. > > This should not be done. We've made strong efforts to not extend the Decimal Arithmetic Specification. The exceptions are already there: Python 2.7.3 (default, Mar 13 2014, 11:03:55) [GCC 4.7.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import decimal >>> print(decimal.DivisionImpossible.__doc__) Cannot perform the division adequately. This occurs and signals invalid-operation if the integer result of a divide-integer or remainder operation had too many digits (would be longer than precision). The result is [0,qNaN]. The specification distinguishes between "conditions" and "signals". It is true that the conditions are not technically raised, but they are very much "subclasses" of InvalidOperation. Cowlishaw himself makes the distinction between InvalidOperation and IEEEInvalidOperation. The latter groups all conditions together: #define DEC_IEEE_754_Invalid_operation (DEC_Conversion_syntax | \ DEC_Division_impossible | \ DEC_Division_undefined | \ DEC_Insufficient_storage | \ DEC_Invalid_context | \ DEC_Invalid_operation) So while I don't particularly care whether we document the conditions or not, I don't think doing so would extend the specification. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 22:31:42 2014 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 16 Apr 2014 20:31:42 +0000 Subject: [issue21167] float('nan') returns 0.0 on Python compiled with icc In-Reply-To: <1396864952.24.0.891595123462.issue21167@psf.upfronthosting.co.za> Message-ID: <1397680302.87.0.0829327905425.issue21167@psf.upfronthosting.co.za> Mark Dickinson added the comment: Sure, if that's really the expectation. I'm not sure I'd want any of *my* extension modules being built with non-strict FP, but there's a bit of a personal bias there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 22:32:41 2014 From: report at bugs.python.org (Ned Deily) Date: Wed, 16 Apr 2014 20:32:41 +0000 Subject: [issue21265] ConfigParser allows "get(*, raw=True), but no corresponding "set(*, raw=True)" In-Reply-To: <1397674824.07.0.686320086238.issue21265@psf.upfronthosting.co.za> Message-ID: <1397680361.37.0.202152963479.issue21265@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +lukasz.langa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 22:43:55 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 16 Apr 2014 20:43:55 +0000 Subject: [issue21167] float('nan') returns 0.0 on Python compiled with icc In-Reply-To: <1397680302.87.0.0829327905425.issue21167@psf.upfronthosting.co.za> Message-ID: <20140416204354.GA18592@sleipnir.bytereef.org> Stefan Krah added the comment: I quite agree, and it's hard to tell what users want. Basically I'm afraid of a bug report "C extension using unsafe math got slower in Python-3.5". I would find either decision reasonable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 22:47:42 2014 From: report at bugs.python.org (Michael Foord) Date: Wed, 16 Apr 2014 20:47:42 +0000 Subject: [issue21269] Provide args and kwargs attributes on mock call objects Message-ID: <1397681262.54.0.610859323151.issue21269@psf.upfronthosting.co.za> New submission from Michael Foord: The unittest.mock.call object could have args/kwargs attributes to easily access the arguments it was called with. ---------- messages: 216585 nosy: michael.foord priority: normal severity: normal status: open title: Provide args and kwargs attributes on mock call objects _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 22:48:12 2014 From: report at bugs.python.org (Michael Foord) Date: Wed, 16 Apr 2014 20:48:12 +0000 Subject: [issue21269] Provide args and kwargs attributes on mock call objects In-Reply-To: <1397681262.54.0.610859323151.issue21269@psf.upfronthosting.co.za> Message-ID: <1397681292.18.0.895765920472.issue21269@psf.upfronthosting.co.za> Changes by Michael Foord : ---------- assignee: -> michael.foord components: +Library (Lib) nosy: +kushal.das stage: -> needs patch type: -> behavior versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 22:48:18 2014 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 16 Apr 2014 20:48:18 +0000 Subject: [issue21227] Decimal class error messages for integer division aren't good In-Reply-To: <1397520159.39.0.440264883295.issue21227@psf.upfronthosting.co.za> Message-ID: <1397681298.23.0.707986162162.issue21227@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 22:48:41 2014 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 16 Apr 2014 20:48:41 +0000 Subject: [issue4744] asynchat documentation needs to be more precise In-Reply-To: <1230168171.56.0.381937953807.issue4744@psf.upfronthosting.co.za> Message-ID: <1397681321.73.0.328620266325.issue4744@psf.upfronthosting.co.za> St?phane Wirtel added the comment: In your issue4744_2.patch, the anchor contains 'asychat' and not 'asynchat'. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 22:49:19 2014 From: report at bugs.python.org (Michael Foord) Date: Wed, 16 Apr 2014 20:49:19 +0000 Subject: [issue21270] unittest.mock.call object has inherited count method Message-ID: <1397681359.44.0.204245756188.issue21270@psf.upfronthosting.co.za> New submission from Michael Foord: The unittest.mock.call object inherits methods from tuple that prevent you using them as normal call attributes. They should be overridden. ---------- assignee: michael.foord messages: 216587 nosy: kushal.das, michael.foord priority: normal severity: normal stage: needs patch status: open title: unittest.mock.call object has inherited count method type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 22:50:16 2014 From: report at bugs.python.org (Michael Foord) Date: Wed, 16 Apr 2014 20:50:16 +0000 Subject: [issue18622] reset_mock on mock created by mock_open causes infinite recursion In-Reply-To: <1375391057.28.0.108463427813.issue18622@psf.upfronthosting.co.za> Message-ID: <1397681416.62.0.555453574396.issue18622@psf.upfronthosting.co.za> Changes by Michael Foord : ---------- nosy: +kushal.das versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 22:51:44 2014 From: report at bugs.python.org (Michael Foord) Date: Wed, 16 Apr 2014 20:51:44 +0000 Subject: [issue21271] reset_mock needs parameters to also reset return_value and side_effect Message-ID: <1397681504.34.0.196484984277.issue21271@psf.upfronthosting.co.za> New submission from Michael Foord: unittest.mock.Mock.reset_mock deliberately doesn't reset the return_value and side_effect. It would be nice if it gained parameters so that it *could*. ---------- assignee: michael.foord components: Library (Lib) messages: 216588 nosy: kushal.das, michael.foord priority: normal severity: normal stage: needs patch status: open title: reset_mock needs parameters to also reset return_value and side_effect type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 22:52:28 2014 From: report at bugs.python.org (leewz) Date: Wed, 16 Apr 2014 20:52:28 +0000 Subject: [issue21227] Decimal class error messages for integer division aren't good In-Reply-To: <1397520159.39.0.440264883295.issue21227@psf.upfronthosting.co.za> Message-ID: <1397681548.14.0.431648250759.issue21227@psf.upfronthosting.co.za> leewz added the comment: Total list of issues now: - Error message for `DivisionImpossible` is [] instead of an actual error message. - `decimal.DivisionImpossible.__doc__` is empty. - Calling `help(decimal.DivisionImpossible)` turns up nothing useful. I checked all of these just now on my 3.2.3 (Windows). These issues are a CHANGE from 3.2 to 3.3. For example: - Old error: decimal.InvalidOperation: quotient too large in //, % or divmod - New error: InvalidOperation: [] I assume that the issues also apply to the other InvalidOperation types. So I guess what I'm really asking for is to pull forward the 3.2 docs and messages. > That doesn't mean the implementation should change. Er, I was explaining why it wasn't really surprising once I thought about it. > There may be a documentation issue, but then again, people who are "surprised" usually haven't studied the docs in detail. To clarify: - I looked at the Decimal docs - skimmed for references to modulo and division - looked for `DivisionImpossible` - Then looked on Google for '"DivisionImpossible" Python'. - Experimented with changing precision and fooling around with bigger and smaller numbers, and realized why the operation was logically impossible. - Came here, posted, got a response that it was a flag raised by libmpdec. I'm not asking for a change in behavior. I did point out that it was inconsistent with regular floats, in case consistency with Pyfloats was a thing that mattered. But I don't care about that. I only worry about anyone else who would use Decimal coming across the same unhelpful error. > AFAICT, this particular "confusion" has never arisen before (i.e. bug reports, questions in python classes, posts on stackoverlow, blog posts, etc). Likewise, the issue does not seem to have ever arisen in the many other non-Python implementations of the decimal spec. I agree it'd be (very) rare, but part of the reason why it might not appear online is that the issues at the top of this email are relatively new (3.3). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 23:01:46 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 16 Apr 2014 21:01:46 +0000 Subject: [issue19316] devguide: compiler - wording In-Reply-To: <1382272126.03.0.859419260116.issue19316@psf.upfronthosting.co.za> Message-ID: <1397682106.92.0.998297304106.issue19316@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I will try to take a look, but anyone else is welcome to also. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 23:06:23 2014 From: report at bugs.python.org (Thomas Wouters) Date: Wed, 16 Apr 2014 21:06:23 +0000 Subject: [issue17861] put opcode information in one place In-Reply-To: <1367162089.6.0.986391601417.issue17861@psf.upfronthosting.co.za> Message-ID: <1397682383.55.0.435369110345.issue17861@psf.upfronthosting.co.za> Thomas Wouters added the comment: FYI, this broke building in a separate object directory (again!) for multiple reasons: it's running the script without specifying $(srcdir), and it's writing to $(srcdir)/Include/opcode.h (where $(srcdir) may be unwritable), and it's picking up the wrong opcode module: the sys.path mucking in Tools/generate_opcode_h.py isn't inserting the right directory for 'import opcode' to pick up the target-Python's opcode.py. It should probably be using execfile() and have the name of the file passed in, instead. Even if it were importing the right opcode.py, relying on 'import' or 'execfile' here sounds like a bad idea: it means the opcode module of the *target* Python needs to be compatible with the Python that the generate_opcode_h.py script runs with. Since the syntax of opcode.h is much more constrained, a more flexible approach, in my opinion, would be to parse opcode.h to produce opcode.py (or an _opcode.py with just the definitions, that opcode.py would then import.) ---------- nosy: +twouters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 23:06:58 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 16 Apr 2014 21:06:58 +0000 Subject: [issue21190] Broken download link on README for CPython docs In-Reply-To: <1397054916.95.0.591389338462.issue21190@psf.upfronthosting.co.za> Message-ID: <1397682418.14.0.723525169584.issue21190@psf.upfronthosting.co.za> ?ric Araujo added the comment: For the record, there is a convention (and server config) to have ?current version? links: http://legacy.python.org/dev/peps/pep-0430/ Senthil: What do you think about using /3/ instead of /3.4/ in the link so that it does not become another thing that needs to change with each release? ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 23:13:35 2014 From: report at bugs.python.org (Thomas Fenzl) Date: Wed, 16 Apr 2014 21:13:35 +0000 Subject: [issue1684] CGIHTTPServer does not chdir prior to executing the CGI script In-Reply-To: <1198274242.65.0.204698066624.issue1684@psf.upfronthosting.co.za> Message-ID: <1397682815.3.0.751794395992.issue1684@psf.upfronthosting.co.za> Changes by Thomas Fenzl : ---------- nosy: +Thomas Fenzl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 23:15:42 2014 From: report at bugs.python.org (Christian Hudon) Date: Wed, 16 Apr 2014 21:15:42 +0000 Subject: [issue20309] Not all method descriptors are callable In-Reply-To: <1390200218.06.0.45732778516.issue20309@psf.upfronthosting.co.za> Message-ID: <1397682942.29.0.956959259082.issue20309@psf.upfronthosting.co.za> Christian Hudon added the comment: Work in progress for fixing this bug. (See descr_v1.diff) I converted the "curious.py" file into additional testcases. I started writing the functions for the tp_call slots for class and static methods. To do: add tests to make sure that the code works for more than what's accepted by function_call(), then switch to using PyObject_Call() (which is the right function to use here, thanks to ncoghlan for catching that). Will finish this in the next few days. ---------- keywords: +patch nosy: +chrish42 Added file: http://bugs.python.org/file34928/descr_v1.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 23:16:27 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 16 Apr 2014 21:16:27 +0000 Subject: [issue12916] Add inspect.splitdoc In-Reply-To: <1315326747.38.0.43030903994.issue12916@psf.upfronthosting.co.za> Message-ID: <1397682987.0.0.6328397917.issue12916@psf.upfronthosting.co.za> ?ric Araujo added the comment: Added some comments. ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 23:22:34 2014 From: report at bugs.python.org (akira) Date: Wed, 16 Apr 2014 21:22:34 +0000 Subject: [issue18243] mktime_tz documentation out-of-date In-Reply-To: <1371482642.16.0.49381484414.issue18243@psf.upfronthosting.co.za> Message-ID: <1397683354.88.0.386141664187.issue18243@psf.upfronthosting.co.za> akira added the comment: I've added the documentation patch with the outdated remark removed from mktime_tz docs. ---------- keywords: +patch nosy: +akira type: -> behavior versions: +Python 3.2, Python 3.5 Added file: http://bugs.python.org/file34929/mktime_tz-doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 23:24:25 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Wed, 16 Apr 2014 21:24:25 +0000 Subject: [issue21190] Broken download link on README for CPython docs In-Reply-To: <1397054916.95.0.591389338462.issue21190@psf.upfronthosting.co.za> Message-ID: <1397683465.42.0.263366351253.issue21190@psf.upfronthosting.co.za> Senthil Kumaran added the comment: ?ric, no preference. I thought this was explicit and if you would like to change it back to /3/, fine, no problem with me. Just think of any redirection issue, if we may accidentally stumble upon, that's it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 23:24:55 2014 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 16 Apr 2014 21:24:55 +0000 Subject: [issue12916] Add inspect.splitdoc In-Reply-To: <1315326747.38.0.43030903994.issue12916@psf.upfronthosting.co.za> Message-ID: <1397683495.54.0.768554827328.issue12916@psf.upfronthosting.co.za> Yury Selivanov added the comment: The current patch proposes to add inspect.splitdoc(obj), instead of pydoc.splitdoc(doc). The former takes an object, extracts documentation out of it, and returns a tuple. The latter, just splits the passed doc string. If you want this function in inspect, we need to find a better name for it, or don't make it to receive an object. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 23:28:27 2014 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 16 Apr 2014 21:28:27 +0000 Subject: [issue12916] Add inspect.splitdoc In-Reply-To: <1397683495.54.0.768554827328.issue12916@psf.upfronthosting.co.za> Message-ID: <6D81A6DA-E940-4192-A1F2-CFA3D584ED82@wirtel.be> St?phane Wirtel added the comment: On 16 Apr 2014, at 17:24, Yury Selivanov wrote: > Yury Selivanov added the comment: > > The current patch proposes to add inspect.splitdoc(obj), instead of > pydoc.splitdoc(doc). The former takes an object, extracts > documentation out of it, and returns a tuple. The latter, just splits > the passed doc string. > > If you want this function in inspect, we need to find a better name > for it, or don't make it to receive an object. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ In the inspect module, I think all the functions take a object and not a string, it's the reason why I included the code of pydoc.getdoc() into inspect.splitdoc(). One point, the former ( pydoc.splitdoc() ) takes a string, and returns a tuple. it's not the case with the new version. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 23:34:29 2014 From: report at bugs.python.org (Thomas Wouters) Date: Wed, 16 Apr 2014 21:34:29 +0000 Subject: [issue17861] put opcode information in one place In-Reply-To: <1367162089.6.0.986391601417.issue17861@psf.upfronthosting.co.za> Message-ID: <1397684069.58.0.0574376212818.issue17861@psf.upfronthosting.co.za> Thomas Wouters added the comment: Here's a minimal patch to at least make the current mechanism work when using a separate build directory. I still don't like the fact that this is importing opcode.py in a different Python than the target Python. Nor do I like that the script hardcodes information about the opcodes (specifically, the first opcode to HAVE_ARGUMENT.) This feels like it's not actually better for maintenance than the previous solution. ---------- assignee: -> kushal.das resolution: fixed -> status: closed -> open Added file: http://bugs.python.org/file34930/generate_opcode_h.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 23:36:35 2014 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 16 Apr 2014 21:36:35 +0000 Subject: [issue12916] Add inspect.splitdoc In-Reply-To: <1397683495.54.0.768554827328.issue12916@psf.upfronthosting.co.za> Message-ID: <2DA50619-4E11-4307-991D-D61A2C79A807@wirtel.be> St?phane Wirtel added the comment: Yury, An other point, as you proposed, I will check the version of Python in an unit test. But is there a good practice? Here is my way to check that: Example from my patch for the issue with inspect.getfullargspec() + getfullargspec = getattr(inspect, 'getfullargspec', None) + if getfullargspec and sys.version_info >= (3, 7): + self.fail("inspect.getfullargspec() is deprecated since 3.5, " + "you must to remove it in 3.7") Are you agree with that, or there is a good way for this kind of improvement? Thank you so much, Stephane ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 23:37:31 2014 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 16 Apr 2014 21:37:31 +0000 Subject: [issue12916] Add inspect.splitdoc In-Reply-To: <1315326747.38.0.43030903994.issue12916@psf.upfronthosting.co.za> Message-ID: <1397684251.77.0.824089079829.issue12916@psf.upfronthosting.co.za> Yury Selivanov added the comment: > In the inspect module, I think all the functions take a object and not a string, it's the reason why I included the code of pydoc.getdoc() into inspect.splitdoc(). I understand. But you also do inspect.getdoc or inspect.getcomments, which I don't really like. What's the point of having getcomments there? Are comments considered docstrings? If not, then why is the method called splitdocs? Don't get me wrong, I'm not trying to pushback on the idea (since everybody is agreeing to have it), I just want the naming and behaviour be consistent. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 23:40:13 2014 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 16 Apr 2014 21:40:13 +0000 Subject: [issue12916] Add inspect.splitdoc In-Reply-To: <1315326747.38.0.43030903994.issue12916@psf.upfronthosting.co.za> Message-ID: <1397684413.67.0.800185137106.issue12916@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Are you agree with that, or there is a good way for this kind of improvement? Having a unittest to check if a deprecated functionality is removed in the future versions was Brett's idea, and I like it. So I think it's good to do the same here. Your way of doing this is fine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 23:40:20 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 16 Apr 2014 21:40:20 +0000 Subject: [issue21255] Attaching a PropertyMock records calls In-Reply-To: <1397665155.65.0.579203534798.issue21255@psf.upfronthosting.co.za> Message-ID: <1397684420.28.0.63424083337.issue21255@psf.upfronthosting.co.za> ?ric Araujo added the comment: >>> type(foo).prop = prop >>> foo.attach_mock(prop, 'prop') Are both of these lines needed? ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 23:40:54 2014 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 16 Apr 2014 21:40:54 +0000 Subject: [issue12916] Add inspect.splitdoc In-Reply-To: <1397684251.77.0.824089079829.issue12916@psf.upfronthosting.co.za> Message-ID: <94E74EC3-F7E1-4A05-91DC-F2671F4B51B0@wirtel.be> St?phane Wirtel added the comment: Totally agree with you, I want to learn how to contribute to cpython and there is a learning curve and it's normal. So, if you think we need to change the names or the signature of the function, I can work on this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 23:46:44 2014 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 16 Apr 2014 21:46:44 +0000 Subject: [issue12916] Add inspect.splitdoc In-Reply-To: <1315326747.38.0.43030903994.issue12916@psf.upfronthosting.co.za> Message-ID: <1397684804.94.0.631429003198.issue12916@psf.upfronthosting.co.za> Yury Selivanov added the comment: I'd keep the name ("splitdoc"), and let it receive a string. But let's hear what Eric & David think about it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 23:48:27 2014 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 16 Apr 2014 21:48:27 +0000 Subject: [issue12916] Add inspect.splitdoc In-Reply-To: <1397684804.94.0.631429003198.issue12916@psf.upfronthosting.co.za> Message-ID: <58313333-0229-4E38-AB18-CDC5B9A5C748@wirtel.be> St?phane Wirtel added the comment: Ok, I will work on this bug after the feedback of Eric and David. Thanks for your time. -- St?phane Wirtel - http://wirtel.be - @matrixise ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 23:49:42 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 16 Apr 2014 21:49:42 +0000 Subject: [issue12916] Add inspect.splitdoc In-Reply-To: <1315326747.38.0.43030903994.issue12916@psf.upfronthosting.co.za> Message-ID: <1397684982.5.0.121314447216.issue12916@psf.upfronthosting.co.za> ?ric Araujo added the comment: > I'd keep the name ("splitdoc"), and let it receive a string. Yes please. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 16 23:51:26 2014 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 16 Apr 2014 21:51:26 +0000 Subject: [issue12916] Add inspect.splitdoc In-Reply-To: <1397684982.5.0.121314447216.issue12916@psf.upfronthosting.co.za> Message-ID: <09E91B08-004A-4049-851E-817AF493456C@wirtel.be> St?phane Wirtel added the comment: And it takes a string or an object? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 00:00:54 2014 From: report at bugs.python.org (Thomas Fenzl) Date: Wed, 16 Apr 2014 22:00:54 +0000 Subject: [issue15887] urlencode should accept iterables of pairs In-Reply-To: <1347185937.29.0.747427121658.issue15887@psf.upfronthosting.co.za> Message-ID: <1397685654.11.0.758243127603.issue15887@psf.upfronthosting.co.za> Changes by Thomas Fenzl : ---------- nosy: +Thomas Fenzl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 00:12:08 2014 From: report at bugs.python.org (Matthias Klose) Date: Wed, 16 Apr 2014 22:12:08 +0000 Subject: [issue21272] use _sysconfigdata.py in distutils.sysconfig to initialize distutils.sysconfig Message-ID: <1397686328.42.0.129070062942.issue21272@psf.upfronthosting.co.za> New submission from Matthias Klose: distutils/sysconfig still parses the Makefile and config header; it should use the same approach now as the toplevel sysconfig module. ---------- components: Library (Lib) files: distutils-init.diff keywords: patch messages: 216609 nosy: doko priority: normal severity: normal status: open title: use _sysconfigdata.py in distutils.sysconfig to initialize distutils.sysconfig versions: Python 3.5 Added file: http://bugs.python.org/file34931/distutils-init.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 00:30:07 2014 From: report at bugs.python.org (Matthias Klose) Date: Wed, 16 Apr 2014 22:30:07 +0000 Subject: [issue21273] don't defined socket constants which are not implemented for GNU/Hurd Message-ID: <1397687407.58.0.755430574464.issue21273@psf.upfronthosting.co.za> New submission from Matthias Klose: Comment out constant exposed on the API which are not implemented on GNU/Hurd. They would not work at runtime anyway. ---------- components: Extension Modules files: hurd-disable-nonworking-constants.diff keywords: patch messages: 216610 nosy: doko priority: normal severity: normal status: open title: don't defined socket constants which are not implemented for GNU/Hurd versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file34932/hurd-disable-nonworking-constants.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 00:32:56 2014 From: report at bugs.python.org (Matthias Klose) Date: Wed, 16 Apr 2014 22:32:56 +0000 Subject: [issue21274] define PATH_MAX for GNU/Hurd in Python/pythonrun.c Message-ID: <1397687576.16.0.104530346632.issue21274@psf.upfronthosting.co.za> New submission from Matthias Klose: PATH_MAX is not defined on GNU/Hurd. Take the same approach as taken for Windows in the very same file and define it in terms of MAXPATHLEN. ---------- components: Interpreter Core files: hurd-path_max.diff keywords: patch messages: 216611 nosy: doko priority: normal severity: normal status: open title: define PATH_MAX for GNU/Hurd in Python/pythonrun.c versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file34933/hurd-path_max.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 00:38:33 2014 From: report at bugs.python.org (Matthias Klose) Date: Wed, 16 Apr 2014 22:38:33 +0000 Subject: [issue21275] fix a socket test on KFreeBSD Message-ID: <1397687913.02.0.0778138511124.issue21275@psf.upfronthosting.co.za> New submission from Matthias Klose: Fix a socket test on KFreeBSD ---------- components: Tests files: kfreebsd-testsuite.diff keywords: patch messages: 216612 nosy: doko priority: normal severity: normal status: open title: fix a socket test on KFreeBSD versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file34934/kfreebsd-testsuite.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 00:39:55 2014 From: report at bugs.python.org (Matthias Klose) Date: Wed, 16 Apr 2014 22:39:55 +0000 Subject: [issue21276] don't define USE_XATTRS on kfreebsd and the Hurd Message-ID: <1397687995.9.0.529028609843.issue21276@psf.upfronthosting.co.za> New submission from Matthias Klose: don't define USE_XATTRS on kfreebsd and the Hurd, not available there. ---------- files: kfreebsd-xattrs.diff keywords: patch messages: 216613 nosy: doko priority: normal severity: normal status: open title: don't define USE_XATTRS on kfreebsd and the Hurd versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file34935/kfreebsd-xattrs.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 00:44:26 2014 From: report at bugs.python.org (Matthias Klose) Date: Wed, 16 Apr 2014 22:44:26 +0000 Subject: [issue21277] don't try to link _ctypes with a ffi_convenience library Message-ID: <1397688266.23.0.303919517358.issue21277@psf.upfronthosting.co.za> New submission from Matthias Klose: the ffi_convenience library was once built and installed with oldish GCC versions. Either remove it completely from the search path, or search for the standard libffi system library. --- a/setup.py +++ b/setup.py @@ -1939,7 +1939,7 @@ break ffi_lib = None if ffi_inc is not None: - for lib_name in ('ffi_convenience', 'ffi_pic', 'ffi'): + for lib_name in ('ffi', 'ffi_convenience', 'ffi_pic', 'ffi'): if (self.compiler.find_library_file(lib_dirs, lib_name)): ffi_lib = lib_name break ---------- components: Build messages: 216614 nosy: doko priority: normal severity: normal status: open title: don't try to link _ctypes with a ffi_convenience library versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 00:45:52 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 16 Apr 2014 22:45:52 +0000 Subject: [issue21227] Decimal class error messages for integer division aren't good In-Reply-To: <1397681548.14.0.431648250759.issue21227@psf.upfronthosting.co.za> Message-ID: <20140416224551.GA20042@sleipnir.bytereef.org> Stefan Krah added the comment: leewz wrote: > - Error message for `DivisionImpossible` is > [] > instead of an actual error message. No, the error message for the *signal* that is raised (InvalidOperation) lists the *condition* that triggered the signal (DivisionImpossible). I followed the recommendation at: http://speleotrove.com/decimal/daexcep.html#refexcep "It is recommended that implementations distinguish the different conditions listed above, and also provide additional information about exceptional conditions where possible (for example, the operation being attempted and the values of the operand or operands involved)." Distinguishing the conditions is easy, adding additional information in all cases would require changes to libmpdec. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 00:49:00 2014 From: report at bugs.python.org (Christian Theune) Date: Wed, 16 Apr 2014 22:49:00 +0000 Subject: [issue21202] Naming a file` io.py` causes cryptic error message In-Reply-To: <1397239551.94.0.578791540537.issue21202@psf.upfronthosting.co.za> Message-ID: <1397688540.77.0.126811291445.issue21202@psf.upfronthosting.co.za> Changes by Christian Theune : ---------- hgrepos: +238 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 01:02:40 2014 From: report at bugs.python.org (ddvento@ucar.edu) Date: Wed, 16 Apr 2014 23:02:40 +0000 Subject: [issue21278] Running the test suite with -v makes the test_ctypes and the test_zipimport erroneously reported as failed Message-ID: <1397689360.76.0.544034222842.issue21278@psf.upfronthosting.co.za> New submission from ddvento at ucar.edu: Running EXTRATESTOPTS='-x test_gdb -uall -v' make testall Produces: .... test_csv test_ctypes test test_ctypes produced unexpected output: ********************************************************************** Trying: from ctypes import * Expecting nothing ok Trying: array = (c_char_p * 5)() Expecting nothing ok Trying: print array._objects Expecting: None ok Trying: array[4] = 'foo bar' Expecting nothing ok Trying: array._objects Expecting: {'4': 'foo bar'} ok Trying: array[4] Expecting: 'foo bar' ok Trying: class X(Structure): _fields_ = [("x", c_int), ("y", c_int), ("array", c_char_p * 5)] Expecting nothing ok Trying: x = X() Expecting nothing ok Trying: print x._objects Expecting: None ok Trying: print x.array._b_base_ # doctest: +ELLIPSIS Expecting: ok Trying: x.array[0] = 'spam spam spam' Expecting nothing ok Trying: x._objects Expecting: {'0:2': 'spam spam spam'} ok Trying: x.array._b_base_._objects Expecting: {'0:2': 'spam spam spam'} ok 2 items had no tests: ctypes.test.test_objects.TestCase ctypes.test.test_objects.TestCase.test 1 items passed all tests: 13 tests in ctypes.test.test_objects 13 tests in 3 items. 13 passed and 0 failed. Test passed. ********************************************************************** test_curses ..... test_zipimport test test_zipimport produced unexpected output: ********************************************************************** Trying: log.append(True) Expecting nothing ok 1 items passed all tests: 1 tests in xyz.txt 1 tests in 1 items. 1 passed and 0 failed. Test passed. Trying: log.append(True) Expecting nothing ok 1 items passed all tests: 1 tests in xyz.txt 1 tests in 1 items. 1 passed and 0 failed. Test passed. ********************************************************************** test_zipimport_support test_zlib 366 tests OK. 4 tests failed: test_ctypes test_urllib2net test_urllibnet test_zipimport 26 tests skipped: test_aepack test_al test_applesingle test_bsddb test_bsddb185 test_bsddb3 test_cd test_cl test_curses test_dl test_gl test_imageop test_imgfile test_kqueue test_linuxaudiodev test_macos test_macostools test_msilib test_ossaudiodev test_pep277 test_scriptpackages test_startfile test_sunaudiodev test_winreg test_winsound test_zipfile64 2 skips unexpected on linux2: test_bsddb test_bsddb3 Clearly the test_ctypes and the test_zipimport are not failing but the test suite thinks so. In fact, rerunning without the -v let them succeed. ---------- messages: 216616 nosy: ddvento at ucar.edu priority: normal severity: normal status: open title: Running the test suite with -v makes the test_ctypes and the test_zipimport erroneously reported as failed versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 01:03:53 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 16 Apr 2014 23:03:53 +0000 Subject: [issue21199] Python on 64-bit Windows uses signed 32-bit type for read length In-Reply-To: <1397149133.44.0.946556558932.issue21199@psf.upfronthosting.co.za> Message-ID: <1397689433.0.0.402171356428.issue21199@psf.upfronthosting.co.za> Larry Hastings added the comment: Here's my version of the patch. It does the same thing Victor's patch does, but removes a now-completely-irrelevant stanza of code, and adds a test. I'm on 64-bit Linux, so the test was always going to work anyway. So I tested the test by changing file_read to use an int (and the "i" format unit), which happily causes it to fail. ---------- stage: -> patch review Added file: http://bugs.python.org/file34936/larry.file_read.8.bytes.1.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 01:04:04 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 16 Apr 2014 23:04:04 +0000 Subject: [issue21240] Add an abstactmethod directive to the Python ReST domain In-Reply-To: <1397577446.45.0.129673687933.issue21240@psf.upfronthosting.co.za> Message-ID: <1397689444.44.0.54128322234.issue21240@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 01:04:28 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 16 Apr 2014 23:04:28 +0000 Subject: [issue21235] importlib's spec module create algorithm is not exposed In-Reply-To: <1397571881.77.0.850697644958.issue21235@psf.upfronthosting.co.za> Message-ID: <1397689468.9.0.379330006849.issue21235@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 01:10:09 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 16 Apr 2014 23:10:09 +0000 Subject: [issue17752] many distutils tests fail when run from the installed location In-Reply-To: <1366109374.8.0.221213577793.issue17752@psf.upfronthosting.co.za> Message-ID: <1397689809.61.0.588691510925.issue17752@psf.upfronthosting.co.za> ?ric Araujo added the comment: The xx module is built by the unit tests IIRC. ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 01:15:06 2014 From: report at bugs.python.org (Christian Theune) Date: Wed, 16 Apr 2014 23:15:06 +0000 Subject: [issue21202] Naming a file` io.py` causes cryptic error message In-Reply-To: <1397239551.94.0.578791540537.issue21202@psf.upfronthosting.co.za> Message-ID: <1397690106.85.0.0107009173641.issue21202@psf.upfronthosting.co.za> Christian Theune added the comment: I managed to create a patch that relies (in hopefully reasonably safe manner) on embedding an object repr for identification in this and similar cases. This is basically what implements what Martin suggested. Caveat emptor: my C knowledge is only good enough to be dangerous. Thomas Wouters and RDM helped me through it. I haven't adapted the tests yet (lots of failures due to the output change) but I managed them to stop crashing. The 'repr.py' in the root is my current testbed to see what's going on. ---------- nosy: +ctheune, r.david.murray, twouters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 01:15:22 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 16 Apr 2014 23:15:22 +0000 Subject: [issue17861] put opcode information in one place In-Reply-To: <1367162089.6.0.986391601417.issue17861@psf.upfronthosting.co.za> Message-ID: <3g8KD95Js8z7Ljf@mail.python.org> Roundup Robot added the comment: New changeset 2b187c9e3e92 by Thomas Wouters in branch 'default': Fix Tools/scripts/generate_opcode_h.py from issue #17861 to work correctly http://hg.python.org/cpython/rev/2b187c9e3e92 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 01:15:23 2014 From: report at bugs.python.org (Christian Theune) Date: Wed, 16 Apr 2014 23:15:23 +0000 Subject: [issue21202] Naming a file` io.py` causes cryptic error message In-Reply-To: <1397239551.94.0.578791540537.issue21202@psf.upfronthosting.co.za> Message-ID: <1397690123.58.0.00374169660215.issue21202@psf.upfronthosting.co.za> Changes by Christian Theune : ---------- keywords: +patch Added file: http://bugs.python.org/file34937/4ae151db1bd9.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 01:17:25 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 16 Apr 2014 23:17:25 +0000 Subject: [issue20438] inspect: Deprecate getfullargspec? In-Reply-To: <1391014813.06.0.594760406572.issue20438@psf.upfronthosting.co.za> Message-ID: <1397690245.32.0.364350666473.issue20438@psf.upfronthosting.co.za> Larry Hastings added the comment: +1 to doc deprecation and adding a DeprecationWarning for 3.5. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 01:17:35 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 16 Apr 2014 23:17:35 +0000 Subject: [issue21227] Decimal class error messages for integer division aren't good In-Reply-To: <20140416224551.GA20042@sleipnir.bytereef.org> Message-ID: <20140416231734.GA20364@sleipnir.bytereef.org> Stefan Krah added the comment: The idea behind the list as the exception message is this: If multiple conditions would have raised the signal they are all listed, while the "highest ranking" signal is the one that is ultimately raised. >>> from decimal import * >>> c = getcontext() >>> for v in c.traps: ... c.traps[v] = True ... >>> >>> Decimal(8) ** 1000000000000000 Traceback (most recent call last): File "", line 1, in decimal.Overflow: [, , ] Exception precedence is listed here at the bottom of the page: http://speleotrove.com/decimal/daexcep.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 01:19:17 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 16 Apr 2014 23:19:17 +0000 Subject: [issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k In-Reply-To: <1394697296.27.0.543058724281.issue20904@psf.upfronthosting.co.za> Message-ID: <1397690357.94.0.642816682475.issue20904@psf.upfronthosting.co.za> Larry Hastings added the comment: Okay, I say let's check this in. If mirabilos can cite problems it causes we can revert it. Andreas, is there someone who would normally check this in for you, or should I do it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 01:23:00 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 16 Apr 2014 23:23:00 +0000 Subject: [issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k In-Reply-To: <1397690357.94.0.642816682475.issue20904@psf.upfronthosting.co.za> Message-ID: <20140416232300.GB20364@sleipnir.bytereef.org> Stefan Krah added the comment: Larry Hastings wrote: > Andreas, is there someone who would normally check this in for you, or should I do it? Traditionally Mark commits the floating point stuff. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 01:43:35 2014 From: report at bugs.python.org (Caelyn McAulay) Date: Wed, 16 Apr 2014 23:43:35 +0000 Subject: [issue12148] Clarify "or-ing together" doctest option flags In-Reply-To: <1306058966.52.0.456848115548.issue12148@psf.upfronthosting.co.za> Message-ID: <1397691815.87.0.476941970596.issue12148@psf.upfronthosting.co.za> Caelyn McAulay added the comment: I grepped for 's together' and found two instances of "or's together" in the docs which I reworded to use bitwise-or instead, in the attached patch. ---------- keywords: +patch nosy: +math_foo Added file: http://bugs.python.org/file34938/issue12148.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 01:53:10 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 16 Apr 2014 23:53:10 +0000 Subject: [issue21088] curses addch() argument position reverses in Python3.4.0 In-Reply-To: <1396036290.82.0.606042459455.issue21088@psf.upfronthosting.co.za> Message-ID: <1397692390.43.0.325483614385.issue21088@psf.upfronthosting.co.za> Larry Hastings added the comment: Here's my version of the patch, which is like Victor's patch but adds a test. For what it's worth, I'll make sure this issue is fixed before I release 3.4.1. ---------- Added file: http://bugs.python.org/file34939/larry.curses.window.addch.y.x.1.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 01:55:07 2014 From: report at bugs.python.org (Daniel Black) Date: Wed, 16 Apr 2014 23:55:07 +0000 Subject: [issue21207] urandom persistent fd - not re-openned after fd close In-Reply-To: <1397316819.31.0.463593532744.issue21207@psf.upfronthosting.co.za> Message-ID: <1397692507.42.0.933452453908.issue21207@psf.upfronthosting.co.za> Changes by Daniel Black : ---------- nosy: +grooverdan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 01:58:47 2014 From: report at bugs.python.org (Matthias Klose) Date: Wed, 16 Apr 2014 23:58:47 +0000 Subject: [issue21277] don't try to link _ctypes with a ffi_convenience library In-Reply-To: <1397688266.23.0.303919517358.issue21277@psf.upfronthosting.co.za> Message-ID: <1397692727.65.0.361752617683.issue21277@psf.upfronthosting.co.za> Matthias Klose added the comment: the list of libs should be just: ('ffi', 'ffi_pic') ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 02:25:08 2014 From: report at bugs.python.org (Caelyn McAulay) Date: Thu, 17 Apr 2014 00:25:08 +0000 Subject: [issue5904] strftime docs do not explain locale effect on result string In-Reply-To: <1241270739.12.0.286821632978.issue5904@psf.upfronthosting.co.za> Message-ID: <1397694308.48.0.888001844137.issue5904@psf.upfronthosting.co.za> Caelyn McAulay added the comment: Added to Docs that strftime will return a locale dependent byte string. ---------- keywords: +patch nosy: +math_foo Added file: http://bugs.python.org/file34940/issue5904.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 02:27:40 2014 From: report at bugs.python.org (Faiz Abbasi) Date: Thu, 17 Apr 2014 00:27:40 +0000 Subject: [issue21230] imghdr does not accept adobe photoshop mime type In-Reply-To: <1397524431.49.0.471880586962.issue21230@psf.upfronthosting.co.za> Message-ID: <1397694460.12.0.19945240235.issue21230@psf.upfronthosting.co.za> Faiz Abbasi added the comment: Hey, just checking in on this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 02:32:31 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 17 Apr 2014 00:32:31 +0000 Subject: [issue21272] use _sysconfigdata.py in distutils.sysconfig to initialize distutils.sysconfig In-Reply-To: <1397686328.42.0.129070062942.issue21272@psf.upfronthosting.co.za> Message-ID: <1397694751.31.0.424594193755.issue21272@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +dstufft, eric.araujo stage: -> patch review type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 02:34:43 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 17 Apr 2014 00:34:43 +0000 Subject: [issue12148] Clarify "or-ing together" doctest option flags In-Reply-To: <1306058966.52.0.456848115548.issue12148@psf.upfronthosting.co.za> Message-ID: <1397694883.83.0.865858379963.issue12148@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- versions: +Python 3.4, Python 3.5 -Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 03:01:22 2014 From: report at bugs.python.org (bob gailer) Date: Thu, 17 Apr 2014 01:01:22 +0000 Subject: [issue21279] str.translate documentation incomplete Message-ID: <1397696482.87.0.486412592823.issue21279@psf.upfronthosting.co.za> New submission from bob gailer: Documentation for str.translate only mentions a dictionary for the translation table. Actually any iterable can be used, as long as its elements are integer, None or str. Recommend wording: str.translate(translation_table) Return a copy of the s where all characters have been "mapped" through the translation_table - which must be either a dictionary mapping Unicode ordinals (integers) to Unicode ordinals, strings or None, or an iterable. In this case the ord() of each character in s is used as an index into the iterable; the corresponding element of the iterable replaces the character. If ord() of the character exceeds the index range of the iterator, no substitution is made. Example: to shift any of the first 255 ASCII characters to the next: >>> 'Now is the time for all good men'.translate(range(1, 256)) 'Opx!jt!uif!ujnf!gps!bmm!hppe!nfo' COMMENT: I placed mapped in quotes as technically this only applies to dictionaries. Not sure what the best word is. ---------- assignee: docs at python components: Documentation messages: 216630 nosy: bgailer, docs at python priority: normal severity: normal status: open title: str.translate documentation incomplete type: enhancement versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 03:03:51 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 17 Apr 2014 01:03:51 +0000 Subject: [issue21234] __contains__ and friends should check "is" for all elements first In-Reply-To: <1397567063.59.0.649029276797.issue21234@psf.upfronthosting.co.za> Message-ID: <1397696631.24.0.280010238397.issue21234@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > when doing an operation that does linear search through a container, > the interpreter checks all items one by one, first checking identity > and then equality. This is the guaranteed behavior. Changing it would result in subtle change in semantics (i.e. an equality match early in a sequence would be bypassed in favor of a later identity match). The current behavior also has favorable cache characteristics (i.e. each element is accessed exactly once) which provide benefits for long lists that cannot fit in L1 or L2 cache. That said, I feel your pain. Slow __eq__ tests are the bane of linear search. I recommend using a hashed container for fast searching or that you use a tool like PyPy that gives significant speed-ups. ---------- resolution: -> rejected status: open -> closed versions: -Python 3.1, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 03:06:05 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 17 Apr 2014 01:06:05 +0000 Subject: [issue21279] str.translate documentation incomplete In-Reply-To: <1397696482.87.0.486412592823.issue21279@psf.upfronthosting.co.za> Message-ID: <1397696765.46.0.466377581696.issue21279@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- keywords: +easy stage: -> patch review versions: +Python 3.4, Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 03:15:03 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 17 Apr 2014 01:15:03 +0000 Subject: [issue21259] replace "except: pass" by "except Exception: pass" In-Reply-To: <1397671015.92.0.0555120458036.issue21259@psf.upfronthosting.co.za> Message-ID: <1397697303.21.0.432015797469.issue21259@psf.upfronthosting.co.za> Raymond Hettinger added the comment: After more consideration, I'm going to reject the patch because it doesn't really make the code better and may make it worse (changing semantics, slower, etc). Any such changes should be done holistically as part of a deeper refactoring on an individual module. I appreciate the patch effort but would like to avoid code churn for nearly zero benefit. ---------- assignee: -> rhettinger resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 03:24:04 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 17 Apr 2014 01:24:04 +0000 Subject: [issue21101] Extend the PyDict C API to handle cases where the hash value is known In-Reply-To: <1396169909.67.0.904843670128.issue21101@psf.upfronthosting.co.za> Message-ID: <1397697844.59.0.0332801201845.issue21101@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Antoine, do you support adding these as part of the public API? If not, I can make them private. I think the functions are broadly useful, but no one has ever asked for this functionality either. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 03:26:22 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 17 Apr 2014 01:26:22 +0000 Subject: [issue21028] ElementTree objects should support all the same methods as Element objects In-Reply-To: <1395528476.17.0.859396205804.issue21028@psf.upfronthosting.co.za> Message-ID: <1397697982.01.0.455315950064.issue21028@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Given Stephan's concerned, I withdraw this feature request. ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 03:27:51 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 17 Apr 2014 01:27:51 +0000 Subject: [issue21101] Extend the PyDict C API to handle cases where the hash value is known In-Reply-To: <1396169909.67.0.904843670128.issue21101@psf.upfronthosting.co.za> Message-ID: <1397698071.43.0.472712975312.issue21101@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I think we can start with making them private. Do you know of any third-party code bases which may be interested in the speedup? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 03:37:49 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 17 Apr 2014 01:37:49 +0000 Subject: [issue21259] replace "except: pass" by "except Exception: pass" In-Reply-To: <1397671015.92.0.0555120458036.issue21259@psf.upfronthosting.co.za> Message-ID: <1397698669.32.0.971003260992.issue21259@psf.upfronthosting.co.za> STINNER Victor added the comment: > FYI, the two are not equivalent. I don't get your point, the purpose of the change is to get ride of "except: pass" which is *bad*. > Even then, the new code would be slower than the original, I don't understand why you are talking about performances here. Ignore SystemExit and KeyboardInterrupt is a huge bug, performances don't matter here. I don't want to benchmark, but I expect that performances are exactly the same if no exception is raised. Please don't close the issue, St?phane is fixing real bug. I agree that it would be better to split the large patch is shorter parts. Or all changes replacing "except: pass" should be grouped into the same patch. Replacing "except: ; raise" with "except Exception: ; raise" is wrong. ---------- resolution: rejected -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 03:50:06 2014 From: report at bugs.python.org (Dave Odell) Date: Thu, 17 Apr 2014 01:50:06 +0000 Subject: [issue21151] winreg.SetValueEx causes crash if value = None In-Reply-To: <1396581421.46.0.554143633373.issue21151@psf.upfronthosting.co.za> Message-ID: <1397699406.9.0.984600088491.issue21151@psf.upfronthosting.co.za> Dave Odell added the comment: Patch works on my end. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 03:53:36 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 17 Apr 2014 01:53:36 +0000 Subject: [issue21259] replace "except: pass" by "except Exception: pass" In-Reply-To: <1397671015.92.0.0555120458036.issue21259@psf.upfronthosting.co.za> Message-ID: <1397699616.42.0.260811198334.issue21259@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > Please don't close the issue, St?phane is fixing real bug. He appears to be doing a blanket search and replace without adding tests, without evaluating each change to see if makes sense, and without consulting the original author of each affected piece of code. We have never received a bug report on any one of these. If you think any one of them is an actually bug, it should be carefully considered one at a time, evaluating why the bare except was put there in the first place. Guido pushes for holistic refactoring for a reason. It is too easy to introduce bugs into stable code by these kind of wholesale changes. If you (Victor) want to individually study each one to make sure it is the right thing to do, I would place more faith in the patch. But as it stands now, reviewing the patch for correctness will take substantially more care and thought than it took to create it in the first place. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 03:58:21 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 17 Apr 2014 01:58:21 +0000 Subject: [issue18628] Better index entry for encoding declarations In-Reply-To: <1375418984.87.0.318628832877.issue18628@psf.upfronthosting.co.za> Message-ID: <3g8NrD6Vvgz7LjS@mail.python.org> Roundup Robot added the comment: New changeset 0413e0b1f76d by R David Murray in branch '3.4': #18628: clarify index entry for source file encoding declaration. http://hg.python.org/cpython/rev/0413e0b1f76d New changeset 7c2dcb18146c by R David Murray in branch 'default': Merge: #18628: clarify index entry for source file encoding declaration. http://hg.python.org/cpython/rev/7c2dcb18146c New changeset 2a793df32be5 by R David Murray in branch '2.7': #18628: clarify index entry for source file encoding declaration. http://hg.python.org/cpython/rev/2a793df32be5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 04:05:52 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 17 Apr 2014 02:05:52 +0000 Subject: [issue21259] replace "except: pass" by "except Exception: pass" In-Reply-To: <1397671015.92.0.0555120458036.issue21259@psf.upfronthosting.co.za> Message-ID: <1397700352.43.0.00738358808842.issue21259@psf.upfronthosting.co.za> STINNER Victor added the comment: I reviewed issue21259-replace_except_pass-2.patch. Please split this huge patch into smaller patches: 1) remove dummy "except: raise" 2) use os.unlink() 3) replace "except: pass" with more precise exceptions like "except OSError:" => please write multiple small patches for this part 4) generic change "except: pass" to "except Exception: pass" You might open a new issue for these 4 kind of patches (4 issues). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 04:09:47 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 17 Apr 2014 02:09:47 +0000 Subject: [issue21259] replace "except: pass" by "except Exception: pass" In-Reply-To: <1397671015.92.0.0555120458036.issue21259@psf.upfronthosting.co.za> Message-ID: <1397700587.79.0.356082335334.issue21259@psf.upfronthosting.co.za> STINNER Victor added the comment: > 3) replace "except: pass" with more precise exceptions like "except OSError:" => please write multiple small patches for this part You may even open a new issue just for "except: pass" => "except OSError: pass" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 04:10:53 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 17 Apr 2014 02:10:53 +0000 Subject: [issue21259] replace "except: pass" by "except Exception: pass" In-Reply-To: <1397671015.92.0.0555120458036.issue21259@psf.upfronthosting.co.za> Message-ID: <1397700653.97.0.915510162018.issue21259@psf.upfronthosting.co.za> STINNER Victor added the comment: @Raymond: To give you more context, St?phane is sprinting at Pycon on Pycon. I suggested him to fix all bare "except: pass". His first patch is wrong, but ignoring any exception is even worse. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 04:13:13 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 17 Apr 2014 02:13:13 +0000 Subject: [issue21259] replace "except: pass" by "except Exception: pass" In-Reply-To: <1397700653.97.0.915510162018.issue21259@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > If you (Victor) want to individually study each one to make sure it is the right thing to do, I would place more faith in the patch. But as it stands now, reviewing the patch for correctness will take substantially more care and thought than it took to create it in the first place. Agreed. I would like to help St?phane to fix these issues. I agree that the huge patch must be splitted, I just explained how the patch should be splitted and how St?phane can provide more useful patches. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 04:15:14 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 17 Apr 2014 02:15:14 +0000 Subject: [issue18628] Better index entry for encoding declarations In-Reply-To: <1375418984.87.0.318628832877.issue18628@psf.upfronthosting.co.za> Message-ID: <1397700914.69.0.992595491804.issue18628@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, Sam. ---------- nosy: +r.david.murray resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 04:49:37 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Thu, 17 Apr 2014 02:49:37 +0000 Subject: [issue21272] use _sysconfigdata.py in distutils.sysconfig to initialize distutils.sysconfig In-Reply-To: <1397686328.42.0.129070062942.issue21272@psf.upfronthosting.co.za> Message-ID: <20140416224925.05ccf7f2@anarchist.localdomain> Barry A. Warsaw added the comment: On Apr 16, 2014, at 10:12 PM, Matthias Klose wrote: > >distutils/sysconfig still parses the Makefile and config header; it should >use the same approach now as the toplevel sysconfig module. Why do we still have two sysconfig modules? ---------- nosy: +barry title: use _sysconfigdata.py in distutils.sysconfig to initialize distutils.sysconfig -> use _sysconfigdata.py in distutils.sysconfig to initialize distutils.sysconfig _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 05:02:23 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 17 Apr 2014 03:02:23 +0000 Subject: [issue21259] replace "except: pass" by "except Exception: pass" In-Reply-To: <1397671015.92.0.0555120458036.issue21259@psf.upfronthosting.co.za> Message-ID: <1397703743.95.0.514758816679.issue21259@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Several areas for attention: * Changes to the test suite probably should not be made The user doesn't benefit in any way and you risk unintentionally breaking the test suite in a way that isn't obvious (we have no tests for the tests themselves so changing tests is like refactoring without a safety net). * Some of the exception handling in IDLE needs to catch all exceptions (i.e. SystemExit and KeyboardInterrupt are supposed to display tracebacks and not terminate IDLE itself). * Changing the exceptions in threading.py is worrisome. * The Pdb debugger may have legitimate reasons to catch all exceptions (like IDLE, we want don't want to terminate the debugger itself). In other words, many of the proposed changes should not be made. For the rest, be careful to not change semantics unintentionally and consider adding tests if you think there is a real bug. In cases where there is doubt about the right thing to do, consider assigning the original author or maintainer of the code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 05:33:28 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 17 Apr 2014 03:33:28 +0000 Subject: [issue21171] Outdated usage str.encode('rot-13') in rot13 codec In-Reply-To: <1396887951.87.0.0918755245814.issue21171@psf.upfronthosting.co.za> Message-ID: <1397705608.33.0.458076449397.issue21171@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 05:33:40 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 17 Apr 2014 03:33:40 +0000 Subject: [issue21229] Path used for HTTP PUT request doesn't match the description In-Reply-To: <1397522183.41.0.398189687255.issue21229@psf.upfronthosting.co.za> Message-ID: <3g8QyC2bFgz7Lkc@mail.python.org> Roundup Robot added the comment: New changeset 57c66f85942d by Senthil Kumaran in branch '3.4': Correct the URL in the http.client example. Noted by Evens Fortun?. Closes #21229 http://hg.python.org/cpython/rev/57c66f85942d ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 05:34:25 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Thu, 17 Apr 2014 03:34:25 +0000 Subject: [issue21229] Path used for HTTP PUT request doesn't match the description In-Reply-To: <1397522183.41.0.398189687255.issue21229@psf.upfronthosting.co.za> Message-ID: <1397705665.86.0.173460643438.issue21229@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Yes. And thanks for the patch. I applied a slight variation of it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 05:44:12 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 17 Apr 2014 03:44:12 +0000 Subject: [issue21248] BROWSER env var described inaccurately in webbrowser docs In-Reply-To: <1397597825.94.0.182594358629.issue21248@psf.upfronthosting.co.za> Message-ID: <3g8RBM34JCz7Ljf@mail.python.org> Roundup Robot added the comment: New changeset 503bf9dee28e by Senthil Kumaran in branch '3.4': Clarify BROWSER envar behavior in webbrowser.py. Noted by David Turner. Closes #21248 http://hg.python.org/cpython/rev/503bf9dee28e ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 05:45:08 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Thu, 17 Apr 2014 03:45:08 +0000 Subject: [issue21248] BROWSER env var described inaccurately in webbrowser docs In-Reply-To: <1397597825.94.0.182594358629.issue21248@psf.upfronthosting.co.za> Message-ID: <1397706308.53.0.364209833793.issue21248@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Thanks for the bug report. The documentation has been fixed in the active versions. ---------- versions: +Python 3.4, Python 3.5 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 06:00:54 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 17 Apr 2014 04:00:54 +0000 Subject: [issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k In-Reply-To: <1394697296.27.0.543058724281.issue20904@psf.upfronthosting.co.za> Message-ID: <3g8RYd5pnqz7LjP@mail.python.org> Roundup Robot added the comment: New changeset c2f6551c9eaf by Benjamin Peterson in branch 'default': support setting fpu precision on m68k (closes #20904) http://hg.python.org/cpython/rev/c2f6551c9eaf ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 06:29:37 2014 From: report at bugs.python.org (Martin Panter) Date: Thu, 17 Apr 2014 04:29:37 +0000 Subject: [issue21259] replace "except: pass" by "except Exception: pass" In-Reply-To: <1397671015.92.0.0555120458036.issue21259@psf.upfronthosting.co.za> Message-ID: <1397708977.85.0.721802608093.issue21259@psf.upfronthosting.co.za> Martin Panter added the comment: If you do go ahead and add ?except Exception? clauses, maybe look around at what other exceptions are being handled. The other day I stumbled across this in ?tkinter.font? module: try: ... except (KeyboardInterrupt, SystemExit): raise except Exception: pass It would have been simpler (and semantically equivalent) to write try: ... except Exception: pass ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 06:50:41 2014 From: report at bugs.python.org (Martin Panter) Date: Thu, 17 Apr 2014 04:50:41 +0000 Subject: [issue21279] str.translate documentation incomplete In-Reply-To: <1397696482.87.0.486412592823.issue21279@psf.upfronthosting.co.za> Message-ID: <1397710241.69.0.376564673868.issue21279@psf.upfronthosting.co.za> Martin Panter added the comment: I suspect ?iterable? is the wrong term. >>> isinstance(set(), Iterable) True >>> "abc".translate(set()) TypeError: 'set' object does not support indexing >>> "abc".translate(object()) TypeError: 'object' object is not subscriptable Maybe ?indexable? or ?subscriptable? would be more correct? If this behaviour is part of the API, it would be nice to document, because it would have saved me a few times from implementing the __len__() and __iter__() methods of the mapping interface in my custom lookup tables. Here is my suggestion: str.translate(table): Return a copy of the string where all characters have been mapped through ?table?, a lookup table. The lookup table must be a subscriptable object, for instance a dictionary or list, mapping Unicode ordinals (integers) to Unicode ordinals, strings or None. If a character is not in the table, the subscript operation should raise LookupError, and the character is left untouched. Characters mapped to None are deleted. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 06:58:58 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 17 Apr 2014 04:58:58 +0000 Subject: [issue16286] Use hash if available to optimize a==b and a!=b for bytes and str In-Reply-To: <1350650166.87.0.27478619259.issue16286@psf.upfronthosting.co.za> Message-ID: <1397710738.12.0.152615447685.issue16286@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > Serhiy, Gregory, Raymond, Antoine: so what is your feeling on > this issue? Is it worth it? I don't think it is worth it. There may be some cases that benefit, but it adds extra branching code to the common cases (sets and dicts) that already have the identity check. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 07:08:45 2014 From: report at bugs.python.org (Martin Panter) Date: Thu, 17 Apr 2014 05:08:45 +0000 Subject: [issue21071] struct.Struct.format is bytes, but should be str In-Reply-To: <1395856133.5.0.672707015318.issue21071@psf.upfronthosting.co.za> Message-ID: <1397711325.69.0.802957117126.issue21071@psf.upfronthosting.co.za> Martin Panter added the comment: This is closely related to Issue 16349. If format strings were explicitly allowed to be byte strings there would be less conflict, but documenting the data type of the ?format? attribute is better than nothing. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 07:11:19 2014 From: report at bugs.python.org (Martin Panter) Date: Thu, 17 Apr 2014 05:11:19 +0000 Subject: [issue16349] Document whether it's safe to use bytes for struct format string In-Reply-To: <1351428222.6.0.656645524198.issue16349@psf.upfronthosting.co.za> Message-ID: <1397711479.97.0.176912174026.issue16349@psf.upfronthosting.co.za> Martin Panter added the comment: The issue of Struct.format being a byte string has been raised separately in Issue 21071. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 07:42:13 2014 From: report at bugs.python.org (Martin Panter) Date: Thu, 17 Apr 2014 05:42:13 +0000 Subject: [issue1062] nice to have a way to tell if a socket is bound In-Reply-To: <1188496399.92.0.368162629574.issue1062@psf.upfronthosting.co.za> Message-ID: <1397713333.4.0.489054348015.issue1062@psf.upfronthosting.co.za> Martin Panter added the comment: The suggested subclass might have to call the default bind(("", 0)) before running certain other operations, including connect(), send[to](), recv[from](), since these operations are meant to automatically bind if necessary. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 07:45:54 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Thu, 17 Apr 2014 05:45:54 +0000 Subject: [issue21272] use _sysconfigdata.py in distutils.sysconfig to initialize distutils.sysconfig In-Reply-To: <1397686328.42.0.129070062942.issue21272@psf.upfronthosting.co.za> Message-ID: <1397713554.93.0.107732056724.issue21272@psf.upfronthosting.co.za> ?ric Araujo added the comment: Because removing distutils.sysconfig would break things. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 07:52:34 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 17 Apr 2014 05:52:34 +0000 Subject: [issue18879] tempfile.NamedTemporaryFile can close the file too early, if not assigning to a variable In-Reply-To: <1377807943.36.0.898364678904.issue18879@psf.upfronthosting.co.za> Message-ID: <1397713954.0.0.657398182233.issue18879@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- title: tempfile.NamedTemporaryFile can close the file too early, if not assigning to a variablwe -> tempfile.NamedTemporaryFile can close the file too early, if not assigning to a variable _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 08:02:31 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Thu, 17 Apr 2014 06:02:31 +0000 Subject: [issue5904] strftime docs do not explain locale effect on result string In-Reply-To: <1241270739.12.0.286821632978.issue5904@psf.upfronthosting.co.za> Message-ID: <1397714551.55.0.719281911398.issue5904@psf.upfronthosting.co.za> ?ric Araujo added the comment: This may help: http://blog.codekills.net/2013/04/13/strftime--table-of-locale-aware-formatters-in-different-locales/ ---------- nosy: +wolever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 08:20:32 2014 From: report at bugs.python.org (Georg Brandl) Date: Thu, 17 Apr 2014 06:20:32 +0000 Subject: [issue21240] Add an abstactmethod directive to the Python ReST domain In-Reply-To: <1397577446.45.0.129673687933.issue21240@psf.upfronthosting.co.za> Message-ID: <1397715632.42.0.566376177406.issue21240@psf.upfronthosting.co.za> Georg Brandl added the comment: LGTM without having tested it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 08:23:14 2014 From: report at bugs.python.org (David Wolever) Date: Thu, 17 Apr 2014 06:23:14 +0000 Subject: [issue5904] strftime docs do not explain locale effect on result string In-Reply-To: <1241270739.12.0.286821632978.issue5904@psf.upfronthosting.co.za> Message-ID: <1397715794.15.0.739173015587.issue5904@psf.upfronthosting.co.za> David Wolever added the comment: It may also be worth noting that the strftime formatters table now includes examples from different locales: https://docs.python.org/2/library/datetime.html#strftime-strptime-behavior This change was introduced about a year ago. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 08:41:59 2014 From: report at bugs.python.org (Vivek Jain) Date: Thu, 17 Apr 2014 06:41:59 +0000 Subject: [issue21106] Updated Mac folder icon In-Reply-To: <1396214057.84.0.0230664527626.issue21106@psf.upfronthosting.co.za> Message-ID: <1397716919.22.0.500072019179.issue21106@psf.upfronthosting.co.za> Vivek Jain added the comment: No reply from Apple yet, so I'm guessing at this stage they won't be responding. Does anyone have any contacts at Apple they could nudge to have a look at this? :) The other option is to recreate something that looks like Apple's folder icon but isn't. There is a tutorial at http://www.tutorial9.net/tutorials/photoshop-tutorials/photoshop-tutorial-design-the-mac-os-x-leopard-folder/ (I actually used the tutorial to create the current icon, but I only used step 10). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 08:49:56 2014 From: report at bugs.python.org (Martin Panter) Date: Thu, 17 Apr 2014 06:49:56 +0000 Subject: [issue16484] pydoc generates invalid docs.python.org link for xml.etree.ElementTree and other modules In-Reply-To: <1353062789.06.0.457819088795.issue16484@psf.upfronthosting.co.za> Message-ID: <1397717396.46.0.364072997797.issue16484@psf.upfronthosting.co.za> Martin Panter added the comment: I don?t think these ones could be so easily fixed, but on my computer ?pydoc? references: * library/importlib.machinery.html (ideally should be library/importlib.html#module-importlib.machinery) * library/tkinter.font.html (not in Python documentation at all that I am aware, except for brief mention in ?25.1.1) ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 08:52:05 2014 From: report at bugs.python.org (Martin Panter) Date: Thu, 17 Apr 2014 06:52:05 +0000 Subject: [issue1191964] asynchronous Subprocess Message-ID: <1397717525.87.0.490221749935.issue1191964@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 09:05:32 2014 From: report at bugs.python.org (Martin Panter) Date: Thu, 17 Apr 2014 07:05:32 +0000 Subject: [issue21108] Add examples for importlib in doc In-Reply-To: <1396240944.13.0.279884654032.issue21108@psf.upfronthosting.co.za> Message-ID: <1397718332.7.0.353104697148.issue21108@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 09:06:51 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 17 Apr 2014 07:06:51 +0000 Subject: [issue21207] urandom persistent fd - not re-openned after fd close In-Reply-To: <1397692507.45.0.975882535953.issue21207@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: I was expecting to see such a report :-) I'm al for the st_ino+st_dev check, it can't hurt. But everybody must keep in mind that if another thread messes with the FD between the check and the read, there's nothing we can do... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 09:08:06 2014 From: report at bugs.python.org (Josiah Carlson) Date: Thu, 17 Apr 2014 07:08:06 +0000 Subject: [issue1191964] asynchronous Subprocess Message-ID: <1397718486.03.0.829407142933.issue1191964@psf.upfronthosting.co.za> Josiah Carlson added the comment: Victor, I addressed the majority of your comments except for a couple stylistic pieces. Your annoyance with the short poll time for Windows made me re-read the docs from MS, which made me realize that my interpretation was wrong. It also made me confirm Richard Oudkerk's earlier note about ReadFile on overlapped IOs. I left similar notes next to your comments. On the method naming side of things, note that you can only write to "stdin", and you can only read from "stdout" or "stderr". This is documented behavior, so I believe the method names are already quite reasonable (and BDFL approved ;)). ---------- Added file: http://bugs.python.org/file34941/subprocess_6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 09:09:00 2014 From: report at bugs.python.org (Alex Lord) Date: Thu, 17 Apr 2014 07:09:00 +0000 Subject: [issue16864] sqlite3.Cursor.lastrowid isn't populated when executing a SQL REPLACE statement In-Reply-To: <1357320260.32.0.764505068506.issue16864@psf.upfronthosting.co.za> Message-ID: <1397718540.27.0.815008784689.issue16864@psf.upfronthosting.co.za> Alex Lord added the comment: Have a unit test that replicates this bug. Working on the C code to fix it right now. ---------- nosy: +Alex.Lord _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 09:13:34 2014 From: report at bugs.python.org (Nitika Agarwal) Date: Thu, 17 Apr 2014 07:13:34 +0000 Subject: [issue4744] asynchat documentation needs to be more precise In-Reply-To: <1230168171.56.0.381937953807.issue4744@psf.upfronthosting.co.za> Message-ID: <1397718814.75.0.479089429887.issue4744@psf.upfronthosting.co.za> Nitika Agarwal added the comment: But then I have submitted another patch issue4744_3 with the corrections.Please review my patch issue4744_3.patch ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 09:19:26 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 17 Apr 2014 07:19:26 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397677682.58.0.634690184444.issue21233@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: Do you have benchmarks? (I'm not looking for an improvement, just no regression.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 09:22:45 2014 From: report at bugs.python.org (Richard Oudkerk) Date: Thu, 17 Apr 2014 07:22:45 +0000 Subject: [issue1191964] asynchronous Subprocess In-Reply-To: <1397718486.03.0.829407142933.issue1191964@psf.upfronthosting.co.za> Message-ID: Richard Oudkerk added the comment: If you use the short timeouts to make the wait interruptible then you can use waitformultipleobjects (which automatically waits on an extra event object) instead of waitforsingleobject. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 09:25:28 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 17 Apr 2014 07:25:28 +0000 Subject: [issue21106] Updated Mac folder icon In-Reply-To: <1396214057.84.0.0230664527626.issue21106@psf.upfronthosting.co.za> Message-ID: <1397719528.78.0.721015352969.issue21106@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I see. I read the tutorial as actually giving permission to use these very shapes and forms for an icon. So if the resulting icon is (or could be) the result of following these steps, my layman's interpretation is that we have permission to use it. However, the PSF has legal council for exactly this question. Please ask psf at python.org (with reference to this issue) whether they want to have a say in this, and if so, what their legal advise is. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 09:54:01 2014 From: report at bugs.python.org (Christoph Gohlke) Date: Thu, 17 Apr 2014 07:54:01 +0000 Subject: [issue17213] ctypes loads wrong version of C runtime, leading to error message box from system In-Reply-To: <1360992800.86.0.617349310494.issue17213@psf.upfronthosting.co.za> Message-ID: <1397721241.71.0.20552868087.issue17213@psf.upfronthosting.co.za> Changes by Christoph Gohlke : ---------- nosy: +cgohlke _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 10:04:36 2014 From: report at bugs.python.org (Julian Taylor) Date: Thu, 17 Apr 2014 08:04:36 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1397721876.63.0.0895099478176.issue21233@psf.upfronthosting.co.za> Julian Taylor added the comment: won't replacing _PyObject_GC_Malloc with a calloc cause Var objects (PyObject_NewVar) to be completely zeroed which I think they didn't before? Some numeric programs stuff a lot of data into var objects and could care about python suddenly setting them to zero when they don't need it. An example would be tinyarray. ---------- nosy: +jtaylor _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 10:09:59 2014 From: report at bugs.python.org (Martin Panter) Date: Thu, 17 Apr 2014 08:09:59 +0000 Subject: [issue21280] shutil.make_archive() with default "root_dir" parameter raises FileNotFoundError: [Errno 2] No such file or directory: '' Message-ID: <1397722199.92.0.999945404475.issue21280@psf.upfronthosting.co.za> New submission from Martin Panter: >>> from shutil import make_archive; make_archive("a", "tar") Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.4/shutil.py", line 783, in make_archive filename = func(base_name, base_dir, **kwargs) File "/usr/lib/python3.4/shutil.py", line 605, in _make_tarball os.makedirs(archive_dir) File "/usr/lib/python3.4/os.py", line 244, in makedirs mkdir(name, mode) FileNotFoundError: [Errno 2] No such file or directory: '' Looking at the code, it calls os.path.dirname("a.tar") -> "", which would be the cause of this bug. The workaround for me was adding an explicit make_archive(root_dir=".") parameter. I was also surprised to see the code calling os.makedirs(archive_dir). Usually if you try to make a file in a non-existent directory, it fails, rather than automatically creating the directory for you. But maybe that?s just a general spirit of the ?shutil? module that I didn?t pick up on. ---------- components: Library (Lib) messages: 216672 nosy: vadmium priority: normal severity: normal status: open title: shutil.make_archive() with default "root_dir" parameter raises FileNotFoundError: [Errno 2] No such file or directory: '' versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 10:27:37 2014 From: report at bugs.python.org (Ned Deily) Date: Thu, 17 Apr 2014 08:27:37 +0000 Subject: [issue5150] IDLE to support reindent.py In-Reply-To: <1233736664.4.0.115705275626.issue5150@psf.upfronthosting.co.za> Message-ID: <1397723257.75.0.337153504869.issue5150@psf.upfronthosting.co.za> Ned Deily added the comment: The code needs to be updated for Python 3 and it needs a test. I'm deassigning it in the hopes that someone will feel free to pick it up. ---------- assignee: ned.deily -> stage: commit review -> patch review versions: +Python 3.5 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 10:40:06 2014 From: report at bugs.python.org (Giampaolo Rodola') Date: Thu, 17 Apr 2014 08:40:06 +0000 Subject: [issue19500] Error when connecting to FTPS servers not supporting SSL session resuming In-Reply-To: <1383624130.64.0.185541289049.issue19500@psf.upfronthosting.co.za> Message-ID: <1397724006.53.0.489718972593.issue19500@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: Interesting, I wasn't aware of this FTP(S) feature. Unfortunately RFC-4217 really doesn't say much about how this should be done but it definitively looks like something worth having. AFAIU this looks like something which should be implemented by servers though, not clients. ---------- nosy: +giampaolo.rodola versions: -Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 10:41:36 2014 From: report at bugs.python.org (Martin Panter) Date: Thu, 17 Apr 2014 08:41:36 +0000 Subject: [issue21109] tarfile: Traversal attack vulnerability In-Reply-To: <1396253659.12.0.842636239516.issue21109@psf.upfronthosting.co.za> Message-ID: <1397724096.17.0.178140787736.issue21109@psf.upfronthosting.co.za> Martin Panter added the comment: Seems like shutil._unpack_tarfile() is affected. I guess it could at least do with one of those warnings in the documentation for make_archive(). The patch for this bug looks a bit over enthusiastic, for example skip_prefixes("blaua../stuff") would incorrectly strip the first bit and just return "stuff". It seems there might already be plenty of existing code to check for bad paths. Examples that come to mind: * http.server.SimpleHTTPRequestHandler.translate_path() * zipfile.ZipFile._extract_member() * shutil._unpack_zipfile() This code either ignores the bad path elements, or ignores the whole path. Perhaps some of it could be recycled into a common function somewhere, rather than implementing it all over again for tar files. I have written my own function joinpath() to do this sort of checking, which you are welcome to use: https://bitbucket.org/vadmium/pyrescene/src/34264f6/rescene/utility.py#cl-217 You would call it with something like joinpath(tarpath.split("/"), osdir). ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 10:44:47 2014 From: report at bugs.python.org (eryksun) Date: Thu, 17 Apr 2014 08:44:47 +0000 Subject: [issue20309] Not all method descriptors are callable In-Reply-To: <1390200218.06.0.45732778516.issue20309@psf.upfronthosting.co.za> Message-ID: <1397724287.29.0.31663804255.issue20309@psf.upfronthosting.co.za> eryksun added the comment: classmethod_descriptor instances such as vars(dict)['fromkeys'] are callable. The first argument has to be a subclass of __objclass__: >>> vars(dict)['fromkeys'].__objclass__ Calling the descriptor creates a bound built-in method; slices the args to remove the class; and calls it with the args and kwds. >>> vars(dict)['fromkeys'](dict, 'abc') {'a': None, 'b': None, 'c': None} source: classmethoddescr_call http://hg.python.org/cpython/file/04f714765c13/Objects/descrobject.c#l256 While the classmethod and staticmethod types that are defined in funcobject.c aren't callable, they do expose a __func__ member. ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 10:52:07 2014 From: report at bugs.python.org (Sebastian Jylanki) Date: Thu, 17 Apr 2014 08:52:07 +0000 Subject: [issue21281] DEBUGGING: Simultaneous stopping of all threads on breakpoint and switching between threads Message-ID: <1397724727.36.0.728876639251.issue21281@psf.upfronthosting.co.za> New submission from Sebastian Jylanki: When debugging with some of the other very popular tools like GDB all the threads are halted when a breakpoint is hit on any of the threads. Then threads can be switched and analyzed separately at the current state of execution. When debugging with PDB only the thread that hits the breakpoint is halted. This makes it quite hard to debug multi-threaded programs (like IO based programs). Also it's annoying that the console output will be shown from other threads when the debugger is stopped. I think it would be extremely helpful for many people to have PDB behave like GDB when debugging multithreaded applications: halt execution on all threads when breakpoint is hit and continue execution on all threads when execution is continued from the debugger. ---------- components: Interpreter Core messages: 216677 nosy: azyr priority: normal severity: normal status: open title: DEBUGGING: Simultaneous stopping of all threads on breakpoint and switching between threads type: enhancement versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 11:12:28 2014 From: report at bugs.python.org (Martin Panter) Date: Thu, 17 Apr 2014 09:12:28 +0000 Subject: [issue20198] xml.etree.ElementTree.ElementTree.write attribute sorting In-Reply-To: <1389231308.67.0.0933451284696.issue20198@psf.upfronthosting.co.za> Message-ID: <1397725948.89.0.41635159721.issue20198@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 11:33:32 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 17 Apr 2014 09:33:32 +0000 Subject: [issue5150] IDLE to support reindent.py In-Reply-To: <1233736664.4.0.115705275626.issue5150@psf.upfronthosting.co.za> Message-ID: <1397727212.25.0.0374222491385.issue5150@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I use rstrip routinely when editing idlelib files, before committing, so it has been useful for that purpose. I do not happen to know what reindent.py does that the current format options do not. #18704 was about integrating the pep8 style checker. That was closed in favor of adding a generic facility to run external analysis tools. There is not an open issue for that yet, but I expect it to happen, perhaps this summer. Reindent.py, if maybe improved, might be a candidate, though I will also try to look at the patch sometime. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 11:42:46 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 17 Apr 2014 09:42:46 +0000 Subject: [issue19500] Error when connecting to FTPS servers not supporting SSL session resuming In-Reply-To: <1383624130.64.0.185541289049.issue19500@psf.upfronthosting.co.za> Message-ID: <1397727766.15.0.523926565497.issue19500@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Yuck. Is there a public FTP server available somewhere with this "feature"? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 11:57:05 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 17 Apr 2014 09:57:05 +0000 Subject: [issue19500] Error when connecting to FTPS servers not supporting SSL session resuming In-Reply-To: <1383624130.64.0.185541289049.issue19500@psf.upfronthosting.co.za> Message-ID: <1397728625.77.0.116033435415.issue19500@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The RFC is unhelpfully lousy. It's not enough to process a "522" error, since that can be triggered for different reasons. You also somehow have to interpret the error text to detect that session reuse is indeed mandated by the server. Regardless, to progress with this we would first need to implement client-side SSL session reuse, which necessitates a bunch of additional APIs (since which session is to be reused is a decision made by user code), and a new opaque type to carry SSL_SESSION objects... (see issue #8106) ---------- nosy: +christian.heimes, dstufft, janssen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 12:35:42 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Thu, 17 Apr 2014 10:35:42 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1397730942.23.0.503973801708.issue21233@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Julian: No. See the diff: http://bugs.python.org/review/21233/diff/11644/Objects/typeobject.c The original GC_Malloc was explicitly memset-ing after confirming that it received a non-NULL pointer from the underlying malloc call; that memset is removed in favor of using the calloc call. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 12:39:32 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Thu, 17 Apr 2014 10:39:32 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1397731172.29.0.88529649383.issue21233@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Well, to be more specific, PyType_GenericAlloc was originally calling one of two methods that didn't zero the memory (one of which was GC_Malloc), then memset-ing. Just realized you're talking about something else; not sure if you're correct about this now, but I have to get to work, will check later if no one else does. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 12:43:16 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Thu, 17 Apr 2014 10:43:16 +0000 Subject: [issue21279] str.translate documentation incomplete In-Reply-To: <1397696482.87.0.486412592823.issue21279@psf.upfronthosting.co.za> Message-ID: <1397731396.33.0.0205968308226.issue21279@psf.upfronthosting.co.za> Josh Rosenberg added the comment: For the record, I have intentionally used bytes.maketrans to make translation table for str.translate for precisely this reason; it's much faster to look up a ordinal in a bytes object than in a dictionary. Before the recent (partial) patch for str.translate performance (#21118), this was a huge improvement if you only needed to worry about latin-1 characters (though encoding to latin-1, using bytes.translate, then decoding again was still faster). It's still faster than using a dictionary even with the patch from #21118, but it's not nearly as significant. ---------- nosy: +josh.rosenberg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 12:47:27 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 17 Apr 2014 10:47:27 +0000 Subject: [issue8106] SSL session management In-Reply-To: <1268184052.67.0.269640299758.issue8106@psf.upfronthosting.co.za> Message-ID: <1397731647.89.0.0434876893851.issue8106@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 13:09:22 2014 From: report at bugs.python.org (Lukas Vacek) Date: Thu, 17 Apr 2014 11:09:22 +0000 Subject: [issue21282] setup.py: More informative error msg for modules which built but failed import check Message-ID: <1397732962.82.0.641060383961.issue21282@psf.upfronthosting.co.za> New submission from Lukas Vacek: Hey, Currently when a module builds successfully during cpython build but it can't be imported (import check around line 330 in setup.py) the module shows in "Failed to build these modules: " which can be misleading. Especially when linking against libraries in non-standard locations the user would set LD_FLAGS and CPPFLAGS and then ... wonder why the cpython build process is not picking the libraries up and the module is not built. I think the modules which *have built* but were removed because of a failed import check should be marked as such so the user knows what happens and can take appropriate actions (set LD_LIBRARY_PATH as well, for example). A patch attached - it's a very simple change (about 10 lines), created with "hg export". Thanks, Lucas ---------- components: Build files: setup_failed_import_hgexport messages: 216684 nosy: Lukas.Vacek priority: normal severity: normal status: open title: setup.py: More informative error msg for modules which built but failed import check type: enhancement versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file34942/setup_failed_import_hgexport _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 13:09:25 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 17 Apr 2014 11:09:25 +0000 Subject: [issue8106] SSL session management In-Reply-To: <1268184052.67.0.269640299758.issue8106@psf.upfronthosting.co.za> Message-ID: <1397732965.24.0.0947179268841.issue8106@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok, I propose the following plan: - add a new opaque type allowing to wrap a SSL_SESSION - add a get_session() method to SSLSocket, returning the current session - add an optional "session=..." parameter to SSLContext.wrap_socket, allowing to specify a session which we hope to reuse during the handshake There is however, one complication (from OpenSSL man pages): """SSL_SESSION objects keep internal link information about the session cache list, when being inserted into one SSL_CTX object's session cache. One SSL_SESSION object, regardless of its reference count, must therefore only be used with one SSL_CTX object (and the SSL objects created from this SSL_CTX object).""" So we would somehow also need to keep a pointer to the SSL context in our session object wrapper, and check that the session isn't reused with another context... (yuck) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 13:11:28 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 17 Apr 2014 11:11:28 +0000 Subject: [issue21281] DEBUGGING: Simultaneous stopping of all threads on breakpoint and switching between threads In-Reply-To: <1397724727.36.0.728876639251.issue21281@psf.upfronthosting.co.za> Message-ID: <1397733088.02.0.252252483543.issue21281@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 13:35:08 2014 From: report at bugs.python.org (Julian Taylor) Date: Thu, 17 Apr 2014 11:35:08 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1397734508.38.0.983834730461.issue21233@psf.upfronthosting.co.za> Julian Taylor added the comment: I just tested it, PyObject_NewVar seems to use RawMalloc not the GC malloc so its probably fine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 15:54:45 2014 From: report at bugs.python.org (Tito Bouzout) Date: Thu, 17 Apr 2014 13:54:45 +0000 Subject: [issue21283] A escape character is used when a REGEXP is an argument of "strip" string function Message-ID: <1397742885.45.0.765313151501.issue21283@psf.upfronthosting.co.za> New submission from Tito Bouzout: Hello! I got a report that the character "\" was removed from a string using the following code > "\\server\path\to".strip(r'"\'<>') At first insight, looks like a bug, because I don't expect the use of the escape character at all. Then I noticed, that our mistake there is that the "strip" argument should be a "string" not a REGEXP. Kinda weird to read, and I've no idea if this is expected behaviour in Python, as I'm relatively very new. So just informing, Kind regards, -- Tito ---------- components: Regular Expressions messages: 216687 nosy: Tito.Bouzout, ezio.melotti, mrabarnett priority: normal severity: normal status: open title: A escape character is used when a REGEXP is an argument of "strip" string function type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 16:09:48 2014 From: report at bugs.python.org (Matthew Barnett) Date: Thu, 17 Apr 2014 14:09:48 +0000 Subject: [issue21283] A escape character is used when a REGEXP is an argument of "strip" string function In-Reply-To: <1397742885.45.0.765313151501.issue21283@psf.upfronthosting.co.za> Message-ID: <1397743788.5.0.788189369099.issue21283@psf.upfronthosting.co.za> Matthew Barnett added the comment: The argument isn't a regex, it's a raw string literal consisting of the characters " (quote), \ (backslash), ' (apostrophe), < (less than) and > (greater than). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 16:14:08 2014 From: report at bugs.python.org (=?utf-8?q?Petr_Dlouh=C3=BD?=) Date: Thu, 17 Apr 2014 14:14:08 +0000 Subject: [issue15276] unicode format does not really work in Python 2.x In-Reply-To: <1341668447.61.0.319523039673.issue15276@psf.upfronthosting.co.za> Message-ID: <1397744048.59.0.888358478179.issue15276@psf.upfronthosting.co.za> Petr Dlouh? added the comment: For anyone stuck on Python 2.x, here is an workaround (maybe it could find it's way to documentation also): def fix_grouping(bytestring): try: return unicode(bytestring) except UnicodeDecodeError: return bytestring.decode("utf-8") ---------- nosy: +petr.dlouhy at email.cz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 16:31:55 2014 From: report at bugs.python.org (Christian Theune) Date: Thu, 17 Apr 2014 14:31:55 +0000 Subject: [issue12489] email.errors.HeaderParseError if base64url is used In-Reply-To: <1309790300.23.0.111625308862.issue12489@psf.upfronthosting.co.za> Message-ID: <1397745115.3.0.650120393767.issue12489@psf.upfronthosting.co.za> Christian Theune added the comment: So, in addition to "+/" and "-_" there are quite a few base64 variants. Worst thing: there are the two ambigious variants "-_" and "_-", even though "_-" supposedly is "non-standard" for its use. See http://en.wikipedia.org/wiki/Base64 The shortest fix I can see would be to not use binascii directly from the email module but go through the base64 module (as pointed out by the blogpost) and call the urlsafe version. That should catch both cases. Preparing a patch right now. ---------- nosy: +ctheune, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 16:35:19 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 17 Apr 2014 14:35:19 +0000 Subject: [issue21273] don't defined socket constants which are not implemented for GNU/Hurd In-Reply-To: <1397687407.58.0.755430574464.issue21273@psf.upfronthosting.co.za> Message-ID: <1397745319.7.0.793667155597.issue21273@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I'm not sure this is a good idea. In general, we expose whatever libc defines, and let it give ENOSYS (or similar) errors if the underlying system doesn't actually support the behavior. Presumably, the Hurd might implement SO_REUSEPORT at some point. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 16:35:52 2014 From: report at bugs.python.org (Josiah Carlson) Date: Thu, 17 Apr 2014 14:35:52 +0000 Subject: [issue1191964] asynchronous Subprocess Message-ID: <1397745352.4.0.334020802302.issue1191964@psf.upfronthosting.co.za> Josiah Carlson added the comment: Richard: short timeouts are no longer an issue. Nothing to worry about :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 16:36:20 2014 From: report at bugs.python.org (Christian Theune) Date: Thu, 17 Apr 2014 14:36:20 +0000 Subject: [issue12489] email.errors.HeaderParseError if base64url is used In-Reply-To: <1309790300.23.0.111625308862.issue12489@psf.upfronthosting.co.za> Message-ID: <1397745380.11.0.180515264295.issue12489@psf.upfronthosting.co.za> Changes by Christian Theune : ---------- hgrepos: +239 versions: +Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 16:36:25 2014 From: report at bugs.python.org (Christian Theune) Date: Thu, 17 Apr 2014 14:36:25 +0000 Subject: [issue12489] email.errors.HeaderParseError if base64url is used In-Reply-To: <1309790300.23.0.111625308862.issue12489@psf.upfronthosting.co.za> Message-ID: <1397745385.66.0.381027239636.issue12489@psf.upfronthosting.co.za> Changes by Christian Theune : ---------- hgrepos: +240 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 16:38:22 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 17 Apr 2014 14:38:22 +0000 Subject: [issue21273] don't defined socket constants which are not implemented for GNU/Hurd In-Reply-To: <1397687407.58.0.755430574464.issue21273@psf.upfronthosting.co.za> Message-ID: <1397745502.02.0.618335702046.issue21273@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Indeed, this complicates the conditional defines for no obvious benefit. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 16:50:33 2014 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 17 Apr 2014 14:50:33 +0000 Subject: [issue21283] A escape character is used when a REGEXP is an argument of "strip" string function In-Reply-To: <1397742885.45.0.765313151501.issue21283@psf.upfronthosting.co.za> Message-ID: <1397746233.46.0.987484386143.issue21283@psf.upfronthosting.co.za> Eric V. Smith added the comment: In addition, you probably want "\\server\path\to" to be a raw string, too. That way, the backslashes are not given special meaning. Notice the difference in output between these two: >>> "\\server\path\to".strip(r'"\'<>') 'server\\path\to' >>> r"\\server\path\to".strip(r'"\'<>') 'server\\path\\to' In the first one, '\t' is being treated as a tab character, in the second one you see a backslash followed by a 't'. My rule of thumb is: any time you have a string with a filename containing backslashes, you want it to be a raw string. ---------- components: -Regular Expressions nosy: +eric.smith resolution: -> not a bug stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 17:06:50 2014 From: report at bugs.python.org (Christian Theune) Date: Thu, 17 Apr 2014 15:06:50 +0000 Subject: [issue12489] email.errors.HeaderParseError if base64url is used In-Reply-To: <1309790300.23.0.111625308862.issue12489@psf.upfronthosting.co.za> Message-ID: <1397747210.83.0.570062141884.issue12489@psf.upfronthosting.co.za> Changes by Christian Theune : ---------- keywords: +patch Added file: http://bugs.python.org/file34943/62b280b61de7.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 17:07:07 2014 From: report at bugs.python.org (Christian Theune) Date: Thu, 17 Apr 2014 15:07:07 +0000 Subject: [issue12489] email.errors.HeaderParseError if base64url is used In-Reply-To: <1309790300.23.0.111625308862.issue12489@psf.upfronthosting.co.za> Message-ID: <1397747227.76.0.0203700063288.issue12489@psf.upfronthosting.co.za> Changes by Christian Theune : Added file: http://bugs.python.org/file34944/732e7d4515c0.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 17:19:39 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 17 Apr 2014 15:19:39 +0000 Subject: [issue21284] IDLE reformat tests fail in presence of non-default FormatParagraph setting Message-ID: <1397747979.02.0.575213731893.issue21284@psf.upfronthosting.co.za> New submission from Raymond Hettinger: When a user sets FormatParagraph to anything other than 70, test_idle.py has 4 failing tests: test_comment_block (idlelib.idle_test.test_formatparagraph.FormatEventTest) ... FAIL test_long_line (idlelib.idle_test.test_formatparagraph.FormatEventTest) ... FAIL test_multiple_lines (idlelib.idle_test.test_formatparagraph.FormatEventTest) ... FAIL test_short_line (idlelib.idle_test.test_formatparagraph.FormatEventTest) ... FAIL The solution is to make these tests setup by: 1) save the user's default configuration 2) set the paragraph reformat width to 70 and tear-down by: 1) restoring the user's default configuration ---------- components: IDLE keywords: easy messages: 216695 nosy: rhettinger priority: normal severity: normal stage: needs patch status: open title: IDLE reformat tests fail in presence of non-default FormatParagraph setting type: behavior versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 17:19:52 2014 From: report at bugs.python.org (Sam Kimbrel) Date: Thu, 17 Apr 2014 15:19:52 +0000 Subject: [issue18374] ast.parse gives wrong position (col_offset) for some BinOp-s In-Reply-To: <1373103302.65.0.774257874247.issue18374@psf.upfronthosting.co.za> Message-ID: <1397747992.26.0.282324215793.issue18374@psf.upfronthosting.co.za> Sam Kimbrel added the comment: Here's a patch that corrects col_offset for binops in both the ast module and in the compiler proper. I've incorporated Aivar's test into test_ast.py; if there are test suites for compile.c please let me know and I can add something there too. ---------- keywords: +patch nosy: +sam.kimbrel Added file: http://bugs.python.org/file34945/18374-binop-col-offset-with-test.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 17:29:18 2014 From: report at bugs.python.org (Christian Theune) Date: Thu, 17 Apr 2014 15:29:18 +0000 Subject: [issue1514420] Missing module code does spurious file search Message-ID: <1397748558.97.0.460153569971.issue1514420@psf.upfronthosting.co.za> Christian Theune added the comment: I don't think the security risk exists due to this bug. As Python is searching for various places anyway, an attacker could just symlink one of those places anyway instead of ''. ---------- nosy: +ctheune _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 17:46:43 2014 From: report at bugs.python.org (Christian Theune) Date: Thu, 17 Apr 2014 15:46:43 +0000 Subject: [issue16285] Update urllib to RFC 3986 In-Reply-To: <1350644168.93.0.364254038155.issue16285@psf.upfronthosting.co.za> Message-ID: <1397749603.92.0.234356738984.issue16285@psf.upfronthosting.co.za> Christian Theune added the comment: I'll update this. ---------- nosy: +ctheune _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 17:51:29 2014 From: report at bugs.python.org (Berker Peksag) Date: Thu, 17 Apr 2014 15:51:29 +0000 Subject: [issue21259] replace "except: pass" by "except Exception: pass" In-Reply-To: <1397671015.92.0.0555120458036.issue21259@psf.upfronthosting.co.za> Message-ID: <1397749889.6.0.397347485033.issue21259@psf.upfronthosting.co.za> Berker Peksag added the comment: This looks like a duplicate of issue 16261. ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 17:51:39 2014 From: report at bugs.python.org (Matthias Klose) Date: Thu, 17 Apr 2014 15:51:39 +0000 Subject: [issue15234] avoid runtime library path for extensions found in system directories In-Reply-To: <1341131354.31.0.215672210129.issue15234@psf.upfronthosting.co.za> Message-ID: <1397749899.06.0.308466760904.issue15234@psf.upfronthosting.co.za> Matthias Klose added the comment: updated patch, reviewed by Thomas, checked that rpath is not added, and the the extensions still build. ---------- nosy: +twouters Added file: http://bugs.python.org/file34946/avoid-rpath.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 17:52:00 2014 From: report at bugs.python.org (Matthias Klose) Date: Thu, 17 Apr 2014 15:52:00 +0000 Subject: [issue15234] avoid runtime library path for extensions found in system directories In-Reply-To: <1341131354.31.0.215672210129.issue15234@psf.upfronthosting.co.za> Message-ID: <1397749920.54.0.0685019916737.issue15234@psf.upfronthosting.co.za> Changes by Matthias Klose : Removed file: http://bugs.python.org/file26222/rpath.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 17:55:48 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 17 Apr 2014 15:55:48 +0000 Subject: [issue15234] avoid runtime library path for extensions found in system directories In-Reply-To: <1341131354.31.0.215672210129.issue15234@psf.upfronthosting.co.za> Message-ID: <3g8lQX01fyz7Ljv@mail.python.org> Roundup Robot added the comment: New changeset 1a00e04a233d by doko in branch '3.4': - Issue #15234: For BerkelyDB and Sqlite, only add the found library and http://hg.python.org/cpython/rev/1a00e04a233d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 17:55:52 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 17 Apr 2014 15:55:52 +0000 Subject: [issue16285] Update urllib to RFC 3986 In-Reply-To: <1350644168.93.0.364254038155.issue16285@psf.upfronthosting.co.za> Message-ID: <1397750152.06.0.306564137066.issue16285@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 17:56:54 2014 From: report at bugs.python.org (Matthias Klose) Date: Thu, 17 Apr 2014 15:56:54 +0000 Subject: [issue15234] avoid runtime library path for extensions found in system directories In-Reply-To: <1341131354.31.0.215672210129.issue15234@psf.upfronthosting.co.za> Message-ID: <1397750214.13.0.357490792997.issue15234@psf.upfronthosting.co.za> Matthias Klose added the comment: fixed ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 17:56:56 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 17 Apr 2014 15:56:56 +0000 Subject: [issue16864] sqlite3.Cursor.lastrowid isn't populated when executing a SQL REPLACE statement In-Reply-To: <1357320260.32.0.764505068506.issue16864@psf.upfronthosting.co.za> Message-ID: <1397750216.53.0.0492610161961.issue16864@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- stage: -> needs patch type: enhancement -> behavior versions: +Python 3.4, Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 17:57:12 2014 From: report at bugs.python.org (Glenn Jones) Date: Thu, 17 Apr 2014 15:57:12 +0000 Subject: [issue9364] some problems with the documentation of pydoc In-Reply-To: <1279949027.26.0.1869842795.issue9364@psf.upfronthosting.co.za> Message-ID: <1397750232.04.0.669151004096.issue9364@psf.upfronthosting.co.za> Changes by Glenn Jones : Added file: http://bugs.python.org/file34947/_sitebuiltins-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 17:57:22 2014 From: report at bugs.python.org (Glenn Jones) Date: Thu, 17 Apr 2014 15:57:22 +0000 Subject: [issue9364] some problems with the documentation of pydoc In-Reply-To: <1279949027.26.0.1869842795.issue9364@psf.upfronthosting.co.za> Message-ID: <1397750242.36.0.296735322704.issue9364@psf.upfronthosting.co.za> Changes by Glenn Jones : Added file: http://bugs.python.org/file34948/pydoc-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 17:57:39 2014 From: report at bugs.python.org (Matthias Klose) Date: Thu, 17 Apr 2014 15:57:39 +0000 Subject: [issue21274] define PATH_MAX for GNU/Hurd in Python/pythonrun.c In-Reply-To: <1397687576.16.0.104530346632.issue21274@psf.upfronthosting.co.za> Message-ID: <1397750259.21.0.18618099549.issue21274@psf.upfronthosting.co.za> Changes by Matthias Klose : ---------- nosy: +twouters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 17:58:02 2014 From: report at bugs.python.org (Matthias Klose) Date: Thu, 17 Apr 2014 15:58:02 +0000 Subject: [issue21275] fix a socket test on KFreeBSD In-Reply-To: <1397687913.02.0.0778138511124.issue21275@psf.upfronthosting.co.za> Message-ID: <1397750282.98.0.358063523275.issue21275@psf.upfronthosting.co.za> Changes by Matthias Klose : ---------- nosy: +twouters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 17:58:44 2014 From: report at bugs.python.org (Christian Theune) Date: Thu, 17 Apr 2014 15:58:44 +0000 Subject: [issue16285] Update urllib quoting to RFC 3986 In-Reply-To: <1350644168.93.0.364254038155.issue16285@psf.upfronthosting.co.za> Message-ID: <1397750324.35.0.638860459609.issue16285@psf.upfronthosting.co.za> Changes by Christian Theune : ---------- title: Update urllib to RFC 3986 -> Update urllib quoting to RFC 3986 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 17:58:53 2014 From: report at bugs.python.org (Glenn Jones) Date: Thu, 17 Apr 2014 15:58:53 +0000 Subject: [issue9364] some problems with the documentation of pydoc In-Reply-To: <1279949027.26.0.1869842795.issue9364@psf.upfronthosting.co.za> Message-ID: <1397750333.22.0.246693520766.issue9364@psf.upfronthosting.co.za> Glenn Jones added the comment: I have added patches that replace the previous ones and apply to head. It appears that the other changes discussed (crosslinking and improving documentation) have already been done. ---------- nosy: +Glenn.Jones _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 17:59:09 2014 From: report at bugs.python.org (Matthias Klose) Date: Thu, 17 Apr 2014 15:59:09 +0000 Subject: [issue21276] don't define USE_XATTRS on kfreebsd and the Hurd In-Reply-To: <1397687995.9.0.529028609843.issue21276@psf.upfronthosting.co.za> Message-ID: <1397750349.7.0.919925386379.issue21276@psf.upfronthosting.co.za> Changes by Matthias Klose : ---------- nosy: +twouters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 17:59:55 2014 From: report at bugs.python.org (Matthias Klose) Date: Thu, 17 Apr 2014 15:59:55 +0000 Subject: [issue21277] don't try to link _ctypes with a ffi_convenience library In-Reply-To: <1397688266.23.0.303919517358.issue21277@psf.upfronthosting.co.za> Message-ID: <1397750395.22.0.235283721415.issue21277@psf.upfronthosting.co.za> Changes by Matthias Klose : ---------- nosy: +twouters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 18:04:16 2014 From: report at bugs.python.org (Christian Theune) Date: Thu, 17 Apr 2014 16:04:16 +0000 Subject: [issue16285] Update urllib quoting to RFC 3986 In-Reply-To: <1350644168.93.0.364254038155.issue16285@psf.upfronthosting.co.za> Message-ID: <1397750656.04.0.565110129145.issue16285@psf.upfronthosting.co.za> Changes by Christian Theune : ---------- hgrepos: +241 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 18:04:16 2014 From: report at bugs.python.org (Matthias Klose) Date: Thu, 17 Apr 2014 16:04:16 +0000 Subject: [issue21285] refactor anfd fix curses configure checks Message-ID: <1397750656.23.0.437739592471.issue21285@psf.upfronthosting.co.za> New submission from Matthias Klose: this refactors the curses configure checks, and fixes the build with ncursesw. In it's current form the curses feature checks are run without the additional include path which leads to wrong results if the only the nurses headers are installed. ---------- components: Build files: ncurses-configure.diff keywords: patch messages: 216704 nosy: doko priority: normal severity: normal status: open title: refactor anfd fix curses configure checks versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file34949/ncurses-configure.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 18:04:31 2014 From: report at bugs.python.org (Matthias Klose) Date: Thu, 17 Apr 2014 16:04:31 +0000 Subject: [issue21285] refactor anfd fix curses configure checks In-Reply-To: <1397750656.23.0.437739592471.issue21285@psf.upfronthosting.co.za> Message-ID: <1397750671.24.0.0196090767721.issue21285@psf.upfronthosting.co.za> Changes by Matthias Klose : ---------- versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 18:04:41 2014 From: report at bugs.python.org (Matthias Klose) Date: Thu, 17 Apr 2014 16:04:41 +0000 Subject: [issue21285] refactor anfd fix curses configure checks In-Reply-To: <1397750656.23.0.437739592471.issue21285@psf.upfronthosting.co.za> Message-ID: <1397750681.39.0.865207366996.issue21285@psf.upfronthosting.co.za> Changes by Matthias Klose : ---------- nosy: +twouters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 18:05:20 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 17 Apr 2014 16:05:20 +0000 Subject: [issue12489] email.errors.HeaderParseError if base64url is used In-Reply-To: <1309790300.23.0.111625308862.issue12489@psf.upfronthosting.co.za> Message-ID: <1397750720.06.0.970149974694.issue12489@psf.upfronthosting.co.za> R. David Murray added the comment: The patch looks good. I'd like the comment to say "We use urlsafe_b64decode here because some mailers apparently use the urlsafe b64 alphabet, and urlsafe_b64decode will correctly decode both the urlsafe and regular alphabets". Also, the new header parser doesn't handle this case either, and furthermore it doesn't handle binascii errors at all (my comment in the code indicates I didn't think it could ever raise there). The fact that it doesn't handle the error at all can be considered a different issue, but it would be nice to add the same decode fix (and a test in test_email/test_headerregistry.py) for the new header parser. Here's one way to reproduce the issue: >>> from email import message_from_string as mfs >>> from email.policy import default >>> m = mfs("From: =?iso-8859-1?B?QW5tZWxkdW5nIE5ldHphbnNjaGx1c3MgU_xkcmluZzNwLmpwZw==?=\n\n", policy=default) >>> m['From'] Traceback (most recent call last): File "/home/rdmurray/python/p34/Lib/email/_encoded_words.py", line 109, in decode_b return base64.b64decode(padded_encoded, validate=True), defects File "/home/rdmurray/python/p34/Lib/base64.py", line 89, in b64decode raise binascii.Error('Non-base64 digit found') binascii.Error: Non-base64 digit found During handling of the above exception, another exception occurred: Traceback (most recent call last): File "", line 1, in File "/home/rdmurray/python/p34/Lib/email/message.py", line 391, in __getitem__ return self.get(name) File "/home/rdmurray/python/p34/Lib/email/message.py", line 471, in get return self.policy.header_fetch_parse(k, v) File "/home/rdmurray/python/p34/Lib/email/policy.py", line 145, in header_fetch_parse return self.header_factory(name, ''.join(value.splitlines())) File "/home/rdmurray/python/p34/Lib/email/headerregistry.py", line 583, in __call__ return self[name](name, value) File "/home/rdmurray/python/p34/Lib/email/headerregistry.py", line 194, in __new__ cls.parse(value, kwds) File "/home/rdmurray/python/p34/Lib/email/headerregistry.py", line 334, in parse kwds['parse_tree'] = address_list = cls.value_parser(value) File "/home/rdmurray/python/p34/Lib/email/headerregistry.py", line 325, in value_parser address_list, value = parser.get_address_list(value) File "/home/rdmurray/python/p34/Lib/email/_header_value_parser.py", line 2313, in get_address_list token, value = get_address(value) File "/home/rdmurray/python/p34/Lib/email/_header_value_parser.py", line 2290, in get_address token, value = get_group(value) File "/home/rdmurray/python/p34/Lib/email/_header_value_parser.py", line 2246, in get_group token, value = get_display_name(value) File "/home/rdmurray/python/p34/Lib/email/_header_value_parser.py", line 2072, in get_display_name token, value = get_phrase(value) File "/home/rdmurray/python/p34/Lib/email/_header_value_parser.py", line 1747, in get_phrase token, value = get_word(value) File "/home/rdmurray/python/p34/Lib/email/_header_value_parser.py", line 1728, in get_word token, value = get_atom(value) File "/home/rdmurray/python/p34/Lib/email/_header_value_parser.py", line 1645, in get_atom token, value = get_encoded_word(value) File "/home/rdmurray/python/p34/Lib/email/_header_value_parser.py", line 1421, in get_encoded_word text, charset, lang, defects = _ew.decode('=?' + tok + '?=') File "/home/rdmurray/python/p34/Lib/email/_encoded_words.py", line 166, in decode bstring, defects = _cte_decoders[cte](bstring) File "/home/rdmurray/python/p34/Lib/email/_encoded_words.py", line 124, in decode_b raise AssertionError("unexpected binascii.Error") AssertionError: unexpected binascii.Error ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 18:05:23 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Thu, 17 Apr 2014 16:05:23 +0000 Subject: [issue16484] pydoc generates invalid docs.python.org link for xml.etree.ElementTree and other modules In-Reply-To: <1353062789.06.0.457819088795.issue16484@psf.upfronthosting.co.za> Message-ID: <1397750723.27.0.0692980757665.issue16484@psf.upfronthosting.co.za> ?ric Araujo added the comment: Brett, any opposition to moving the doc about importlib submodules to separate files? ---------- nosy: +brett.cannon versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 18:06:52 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Thu, 17 Apr 2014 16:06:52 +0000 Subject: [issue21268] Update pydoc module docstring In-Reply-To: <1397680012.16.0.887791975702.issue21268@psf.upfronthosting.co.za> Message-ID: <1397750812.53.0.856254770983.issue21268@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- resolution: -> duplicate stage: needs patch -> committed/rejected status: open -> closed superseder: -> some problems with the documentation of pydoc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 18:38:54 2014 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 17 Apr 2014 16:38:54 +0000 Subject: [issue21286] Refcounting information missing in docs for Python 3.4 and above. Message-ID: <1397752734.97.0.965637829315.issue21286@psf.upfronthosting.co.za> New submission from Mark Dickinson: It looks as though the information from refcounts.dat isn't making it into the online docs for 3.4 and 3.5. See e.g., the documentation for PyList_GetItem. For 3.3 [2], there's a "Return value: Borrowed reference." annotation supplied by Sphinx's refcounting extension. For the 3.4 and 3.5 docs that annotation is missing. Issue originally reported by Jianfeng Mao on the python-dev mailing list [1]. [1] https://mail.python.org/pipermail/python-dev/2014-April/134089.html [2] https://docs.python.org/3.3/c-api/list.html?highlight=pylist_getitem#PyList_GetItem ---------- assignee: docs at python components: Documentation messages: 216707 nosy: docs at python, mark.dickinson priority: normal severity: normal status: open title: Refcounting information missing in docs for Python 3.4 and above. versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 18:40:45 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 17 Apr 2014 16:40:45 +0000 Subject: [issue21286] Refcounting information missing in docs for Python 3.4 and above. In-Reply-To: <1397752734.97.0.965637829315.issue21286@psf.upfronthosting.co.za> Message-ID: <1397752845.61.0.608890601741.issue21286@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 18:43:03 2014 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 17 Apr 2014 16:43:03 +0000 Subject: [issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k In-Reply-To: <1394697296.27.0.543058724281.issue20904@psf.upfronthosting.co.za> Message-ID: <1397752983.39.0.116546733661.issue20904@psf.upfronthosting.co.za> Mark Dickinson added the comment: Yay! Thanks, Benjamin. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 18:43:03 2014 From: report at bugs.python.org (Brett Cannon) Date: Thu, 17 Apr 2014 16:43:03 +0000 Subject: [issue16484] pydoc generates invalid docs.python.org link for xml.etree.ElementTree and other modules In-Reply-To: <1353062789.06.0.457819088795.issue16484@psf.upfronthosting.co.za> Message-ID: <1397752983.86.0.661299675371.issue16484@psf.upfronthosting.co.za> Brett Cannon added the comment: No, I have no objections. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 18:44:23 2014 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 17 Apr 2014 16:44:23 +0000 Subject: [issue21286] Refcounting information missing in docs for Python 3.4 and above. In-Reply-To: <1397752734.97.0.965637829315.issue21286@psf.upfronthosting.co.za> Message-ID: <1397753063.87.0.907646158856.issue21286@psf.upfronthosting.co.za> Mark Dickinson added the comment: N.B. When I build the docs locally on the default branch (using 'make html' from the Docs directory on a clean checkout), I *do* see the refcounting annotations in the html output. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 18:46:38 2014 From: report at bugs.python.org (Christian Theune) Date: Thu, 17 Apr 2014 16:46:38 +0000 Subject: [issue16285] Update urllib quoting to RFC 3986 In-Reply-To: <1350644168.93.0.364254038155.issue16285@psf.upfronthosting.co.za> Message-ID: <1397753198.04.0.287293751324.issue16285@psf.upfronthosting.co.za> Changes by Christian Theune : ---------- hgrepos: +242 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 18:46:47 2014 From: report at bugs.python.org (Christian Theune) Date: Thu, 17 Apr 2014 16:46:47 +0000 Subject: [issue16285] Update urllib quoting to RFC 3986 In-Reply-To: <1350644168.93.0.364254038155.issue16285@psf.upfronthosting.co.za> Message-ID: <1397753207.25.0.776935974745.issue16285@psf.upfronthosting.co.za> Changes by Christian Theune : ---------- hgrepos: -242 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 18:47:03 2014 From: report at bugs.python.org (Christian Theune) Date: Thu, 17 Apr 2014 16:47:03 +0000 Subject: [issue16285] Update urllib quoting to RFC 3986 In-Reply-To: <1350644168.93.0.364254038155.issue16285@psf.upfronthosting.co.za> Message-ID: <1397753223.58.0.746467345491.issue16285@psf.upfronthosting.co.za> Changes by Christian Theune : ---------- keywords: +patch Added file: http://bugs.python.org/file34950/0be3805cade1.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 18:47:08 2014 From: report at bugs.python.org (Christian Theune) Date: Thu, 17 Apr 2014 16:47:08 +0000 Subject: [issue16285] Update urllib quoting to RFC 3986 In-Reply-To: <1350644168.93.0.364254038155.issue16285@psf.upfronthosting.co.za> Message-ID: <1397753228.64.0.434315526306.issue16285@psf.upfronthosting.co.za> Changes by Christian Theune : ---------- versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 18:58:22 2014 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Thu, 17 Apr 2014 16:58:22 +0000 Subject: [issue20434] Fix error handler of _PyString_Resize() on allocation failure In-Reply-To: <1390984600.38.0.476358983499.issue20434@psf.upfronthosting.co.za> Message-ID: <1397753902.46.0.347061158001.issue20434@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Add comments and explicit (void) on the ignored value from _PyString_Resize as suggested by Victor ---------- Added file: http://bugs.python.org/file34951/string_resize.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 19:15:56 2014 From: report at bugs.python.org (Thomas Wouters) Date: Thu, 17 Apr 2014 17:15:56 +0000 Subject: [issue21274] define PATH_MAX for GNU/Hurd in Python/pythonrun.c In-Reply-To: <1397687576.16.0.104530346632.issue21274@psf.upfronthosting.co.za> Message-ID: <1397754956.76.0.800634774096.issue21274@psf.upfronthosting.co.za> Thomas Wouters added the comment: You should put the definition closer to the Windows one (right after or before it) rather than further down the file. Other than that, looks good. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 19:16:30 2014 From: report at bugs.python.org (Thomas Wouters) Date: Thu, 17 Apr 2014 17:16:30 +0000 Subject: [issue21275] fix a socket test on KFreeBSD In-Reply-To: <1397687913.02.0.0778138511124.issue21275@psf.upfronthosting.co.za> Message-ID: <1397754990.88.0.394111456019.issue21275@psf.upfronthosting.co.za> Thomas Wouters added the comment: Looks good. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 19:17:14 2014 From: report at bugs.python.org (Thomas Wouters) Date: Thu, 17 Apr 2014 17:17:14 +0000 Subject: [issue21276] don't define USE_XATTRS on kfreebsd and the Hurd In-Reply-To: <1397687995.9.0.529028609843.issue21276@psf.upfronthosting.co.za> Message-ID: <1397755034.8.0.780696975362.issue21276@psf.upfronthosting.co.za> Thomas Wouters added the comment: Looks good. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 19:29:45 2014 From: report at bugs.python.org (Chris Monsanto) Date: Thu, 17 Apr 2014 17:29:45 +0000 Subject: [issue10740] sqlite3 module breaks transactions and potentially corrupts data In-Reply-To: <1292868135.81.0.257293444934.issue10740@psf.upfronthosting.co.za> Message-ID: <1397755785.53.0.789482759811.issue10740@psf.upfronthosting.co.za> Chris Monsanto added the comment: This issue has been open for 4 years, last update was 2 months ago. Lack of transactional DDL is a big deal for Python programs that use SQLite heavily. We have a patch for Python 3 that applies cleanly and as far as I can tell works fine. I've been using it in testing for months, and I'm about to deploy it in production. What's the next step here? What do we need to do to get something merged? ---------- nosy: +monsanto _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 19:49:09 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 17 Apr 2014 17:49:09 +0000 Subject: [issue21276] don't define USE_XATTRS on kfreebsd and the Hurd In-Reply-To: <1397687995.9.0.529028609843.issue21276@psf.upfronthosting.co.za> Message-ID: <3g8nxJ5PVYz7Ljh@mail.python.org> Roundup Robot added the comment: New changeset ca2edbefca35 by doko in branch '3.4': Fixes for KFreeBSD and the Hurd: http://hg.python.org/cpython/rev/ca2edbefca35 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 19:49:10 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 17 Apr 2014 17:49:10 +0000 Subject: [issue21275] fix a socket test on KFreeBSD In-Reply-To: <1397687913.02.0.0778138511124.issue21275@psf.upfronthosting.co.za> Message-ID: <3g8nxK3jtYz7Ljh@mail.python.org> Roundup Robot added the comment: New changeset ca2edbefca35 by doko in branch '3.4': Fixes for KFreeBSD and the Hurd: http://hg.python.org/cpython/rev/ca2edbefca35 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 19:49:10 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 17 Apr 2014 17:49:10 +0000 Subject: [issue21274] define PATH_MAX for GNU/Hurd in Python/pythonrun.c In-Reply-To: <1397687576.16.0.104530346632.issue21274@psf.upfronthosting.co.za> Message-ID: <3g8nxL2LfNz7Ljv@mail.python.org> Roundup Robot added the comment: New changeset ca2edbefca35 by doko in branch '3.4': Fixes for KFreeBSD and the Hurd: http://hg.python.org/cpython/rev/ca2edbefca35 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 19:49:51 2014 From: report at bugs.python.org (Thomas Wouters) Date: Thu, 17 Apr 2014 17:49:51 +0000 Subject: [issue21285] refactor anfd fix curses configure checks In-Reply-To: <1397750656.23.0.437739592471.issue21285@psf.upfronthosting.co.za> Message-ID: <1397756991.72.0.21359995095.issue21285@psf.upfronthosting.co.za> Thomas Wouters added the comment: Good fix. Do remove the 'first curses header check' comment you add, and don't forget to regenerate configure (and maybe pyconfig.h.in? I don't know if that'll change.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 19:54:15 2014 From: report at bugs.python.org (Ned Deily) Date: Thu, 17 Apr 2014 17:54:15 +0000 Subject: [issue21286] Refcounting information missing in docs for Python 3.4 and above. In-Reply-To: <1397752734.97.0.965637829315.issue21286@psf.upfronthosting.co.za> Message-ID: <1397757255.47.0.236446294316.issue21286@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 20:12:11 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Thu, 17 Apr 2014 18:12:11 +0000 Subject: [issue15887] urlencode should accept iterables of pairs In-Reply-To: <1347185937.29.0.747427121658.issue15887@psf.upfronthosting.co.za> Message-ID: <1397758331.38.0.053122779987.issue15887@psf.upfronthosting.co.za> ?ric Araujo added the comment: >> "Convert a mapping object or a sequence of two-element tuples, which >> may either be a str or a bytes, to a ?percent-encoded? string." > > Mappings, duple sequences, and duples cannot be str or bytes. The only thing making sense to me here is that ?which? refers to ?element?. Rephrased: Convert a mapping or sequence of two-element tuples, where each mapping key or each first element in the tuples may be str or bytes. ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 20:14:41 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 17 Apr 2014 18:14:41 +0000 Subject: [issue21285] refactor anfd fix curses configure checks In-Reply-To: <1397750656.23.0.437739592471.issue21285@psf.upfronthosting.co.za> Message-ID: <3g8pVm4sCNz7LjY@mail.python.org> Roundup Robot added the comment: New changeset 1bc0a8310b9f by doko in branch '2.7': - Issue #21285: Refactor and fix curses configure check to always search http://hg.python.org/cpython/rev/1bc0a8310b9f New changeset 635817da596d by doko in branch '3.4': - Issue #21285: Refactor and fix curses configure check to always search http://hg.python.org/cpython/rev/635817da596d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 20:22:20 2014 From: report at bugs.python.org (Matthias Klose) Date: Thu, 17 Apr 2014 18:22:20 +0000 Subject: [issue21285] refactor anfd fix curses configure checks In-Reply-To: <1397750656.23.0.437739592471.issue21285@psf.upfronthosting.co.za> Message-ID: <1397758940.8.0.46329572138.issue21285@psf.upfronthosting.co.za> Matthias Klose added the comment: looks like with this change the curses extension isn't built anymore on Solaris. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 20:22:56 2014 From: report at bugs.python.org (Matthias Klose) Date: Thu, 17 Apr 2014 18:22:56 +0000 Subject: [issue21285] refactor and fix curses configure checks In-Reply-To: <1397750656.23.0.437739592471.issue21285@psf.upfronthosting.co.za> Message-ID: <1397758976.18.0.278194009787.issue21285@psf.upfronthosting.co.za> Changes by Matthias Klose : ---------- title: refactor anfd fix curses configure checks -> refactor and fix curses configure checks _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 20:29:22 2014 From: report at bugs.python.org (Matthias Klose) Date: Thu, 17 Apr 2014 18:29:22 +0000 Subject: [issue21274] define PATH_MAX for GNU/Hurd in Python/pythonrun.c In-Reply-To: <1397687576.16.0.104530346632.issue21274@psf.upfronthosting.co.za> Message-ID: <1397759362.49.0.205942848912.issue21274@psf.upfronthosting.co.za> Matthias Klose added the comment: fixed ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 20:29:51 2014 From: report at bugs.python.org (Matthias Klose) Date: Thu, 17 Apr 2014 18:29:51 +0000 Subject: [issue21275] fix a socket test on KFreeBSD In-Reply-To: <1397687913.02.0.0778138511124.issue21275@psf.upfronthosting.co.za> Message-ID: <1397759391.62.0.290550101961.issue21275@psf.upfronthosting.co.za> Matthias Klose added the comment: fixed ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 20:30:32 2014 From: report at bugs.python.org (Matthias Klose) Date: Thu, 17 Apr 2014 18:30:32 +0000 Subject: [issue21276] don't define USE_XATTRS on kfreebsd and the Hurd In-Reply-To: <1397687995.9.0.529028609843.issue21276@psf.upfronthosting.co.za> Message-ID: <1397759432.23.0.711431202027.issue21276@psf.upfronthosting.co.za> Matthias Klose added the comment: fixed ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 20:34:25 2014 From: report at bugs.python.org (Christian Theune) Date: Thu, 17 Apr 2014 18:34:25 +0000 Subject: [issue10362] AttributeError: addinfourl instance has no attribute 'tell' In-Reply-To: <1289237897.0.0.279670034262.issue10362@psf.upfronthosting.co.za> Message-ID: <1397759665.91.0.869278236514.issue10362@psf.upfronthosting.co.za> Christian Theune added the comment: I don't think this will be solved. File-like objects (in this case IO wrappers for the socket) may have different capabilities and tarfile is just expecting too much. My patch for #15002 relieved the situation somewhat by providing tell() but the IO stream just isn't seekable. I think you'll have to download to a temporary file first to give tarfile all the capabilities it needs. I guess this should be rejected. ---------- nosy: +ctheune, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 20:39:07 2014 From: report at bugs.python.org (=?utf-8?b?0JjQs9C+0YDRjCDQn9Cw0YjQtdCy?=) Date: Thu, 17 Apr 2014 18:39:07 +0000 Subject: [issue21287] Better support for AF_PACKET on opensolaris (illumos) Message-ID: <1397759947.91.0.17620010785.issue21287@psf.upfronthosting.co.za> New submission from ????? ?????: SIOCGIFINDEX could be defined in illumos (aka OpenSolaris) if BSD_COMP macro defined. This causes known error: no member ifr_ifindex in struct ifreq. But OpenSolaris provides newer interface with struct lifreq and SIOCGLIFINDEX. Attached patch tries to use it. ---------- components: Library (Lib) files: dyson-socketmodule-ifindex.patch keywords: patch messages: 216727 nosy: ?????.????? priority: normal severity: normal status: open title: Better support for AF_PACKET on opensolaris (illumos) type: compile error versions: Python 3.4 Added file: http://bugs.python.org/file34952/dyson-socketmodule-ifindex.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 20:44:53 2014 From: report at bugs.python.org (Armin Ronacher) Date: Thu, 17 Apr 2014 18:44:53 +0000 Subject: [issue21288] hashlib.pbkdf2_hmac Hash Constructor Message-ID: <1397760292.99.0.128790868195.issue21288@psf.upfronthosting.co.za> New submission from Armin Ronacher: Is there a specific reason why hashlib.pbkdf2_hmac now has a completely inconsistent API with the rest of the stdlib? So far the concept in both hashlib and hmac has been to accept hash constructors as parameters. As such you would expect the API to look like this: hashlib.pbkdf2_hmac(hashlib.sha256, b'password', b'salt', 100000) Instead the API now is string based. This is annoying because a lot of code already in the past exposed a pbkdf2 implementation that allows passing in a hashlib constructor by passing it to HMAC. If such code now wants to use the stdlib pbkdf2_hmac implementation it has to special case known implementations. If a non known implementation is found it needs to dispatch to a separate implementation of PBKDF2. In addition to that there is no nice way to detect if a algorithm is not supported as the exception raised for an invalid algorithm is the same as an invalid parameter for the iteration count (ValueError). I would propose to change the API to allow hash constructors to be passed in in addition to strings. ---------- messages: 216728 nosy: aronacher priority: normal severity: normal status: open title: hashlib.pbkdf2_hmac Hash Constructor versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 20:45:33 2014 From: report at bugs.python.org (Christian Theune) Date: Thu, 17 Apr 2014 18:45:33 +0000 Subject: [issue10362] AttributeError: addinfourl instance has no attribute 'tell' In-Reply-To: <1289237897.0.0.279670034262.issue10362@psf.upfronthosting.co.za> Message-ID: <1397760333.24.0.592037581076.issue10362@psf.upfronthosting.co.za> Christian Theune added the comment: Not being an export on tar at all, but I tried getting anything working without tell() and seek() but couldn't. The code reads as if its supposed to support some tar formats that do not require seeking, but that would be rather hard to predict on a file-by-file basis, I guess. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 20:46:12 2014 From: report at bugs.python.org (Alex Gaynor) Date: Thu, 17 Apr 2014 18:46:12 +0000 Subject: [issue21288] hashlib.pbkdf2_hmac Hash Constructor In-Reply-To: <1397760292.99.0.128790868195.issue21288@psf.upfronthosting.co.za> Message-ID: <1397760372.5.0.979600898134.issue21288@psf.upfronthosting.co.za> Changes by Alex Gaynor : ---------- nosy: +alex _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 20:54:27 2014 From: report at bugs.python.org (Armin Ronacher) Date: Thu, 17 Apr 2014 18:54:27 +0000 Subject: [issue21288] hashlib.pbkdf2_hmac Hash Constructor In-Reply-To: <1397760292.99.0.128790868195.issue21288@psf.upfronthosting.co.za> Message-ID: <1397760867.02.0.608975599659.issue21288@psf.upfronthosting.co.za> Armin Ronacher added the comment: This commit shows why the API is problematic: https://github.com/mitsuhiko/werkzeug/commit/c527dcbfb0ee621e9faa0a3a2873118438965800 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 20:59:19 2014 From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=) Date: Thu, 17 Apr 2014 18:59:19 +0000 Subject: [issue18159] ConfigParser getters not available on SectionProxy In-Reply-To: <1370627030.12.0.961792763365.issue18159@psf.upfronthosting.co.za> Message-ID: <1397761159.49.0.990992903856.issue18159@psf.upfronthosting.co.za> Jo?o Bernardo added the comment: ping? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 20:59:42 2014 From: report at bugs.python.org (Eric Snow) Date: Thu, 17 Apr 2014 18:59:42 +0000 Subject: [issue20309] Not all method descriptors are callable In-Reply-To: <1390200218.06.0.45732778516.issue20309@psf.upfronthosting.co.za> Message-ID: <1397761182.94.0.345293679388.issue20309@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 21:15:50 2014 From: report at bugs.python.org (aaugustin) Date: Thu, 17 Apr 2014 19:15:50 +0000 Subject: [issue10740] sqlite3 module breaks transactions and potentially corrupts data In-Reply-To: <1292868135.81.0.257293444934.issue10740@psf.upfronthosting.co.za> Message-ID: <1397762150.58.0.959746588025.issue10740@psf.upfronthosting.co.za> aaugustin added the comment: Hey -- maintainer of Django's transaction support here. This ticket was brought to my attention again today. As I know a few things about this issue and I see Python core devs asking for input, I'll give my $0.02. The core of this issue is that, **by default**, the sqlite3 module performs a simplistic parsing of SQL queries and decides to commit before anything it doesn't understand, for example "SAVEPOINT foo". I don't think it's a good idea to change sqlite's default operation mode to autocommit. PEP 249's prescription for transaction management aren't practical (and Django enforces the opposite behavior by default) but that's beyond the point. It's way too much backwards incompatible. However, I don't think it's a good idea either to automatically send a COMMIT when I want to make a SAVEPOINT. In fact, if you want to use transactions with sqlite, connection.isolation_level = None is almost warranted -- and then you do everything manually. For a slightly longer explanation, see https://www.youtube.com/watch?v=09tM18_st4I#t=1751 I've struggled mightily with all this when rewriting Django's transaction management. See: - https://github.com/django/django/blob/3becac84/django/db/backends/sqlite3/base.py#L107 https://github.com/django/django/blob/3becac84/django/db/backends/sqlite3/base.py#L398-L403 - https://github.com/django/django/blob/3becac84/django/db/transaction.py#L185-L195 I have implemented the workarounds I need and I we won't be able to remove them from Django anytime soon. As a consequence, I have little interest in getting this fixed. Still, it would be sane to stop committing before savepoints by default -- that kinda ruins the concept of savepoints :-) It would be even saner to stop parsing SQL. Does http://hg.python.org/cpython/file/85fd955c6fc8/Modules/_sqlite/cursor.c#l32 look like an adequate parser for http://sqlite.org/lang.html? Unfortunately, I don't have backwards-compatible proposal to fix this. Trying to account for a bit more syntax will help in the short term but not fix the underlying issue. PS: I find it unfair to brand SQLite as a neutered database engine. Its transaction model is vastly superior to, say, MySQL. Too bad sqlite3 ruins it. ---------- nosy: +aaugustin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 21:25:21 2014 From: report at bugs.python.org (Eric Snow) Date: Thu, 17 Apr 2014 19:25:21 +0000 Subject: [issue16484] pydoc generates invalid docs.python.org link for xml.etree.ElementTree and other modules In-Reply-To: <1353062789.06.0.457819088795.issue16484@psf.upfronthosting.co.za> Message-ID: <1397762721.37.0.349483625618.issue16484@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 21:53:21 2014 From: report at bugs.python.org (Donald Stufft) Date: Thu, 17 Apr 2014 19:53:21 +0000 Subject: [issue21288] hashlib.pbkdf2_hmac Hash Constructor In-Reply-To: <1397760292.99.0.128790868195.issue21288@psf.upfronthosting.co.za> Message-ID: <1397764401.17.0.344960970593.issue21288@psf.upfronthosting.co.za> Donald Stufft added the comment: I agree that this change makes a lot of sense. ---------- nosy: +dstufft _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 22:01:12 2014 From: report at bugs.python.org (Chris Monsanto) Date: Thu, 17 Apr 2014 20:01:12 +0000 Subject: [issue10740] sqlite3 module breaks transactions and potentially corrupts data In-Reply-To: <1292868135.81.0.257293444934.issue10740@psf.upfronthosting.co.za> Message-ID: <1397764872.15.0.00715565210278.issue10740@psf.upfronthosting.co.za> Chris Monsanto added the comment: > Unfortunately, I don't have backwards-compatible proposal to fix this. Trying to account for a bit more syntax will help in the short term but not fix the underlying issue. aaugustin -- the patch by torsen made 3 years ago is backwards compatible. It adds a hook that you can use to disable autocommits, but you have to opt-in. I think that is good enough for now. We can worry about how to transition people away from the broken transaction model in the future. Let's treat this as any other backwards compatibility problem in Python. We have a flag, that when enabled, removes the shitty behavior. In a future release, you get a warning for relying on the shitty behavior. In a release after that, we kill the old behavior. Then we deprecate the flag. In other words, it literally doesn't matter what the flag is. torsen's is fine. We just need some way to enable transactional DDL. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 22:04:55 2014 From: report at bugs.python.org (Alex Lord) Date: Thu, 17 Apr 2014 20:04:55 +0000 Subject: [issue16864] sqlite3.Cursor.lastrowid isn't populated when executing a SQL REPLACE statement In-Reply-To: <1357320260.32.0.764505068506.issue16864@psf.upfronthosting.co.za> Message-ID: <1397765095.74.0.398524713772.issue16864@psf.upfronthosting.co.za> Alex Lord added the comment: Patch that fixes Issue16864. Follows Jim Minters suggestion. Unit test will reproduce the issue without the c modifications. C modifications fix the issue. ---------- keywords: +patch Added file: http://bugs.python.org/file34953/Issue16864_py35.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 22:10:36 2014 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 17 Apr 2014 20:10:36 +0000 Subject: [issue21288] hashlib.pbkdf2_hmac Hash Constructor In-Reply-To: <1397760292.99.0.128790868195.issue21288@psf.upfronthosting.co.za> Message-ID: <1397765436.25.0.737394750882.issue21288@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +yselivanov versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 22:12:21 2014 From: report at bugs.python.org (Matthias Klose) Date: Thu, 17 Apr 2014 20:12:21 +0000 Subject: [issue21285] refactor and fix curses configure checks In-Reply-To: <1397750656.23.0.437739592471.issue21285@psf.upfronthosting.co.za> Message-ID: <1397765541.78.0.409495410644.issue21285@psf.upfronthosting.co.za> Matthias Klose added the comment: Victor pointer out the Solaris issue is unrelated. See #13552. Closing. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 22:14:03 2014 From: report at bugs.python.org (Dave Sawyer) Date: Thu, 17 Apr 2014 20:14:03 +0000 Subject: [issue21289] make.bat not building documentation Message-ID: <1397765643.91.0.331086007996.issue21289@psf.upfronthosting.co.za> New submission from Dave Sawyer: With Python 3.5, some refactoring of the documentation structure has been done. Building the documentation targets directly works, but using the supplied make.bat fails, not finding the sphinx python file. ---------- assignee: docs at python components: Documentation messages: 216737 nosy: docs at python, dsawyer priority: normal severity: normal status: open title: make.bat not building documentation type: compile error versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 22:15:48 2014 From: report at bugs.python.org (Dave Sawyer) Date: Thu, 17 Apr 2014 20:15:48 +0000 Subject: [issue21289] make.bat not building documentation In-Reply-To: <1397765643.91.0.331086007996.issue21289@psf.upfronthosting.co.za> Message-ID: <1397765748.83.0.640669164917.issue21289@psf.upfronthosting.co.za> Changes by Dave Sawyer : ---------- type: compile error -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 22:20:36 2014 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 17 Apr 2014 20:20:36 +0000 Subject: [issue21288] hashlib.pbkdf2_hmac Hash Constructor In-Reply-To: <1397760292.99.0.128790868195.issue21288@psf.upfronthosting.co.za> Message-ID: <1397766036.0.0.410210492023.issue21288@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +christian.heimes, gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 22:23:54 2014 From: report at bugs.python.org (Ned Deily) Date: Thu, 17 Apr 2014 20:23:54 +0000 Subject: [issue21287] Better support for AF_PACKET on opensolaris (illumos) In-Reply-To: <1397759947.91.0.17620010785.issue21287@psf.upfronthosting.co.za> Message-ID: <1397766234.57.0.556674025462.issue21287@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 22:43:46 2014 From: report at bugs.python.org (aaugustin) Date: Thu, 17 Apr 2014 20:43:46 +0000 Subject: [issue10740] sqlite3 module breaks transactions and potentially corrupts data In-Reply-To: <1292868135.81.0.257293444934.issue10740@psf.upfronthosting.co.za> Message-ID: <1397767426.6.0.13137648705.issue10740@psf.upfronthosting.co.za> aaugustin added the comment: That patch solves the problem, at the cost of introducing an unwieldy API, "operation_needs_transaction_callback". I'm very skeptical of the other API, "in_transaction". Other database backends usually provide an "autocommit" attribute. "autocommit" is the opposite of "in_transaction" for all practical purposes. There's only two situations where they may be equal: - before the first query - after an explicit commit Then you aren't in a transaction and you aren't in autocommit. But in these cases, in practice, the question you want to ask is "is the next query going to create a transaction?" (and if not, I may want to create one.) So the semantic of "connection.autocommit" is much more useful than the semantic of "connection.in_transaction". While you're there, it would be cool to provide "connection.autocommit = True" as an API to enable autocommit, because "connection.isolation_level = None" isn't a good API at all -- it's very obscure and has nothing to do with isolation level whatsoever. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 22:53:45 2014 From: report at bugs.python.org (Dave Sawyer) Date: Thu, 17 Apr 2014 20:53:45 +0000 Subject: [issue21289] make.bat not building documentation In-Reply-To: <1397765643.91.0.331086007996.issue21289@psf.upfronthosting.co.za> Message-ID: <1397768025.19.0.0807885293962.issue21289@psf.upfronthosting.co.za> Changes by Dave Sawyer : ---------- keywords: +patch Added file: http://bugs.python.org/file34954/mywork.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 22:55:12 2014 From: report at bugs.python.org (Dave Sawyer) Date: Thu, 17 Apr 2014 20:55:12 +0000 Subject: [issue21289] make.bat not building documentation In-Reply-To: <1397765643.91.0.331086007996.issue21289@psf.upfronthosting.co.za> Message-ID: <1397768112.49.0.74978456284.issue21289@psf.upfronthosting.co.za> Dave Sawyer added the comment: Removed the use of python in the make, calling the sphinx-build executable. Also the Doc directory was called "Docs" in the readme.txt ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 22:58:53 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 17 Apr 2014 20:58:53 +0000 Subject: [issue10740] sqlite3 module breaks transactions and potentially corrupts data In-Reply-To: <1292868135.81.0.257293444934.issue10740@psf.upfronthosting.co.za> Message-ID: <1397768333.43.0.520302765741.issue10740@psf.upfronthosting.co.za> Antoine Pitrou added the comment: What is the callback thing for? The only value that's ever passed in the tests is `lambda operation: True`. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 23:02:24 2014 From: report at bugs.python.org (Christian Heimes) Date: Thu, 17 Apr 2014 21:02:24 +0000 Subject: [issue21288] hashlib.pbkdf2_hmac Hash Constructor In-Reply-To: <1397766036.05.0.929161656883.issue21288@psf.upfronthosting.co.za> Message-ID: Christian Heimes added the comment: A callable wouldn't work for the OpenSSL back end of PBKDF2. The function takes a digest pointer. I have to think about a solution... Sorry for the brevity, I still don't have proper internet at home. On 17. April 2014 22:20:36 MESZ, Yury Selivanov wrote: > >Changes by Yury Selivanov : > > >---------- >nosy: +christian.heimes, gregory.p.smith > >_______________________________________ >Python tracker > >_______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 23:05:32 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 17 Apr 2014 21:05:32 +0000 Subject: [issue1514420] Traceback display code can attempt to open a file named "" Message-ID: <1397768732.5.0.395861478755.issue1514420@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The problem is not in the import, but when displaying the traceback of the exception. In other words, if you catch the exception, no attempt to open "" happens: $ strace -e open ./python [...] Python 3.5.0a0 (default:3417a95df7e2, Apr 16 2014, 17:57:12) [GCC 4.8.1] on linux [...] >>> >>> try: import dismal ... except ImportError: pass ... >>> ---------- nosy: +pitrou priority: normal -> low stage: test needed -> title: Missing module code does spurious file search -> Traceback display code can attempt to open a file named "" versions: +Python 3.5 -Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 23:06:38 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 17 Apr 2014 21:06:38 +0000 Subject: [issue1514420] Traceback display code can attempt to open a file named "" Message-ID: <1397768798.26.0.969773585674.issue1514420@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Also, by construction it will only happen if the import happens under the interpreter prompt (hence the "" filename). I honestly don't think this deserves introducing some complication, only to avoid a couple filesystem accesses. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 23:09:59 2014 From: report at bugs.python.org (Zachary Ware) Date: Thu, 17 Apr 2014 21:09:59 +0000 Subject: [issue21289] make.bat not building documentation In-Reply-To: <1397765643.91.0.331086007996.issue21289@psf.upfronthosting.co.za> Message-ID: <1397768999.7.0.277432636098.issue21289@psf.upfronthosting.co.za> Zachary Ware added the comment: I left a review on Rietveld, which should have sent you an email. Thanks for the report and patch! If you plan on submitting anything more than the most trivial of patches, could you please sign the contributor agreement[1][2]? Thanks! [1]The form: https://www.python.org/psf/contrib/contrib-form/ [2]More information: https://www.python.org/psf/contrib/ ---------- assignee: docs at python -> zach.ware nosy: +zach.ware stage: -> patch review versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 23:16:17 2014 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 17 Apr 2014 21:16:17 +0000 Subject: [issue2771] Test issue In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za> Message-ID: <1397769377.37.0.532740989322.issue2771@psf.upfronthosting.co.za> Ezio Melotti added the comment: Ping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 23:16:48 2014 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 17 Apr 2014 21:16:48 +0000 Subject: [issue2771] Test issue In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za> Message-ID: <1397769408.62.0.605785524174.issue2771@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 23:17:07 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 17 Apr 2014 21:17:07 +0000 Subject: [issue2771] Test issue In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za> Message-ID: <1397769427.47.0.43321787213.issue2771@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- stage: committed/rejected -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 23:21:12 2014 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 17 Apr 2014 21:21:12 +0000 Subject: [issue21288] hashlib.pbkdf2_hmac Hash Constructor In-Reply-To: Message-ID: <535045C6.6070609@gmail.com> Yury Selivanov added the comment: On 2014-04-17, 5:02 PM, Christian Heimes wrote: > Christian Heimes added the comment: > > A callable wouldn't work for the OpenSSL back end of PBKDF2. The function takes a digest pointer. I have to think about a solution... > > Sorry for the brevity, I still don't have proper internet at home. > We can accept only hashlib functions, and continue passing their names to the OpenSSL backend. A bit ugly and limited solution (no user-defined hash functions) for a better looking API. Yury ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 23:33:30 2014 From: report at bugs.python.org (Armin Ronacher) Date: Thu, 17 Apr 2014 21:33:30 +0000 Subject: [issue21288] hashlib.pbkdf2_hmac Hash Constructor In-Reply-To: <1397760292.99.0.128790868195.issue21288@psf.upfronthosting.co.za> Message-ID: <1397770410.16.0.0625014647164.issue21288@psf.upfronthosting.co.za> Armin Ronacher added the comment: > We can accept only hashlib functions, and continue passing their names > to the OpenSSL backend. A bit ugly and limited solution (no user-defined > hash functions) for a better looking API. What I'm doing at the code for my employer is something similar. There is a PBKDF2 implementation on top of the hmac module. If a hashlib constructor is detected that OpenSSL implements it dispatches that to the PBKDF2 path in OpenSSL via ctypes. Ultimately it's the same situation but it does not expose the implementation detail. ---------- versions: +Python 3.4 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 23:34:19 2014 From: report at bugs.python.org (Armin Ronacher) Date: Thu, 17 Apr 2014 21:34:19 +0000 Subject: [issue21288] hashlib.pbkdf2_hmac Hash Constructor In-Reply-To: <1397760292.99.0.128790868195.issue21288@psf.upfronthosting.co.za> Message-ID: <1397770459.93.0.539702231938.issue21288@psf.upfronthosting.co.za> Armin Ronacher added the comment: I should add that we still support non OpenSSL hashers, but we go a different path. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 23:36:08 2014 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 17 Apr 2014 21:36:08 +0000 Subject: [issue2771] Test issue In-Reply-To: <1397769427.51.0.01641214072.issue2771@psf.upfronthosting.co.za> Message-ID: Ezio Melotti added the comment: mail pong ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 23:36:11 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 17 Apr 2014 21:36:11 +0000 Subject: [issue21282] setup.py: More informative error msg for modules which built but failed import check In-Reply-To: <1397732962.82.0.641060383961.issue21282@psf.upfronthosting.co.za> Message-ID: <1397770571.23.0.213306341355.issue21282@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever versions: -Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 23:38:33 2014 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 17 Apr 2014 21:38:33 +0000 Subject: [issue21288] hashlib.pbkdf2_hmac Hash Constructor In-Reply-To: <1397760292.99.0.128790868195.issue21288@psf.upfronthosting.co.za> Message-ID: <1397770713.88.0.133533601107.issue21288@psf.upfronthosting.co.za> Yury Selivanov added the comment: Armin, FWIW, I don't think it's possible to push this API change in 3.4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 23:39:03 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 17 Apr 2014 21:39:03 +0000 Subject: [issue21272] use _sysconfigdata.py in distutils.sysconfig to initialize distutils.sysconfig In-Reply-To: <1397686328.42.0.129070062942.issue21272@psf.upfronthosting.co.za> Message-ID: <1397770743.34.0.584276708408.issue21272@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: Maybe distutils.sysconfig could become a small wrapper around sysconfig? ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 23:42:34 2014 From: report at bugs.python.org (Aaron Briel) Date: Thu, 17 Apr 2014 21:42:34 +0000 Subject: [issue21290] imaplib.error when importing email package Message-ID: <1397770954.41.0.647416164199.issue21290@psf.upfronthosting.co.za> New submission from Aaron Briel: I see an error when attempting to import the email package on a mac running Python 2.7.6rc1 (v2.7.6rc1:4913d0e9be30+, Oct 27 2013, 20:52:11) . This does not occur on another system running Python 2.7.3 (default, Mar 25 2013, 15:56:58) [GCC 4.4.7 20120313 (Red Hat 4.4.7-3)] on linux2. aaron-mbp15:core aaronb$ python2.7 Python 2.7.6rc1 (v2.7.6rc1:4913d0e9be30+, Oct 27 2013, 20:52:11) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import email Traceback (most recent call last): File "", line 1, in File "email.py", line 7, in File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/imaplib.py", line 443, in fetch typ, dat = self._simple_command(name, message_set, message_parts) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/imaplib.py", line 1070, in _simple_command return self._command_complete(name, self._command(name, *args)) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/imaplib.py", line 905, in _command_complete raise self.error('%s command error: %s %s' % (name, typ, data)) imaplib.error: FETCH command error: BAD ['Could not parse command'] >>> ---------- components: email messages: 216752 nosy: barry, r.david.murray, teraincognita priority: normal severity: normal status: open title: imaplib.error when importing email package type: compile error versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 23:42:55 2014 From: report at bugs.python.org (Armin Ronacher) Date: Thu, 17 Apr 2014 21:42:55 +0000 Subject: [issue21288] hashlib.pbkdf2_hmac Hash Constructor In-Reply-To: <1397760292.99.0.128790868195.issue21288@psf.upfronthosting.co.za> Message-ID: <1397770975.44.0.669406461854.issue21288@psf.upfronthosting.co.za> Armin Ronacher added the comment: I understand that, but given that this API might be backported to 2.7 I think it should get further review. Also, this would only be a change to the error case. Non string arguments are currently being responded to with a TypeError. I am not proposing to remove the string API, just also allow a hash constructor. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 23:47:04 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Thu, 17 Apr 2014 21:47:04 +0000 Subject: [issue21272] use _sysconfigdata to itinialize distutils.sysconfig In-Reply-To: <1397686328.42.0.129070062942.issue21272@psf.upfronthosting.co.za> Message-ID: <1397771224.63.0.848659094119.issue21272@psf.upfronthosting.co.za> ?ric Araujo added the comment: Sure. The API is slightly different, but the data should be the same, so this can be done. ---------- components: +Distutils -Library (Lib) title: use _sysconfigdata.py in distutils.sysconfig to initialize distutils.sysconfig -> use _sysconfigdata to itinialize distutils.sysconfig _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 23:47:16 2014 From: report at bugs.python.org (Dave Sawyer) Date: Thu, 17 Apr 2014 21:47:16 +0000 Subject: [issue15414] os.path.join behavior on Windows (ntpath.join) is unexpected and not well documented In-Reply-To: <1342903268.21.0.193498975528.issue15414@psf.upfronthosting.co.za> Message-ID: <1397771236.07.0.185695605958.issue15414@psf.upfronthosting.co.za> Dave Sawyer added the comment: http://bugs.python.org/issue1669539 has been partially fixed. On Windows os.path.join('foo', 'a:bar') gives 'a:bar' not 'foo\\a:bar'. However os.path.isabs('a:bar') returns False yet it causes a reset in the join like an absolute path. '\foo' is considered an absolute path even though calling os.path.abspath on it can yield different results - as if it were a relative path. At minimum we should amend the wording about what resets the join. ---------- nosy: +dsawyer _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 23:49:20 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Thu, 17 Apr 2014 21:49:20 +0000 Subject: [issue21272] use _sysconfigdata to itinialize distutils.sysconfig In-Reply-To: <1397686328.42.0.129070062942.issue21272@psf.upfronthosting.co.za> Message-ID: <1397771360.64.0.922925760713.issue21272@psf.upfronthosting.co.za> ?ric Araujo added the comment: doko?s patch is actually conservative, not changing the query functions of distutils.sysconfig but only the _init_posix function, which just defines a global dict. It looks quite safe to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 23:49:43 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 17 Apr 2014 21:49:43 +0000 Subject: [issue21291] subprocess Popen objects are not thread safe w.r.t. wait() and returncode being set Message-ID: <1397771383.14.0.251860763766.issue21291@psf.upfronthosting.co.za> New submission from Gregory P. Smith: Executing the supplied test code you either get: sys.version = 3.4.0+ (3.4:635817da596d, Apr 17 2014, 14:30:34) [GCC 4.6.3] -------- Results with : r0 = None, expected None r1 = None, expected None ri0 = None, expected None ri1 = -9, expected -9 ri2 = -9, expected -9 r2 = 0, expected -9 *** MISMATCH *** r3 = 0, expected -9 *** MISMATCH *** or Results with : r0 = None, expected None r1 = None, expected None ri0 = None, expected None ri1 = -9, expected -9 ri2 = -9, expected -9 r2 = 0, expected -9 *** MISMATCH *** r3 = 0, expected -9 *** MISMATCH *** At first glance it appears that the .returncode attribute is not safely set after the wait call... This test code is using the Popen object from multiple threads at once. ---------- assignee: gregory.p.smith files: subprocess_wait_problem.py messages: 216757 nosy: gregory.p.smith priority: normal severity: normal status: open title: subprocess Popen objects are not thread safe w.r.t. wait() and returncode being set versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file34955/subprocess_wait_problem.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 23:50:01 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 17 Apr 2014 21:50:01 +0000 Subject: [issue21290] imaplib.error when importing email package In-Reply-To: <1397770954.41.0.647416164199.issue21290@psf.upfronthosting.co.za> Message-ID: <1397771401.23.0.641756158851.issue21290@psf.upfronthosting.co.za> R. David Murray added the comment: There is no file 'email.py' in the Python standard library. You must have such a file in your python path somewhere, so when you import email it actually imports that file instead of the email package. You will note that 'email.py' in the traceback does not have a path, so it is probably in the directory you are running python from. ---------- resolution: -> not a bug stage: -> committed/rejected status: open -> closed type: compile error -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 23:51:18 2014 From: report at bugs.python.org (Steve) Date: Thu, 17 Apr 2014 21:51:18 +0000 Subject: [issue21292] C API in debug fails Message-ID: <1397771478.75.0.526004579779.issue21292@psf.upfronthosting.co.za> New submission from Steve: Although not a bug, it annoys me enough that it is a bug in my head! The problem is that trying to compile an application in debug that embeds Python fails. Case in point; we canned the idea of embedding Python (went with Lua) for that reason only. We did not have the option of incorporating a Python build into our build system and not being able to compile in debug was not an option either. We would have been happy to compile in debug with a release lib of Python, but since it was not possible, it got killed. The fix: It should be possible for someone to compile an application in debug that embeds python without having the Python debug libraries. ---------- components: Library (Lib) messages: 216759 nosy: Banger priority: normal severity: normal status: open title: C API in debug fails type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 17 23:52:13 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 17 Apr 2014 21:52:13 +0000 Subject: [issue21292] C API in debug fails In-Reply-To: <1397771478.75.0.526004579779.issue21292@psf.upfronthosting.co.za> Message-ID: <1397771533.8.0.0800783776833.issue21292@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Is that under Windows? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 00:11:41 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 17 Apr 2014 22:11:41 +0000 Subject: [issue21109] tarfile: Traversal attack vulnerability In-Reply-To: <1396253659.12.0.842636239516.issue21109@psf.upfronthosting.co.za> Message-ID: <1397772701.75.0.901311812788.issue21109@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 00:27:44 2014 From: report at bugs.python.org (paul j3) Date: Thu, 17 Apr 2014 22:27:44 +0000 Subject: [issue17218] support title and description in argparse add_mutually_exclusive_group In-Reply-To: <1361061502.09.0.252084655816.issue17218@psf.upfronthosting.co.za> Message-ID: <1397773664.74.0.304164674103.issue17218@psf.upfronthosting.co.za> paul j3 added the comment: The idea of nesting a mutually_exclusive_group in a titled argument_group is already present in `test_argparse.py`. class TestMutuallyExclusiveInGroup(MEMixin, TestCase): def get_parser(self, required=None): parser = ErrorRaisingArgumentParser(prog='PROG') titled_group = parser.add_argument_group( title='Titled group', description='Group description') mutex_group = \ titled_group.add_mutually_exclusive_group(required=required) mutex_group.add_argument('--bar', help='bar help') mutex_group.add_argument('--baz', help='baz help') return parser failures = ['--bar X --baz Y', '--baz X --bar Y'] successes = [ ('--bar X', NS(bar='X', baz=None)), ('--baz Y', NS(bar=None, baz='Y')), ] successes_when_not_required = [ ('', NS(bar=None, baz=None)), ] usage_when_not_required = '''\ usage: PROG [-h] [--bar BAR | --baz BAZ] ''' usage_when_required = '''\ usage: PROG [-h] (--bar BAR | --baz BAZ) ''' help = '''\ optional arguments: -h, --help show this help message and exit Titled group: Group description --bar BAR bar help --baz BAZ baz help ''' So now the question is - do we to modify `add_mutually_exclusive_group` to streamline this task? An alternative is to add a note to the documentation, eg. Note that currently mutually exclusive argument groups do not support the title and description arguments of add_argument_group(). However a such a group can be added to a titled argument group. (and then add an example) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 00:29:34 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 17 Apr 2014 22:29:34 +0000 Subject: [issue21286] Refcounting information missing in docs for Python 3.4 and above. In-Reply-To: <1397752734.97.0.965637829315.issue21286@psf.upfronthosting.co.za> Message-ID: <3g8w8s4hH1z7LjM@mail.python.org> Roundup Robot added the comment: New changeset 8c12d3e0f1de by Benjamin Peterson in branch '3.4': fix ref count annotations on sphinx >= 1.2.1 (closes #21286) http://hg.python.org/cpython/rev/8c12d3e0f1de ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 00:31:40 2014 From: report at bugs.python.org (Dave Sawyer) Date: Thu, 17 Apr 2014 22:31:40 +0000 Subject: [issue15414] os.path.join behavior on Windows (ntpath.join) is unexpected and not well documented In-Reply-To: <1342903268.21.0.193498975528.issue15414@psf.upfronthosting.co.za> Message-ID: <1397773900.76.0.321649355301.issue15414@psf.upfronthosting.co.za> Changes by Dave Sawyer : ---------- keywords: +patch Added file: http://bugs.python.org/file34956/joindoc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 00:42:46 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 17 Apr 2014 22:42:46 +0000 Subject: [issue20309] Not all method descriptors are callable In-Reply-To: <1390200218.06.0.45732778516.issue20309@psf.upfronthosting.co.za> Message-ID: <1397774566.71.0.78239904895.issue20309@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 00:46:06 2014 From: report at bugs.python.org (Dave Sawyer) Date: Thu, 17 Apr 2014 22:46:06 +0000 Subject: [issue15414] os.path.join behavior on Windows (ntpath.join) is unexpected and not well documented In-Reply-To: <1342903268.21.0.193498975528.issue15414@psf.upfronthosting.co.za> Message-ID: <1397774766.08.0.705680160223.issue15414@psf.upfronthosting.co.za> Changes by Dave Sawyer : ---------- versions: +Python 3.4, Python 3.5 -Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 01:04:26 2014 From: report at bugs.python.org (Florent Xicluna) Date: Thu, 17 Apr 2014 23:04:26 +0000 Subject: [issue10740] sqlite3 module breaks transactions and potentially corrupts data In-Reply-To: <1292868135.81.0.257293444934.issue10740@psf.upfronthosting.co.za> Message-ID: <1397775866.11.0.886036836796.issue10740@psf.upfronthosting.co.za> Changes by Florent Xicluna : ---------- nosy: +flox _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 01:14:32 2014 From: report at bugs.python.org (Martin Panter) Date: Thu, 17 Apr 2014 23:14:32 +0000 Subject: [issue18304] ElementTree -- provide a way to ignore namespace in tags and seaches In-Reply-To: <1372218497.28.0.26294900817.issue18304@psf.upfronthosting.co.za> Message-ID: <1397776472.25.0.454314267249.issue18304@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 01:22:20 2014 From: report at bugs.python.org (paul j3) Date: Thu, 17 Apr 2014 23:22:20 +0000 Subject: [issue17218] support title and description in argparse add_mutually_exclusive_group In-Reply-To: <1361061502.09.0.252084655816.issue17218@psf.upfronthosting.co.za> Message-ID: <1397776940.9.0.0317625570813.issue17218@psf.upfronthosting.co.za> paul j3 added the comment: oops - one more glitch (revealed by TestMutuallyExclusiveInGroup): 'add_mutually_exclusive_group' accepts a 'required' argument, but 'add_argument_group' does not. So 'add_titled_mutually_exclusive_group' needs to be changed to temporarily remove that argument (if given). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 01:28:07 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 17 Apr 2014 23:28:07 +0000 Subject: [issue4963] mimetypes.guess_extension result changes after mimetypes.init() In-Reply-To: <1232107494.83.0.0570958889295.issue4963@psf.upfronthosting.co.za> Message-ID: <1397777287.05.0.101627498674.issue4963@psf.upfronthosting.co.za> R. David Murray added the comment: OK, it is great having a test that makes this at least mostly reproducible :) Having reloaded my brain on this thing, I'm thinking that the best solution may be indeed to switch to ordered dicts. If we then reorder the hardcoded lists to be in "preferred" order, that should then also solve issue 1043134. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 01:35:51 2014 From: report at bugs.python.org (Dave Sawyer) Date: Thu, 17 Apr 2014 23:35:51 +0000 Subject: [issue21289] make.bat not building documentation In-Reply-To: <1397765643.91.0.331086007996.issue21289@psf.upfronthosting.co.za> Message-ID: <1397777751.7.0.682064024887.issue21289@psf.upfronthosting.co.za> Changes by Dave Sawyer : Added file: http://bugs.python.org/file34957/mywork.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 01:37:36 2014 From: report at bugs.python.org (Dave Sawyer) Date: Thu, 17 Apr 2014 23:37:36 +0000 Subject: [issue21289] make.bat not building documentation In-Reply-To: <1397765643.91.0.331086007996.issue21289@psf.upfronthosting.co.za> Message-ID: <1397777856.79.0.0447519097216.issue21289@psf.upfronthosting.co.za> Dave Sawyer added the comment: Thanks Zach! The bug tracker was nice enough to prompt me to go look in my email for the agreement too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 01:55:53 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 17 Apr 2014 23:55:53 +0000 Subject: [issue21293] Remove "capsule hack" from object.c? Message-ID: <1397778953.55.0.677894894827.issue21293@psf.upfronthosting.co.za> New submission from Larry Hastings: I noticed this code in Objects/object.c today: /* Hack to force loading of pycapsule.o */ PyTypeObject *_PyCapsule_hack = &PyCapsule_Type; What is this doing? Note that PyCapsule_Type is referred to inside _Py_ReadyTypes(), so there's already a reference to it from this module. This global seems redundant. Attached is a patch that removes it. Trunk compiles and all tests pass with it applied, though I only tried on 64-bit Linux so I concede if this is handling some obscure edge case I probably wouldn't have hit it. ---------- files: larry.remove.no.capsule.hack.1.diff keywords: patch messages: 216766 nosy: larry priority: low severity: normal stage: patch review status: open title: Remove "capsule hack" from object.c? type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file34958/larry.remove.no.capsule.hack.1.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 03:00:30 2014 From: report at bugs.python.org (Martin Panter) Date: Fri, 18 Apr 2014 01:00:30 +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: <1397782830.45.0.168242937584.issue21224@psf.upfronthosting.co.za> Martin Panter added the comment: Looking at Issue 430706 and revision 27f36f4bf525, there is concious support for HTTP 1.1 persistent connections. Apparently the 1.0 default is just for backwards compatibility. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 03:12:08 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 18 Apr 2014 01:12:08 +0000 Subject: [issue18304] ElementTree -- provide a way to ignore namespace in tags and seaches In-Reply-To: <1372218497.28.0.26294900817.issue18304@psf.upfronthosting.co.za> Message-ID: <1397783528.74.0.617299187891.issue18304@psf.upfronthosting.co.za> Raymond Hettinger added the comment: FWIW, I would like to have a way to ignore namespaces. For many day-to-day problems (parsing Microsoft Excel files saved in an XML format or parsing RSS feeds), this would be a nice simplification. I teach Python for a living and have found that it is common for namespaces to be an obstacle for people trying to get something done. Giving them the following answer is unsatisfactory response to legitimate needs: """ And it's pretty trivial to pre-process the entire tree by stripping all namespaces from it the intention is really to do namespace agnostic processing. However, in my experience, most people who want to do that haven't actually understood namespaces (although, admittedly, sometimes it's those who designed the XML format who didn't understand namespaces ...). """ ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 03:15:09 2014 From: report at bugs.python.org (Christian Hudon) Date: Fri, 18 Apr 2014 01:15:09 +0000 Subject: [issue20309] Not all method descriptors are callable In-Reply-To: <1390200218.06.0.45732778516.issue20309@psf.upfronthosting.co.za> Message-ID: <1397783709.05.0.163872166989.issue20309@psf.upfronthosting.co.za> Christian Hudon added the comment: Here is the (first?) complete version of the patch. All tests pass. Note that I had to remove a test that was checking that the object returned from staticmethod was not callable. Let me know if I should add more tests, or if there are any other problems with the patch. Thanks! ---------- Added file: http://bugs.python.org/file34959/descr_v2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 03:34:05 2014 From: report at bugs.python.org (Martin Panter) Date: Fri, 18 Apr 2014 01:34:05 +0000 Subject: [issue21257] Document parse_headers function of http.client In-Reply-To: <1397666699.47.0.0992171618243.issue21257@psf.upfronthosting.co.za> Message-ID: <1397784845.06.0.52634609632.issue21257@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 03:35:25 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 18 Apr 2014 01:35:25 +0000 Subject: [issue21291] subprocess Popen objects are not thread safe w.r.t. wait() and returncode being set In-Reply-To: <1397771383.14.0.251860763766.issue21291@psf.upfronthosting.co.za> Message-ID: <1397784925.59.0.940171442986.issue21291@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Attaching a proposed fix for this issue. It should make the wait() and poll() methods thread safe. I need to turn the reproducer code into an actual test case and add more test cases for coverage of all code paths being touched. I haven't examined the windows side of this code for the issue, it may also be useful there. ---------- keywords: +patch Added file: http://bugs.python.org/file34960/issue21291-fix-gps01.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 03:50:23 2014 From: report at bugs.python.org (Martin Panter) Date: Fri, 18 Apr 2014 01:50:23 +0000 Subject: [issue16285] Update urllib quoting to RFC 3986 In-Reply-To: <1350644168.93.0.364254038155.issue16285@psf.upfronthosting.co.za> Message-ID: <1397785823.64.0.328518400101.issue16285@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 03:55:57 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Fri, 18 Apr 2014 01:55:57 +0000 Subject: [issue21202] Naming a file` io.py` causes cryptic error message In-Reply-To: <1397239551.94.0.578791540537.issue21202@psf.upfronthosting.co.za> Message-ID: <1397786157.92.0.178982096051.issue21202@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 06:19:33 2014 From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=) Date: Fri, 18 Apr 2014 04:19:33 +0000 Subject: [issue21294] len wrong help Message-ID: <1397794773.2.0.687727547467.issue21294@psf.upfronthosting.co.za> New submission from Vedran ?a?i?: >From recently, help(len) gives the wrong signature of len. Help on built-in function len in module builtins: len(...) len(module, object) ^^^^^^^^ Return the number of items of a sequence or mapping. I tried to track it down, I think it happened here: http://bugs.python.org/file33655/larry.support.text_signature.on.more.types.6.txt I realize it was a part of some big fix, so I don't know how easy it is to fix independently. Also, you might think it's not so big an issue. But I teach Python, and my pupils are really confused because of this. Please fix it if anyhow possible. Tnx. ---------- assignee: docs at python components: Documentation messages: 216771 nosy: Vedran.?a?i?, docs at python priority: normal severity: normal status: open title: len wrong help versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 06:27:30 2014 From: report at bugs.python.org (Igor Pashev) Date: Fri, 18 Apr 2014 04:27:30 +0000 Subject: [issue21287] Better support for AF_PACKET on opensolaris (illumos) In-Reply-To: <1397759947.91.0.17620010785.issue21287@psf.upfronthosting.co.za> Message-ID: <1397795250.65.0.228581834397.issue21287@psf.upfronthosting.co.za> Changes by Igor Pashev : Added file: http://bugs.python.org/file34961/dyson-socketmodule-ifindex.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 06:28:49 2014 From: report at bugs.python.org (Ned Deily) Date: Fri, 18 Apr 2014 04:28:49 +0000 Subject: [issue21294] len wrong help In-Reply-To: <1397794773.2.0.687727547467.issue21294@psf.upfronthosting.co.za> Message-ID: <1397795329.57.0.0468828704737.issue21294@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +larry stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 06:37:08 2014 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 18 Apr 2014 04:37:08 +0000 Subject: [issue21294] len wrong help In-Reply-To: <1397794773.2.0.687727547467.issue21294@psf.upfronthosting.co.za> Message-ID: <1397795828.39.0.192233224549.issue21294@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +ncoghlan, yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 07:02:25 2014 From: report at bugs.python.org (Georg Brandl) Date: Fri, 18 Apr 2014 05:02:25 +0000 Subject: [issue21286] Refcounting information missing in docs for Python 3.4 and above. In-Reply-To: <1397752734.97.0.965637829315.issue21286@psf.upfronthosting.co.za> Message-ID: <1397797345.57.0.38808914604.issue21286@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 07:04:16 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 18 Apr 2014 05:04:16 +0000 Subject: [issue21294] len wrong help In-Reply-To: <1397794773.2.0.687727547467.issue21294@psf.upfronthosting.co.za> Message-ID: <3g94wH1Nlhz7Ljf@mail.python.org> Roundup Robot added the comment: New changeset 679319e3f42b by Benjamin Peterson in branch '3.4': correct len signature in docstring (closes #21294) http://hg.python.org/cpython/rev/679319e3f42b ---------- nosy: +python-dev resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 07:08:06 2014 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 18 Apr 2014 05:08:06 +0000 Subject: [issue18304] ElementTree -- provide a way to ignore namespace in tags and seaches In-Reply-To: <1372218497.28.0.26294900817.issue18304@psf.upfronthosting.co.za> Message-ID: <1397797686.38.0.0542851960459.issue18304@psf.upfronthosting.co.za> Stefan Behnel added the comment: You can already use iterparse for this. it = ET.iterparse('somefile.xml') for _, el in it: el.tag = el.tag.split('}', 1)[1] # strip all namespaces root = it.root As I said, this would be a little friendlier with support in the QName class, but it's not really complex code. Could be added to the docs as a recipe, with a visible warning that this can easily lead to incorrect data processing and therefore should not be used in systems where the input is not entirely under control. Note that it's unclear what the "right way to do it" is, though. Is it better to 1) alter the data by stripping all namespaces off, or 2) let the tree API itself provide a namespace agnostic mode? Depends on the use case, but the more generic way 2) should be fairly involved in terms of implementation complexity, for just a minor use case. 1) would be ok in most cases where this "feature" is useful, I guess, and can be done as shown above. In fact, the advantage of doing it explicitly with iterparse() is that instead of stripping all namespaces, only the expected namespaces can be discarded. And errors can be raised when finding unnamespaced elements, for example. This allows for a safety guard that prevents the code from completely misinterpreting input. There is a reason why namespace were added to XML at some point. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 07:20:12 2014 From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=) Date: Fri, 18 Apr 2014 05:20:12 +0000 Subject: [issue21294] len wrong help In-Reply-To: <1397794773.2.0.687727547467.issue21294@psf.upfronthosting.co.za> Message-ID: <1397798412.43.0.0267292003315.issue21294@psf.upfronthosting.co.za> Vedran ?a?i? added the comment: 1. Was it really _that_ easy? I mean, there obviously was a reason for previous change... someone wouldn't add a parameter to documentation out of thin air. As far as I can see, it was because automatic argument inspection didn't work in some cases... 2. If it really is that easy, when will the fixed version be available? I know I can compile from source, but my pupils are not so comfortable with this. Will it be in 3.4.1? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 07:46:17 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 18 Apr 2014 05:46:17 +0000 Subject: [issue21294] len wrong help In-Reply-To: <1397794773.2.0.687727547467.issue21294@psf.upfronthosting.co.za> Message-ID: <1397799977.85.0.75098590404.issue21294@psf.upfronthosting.co.za> Larry Hastings added the comment: It's really that easy, it was a stupid bug that is probably my fault, the fix will be in 3.4.1. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 12:46:10 2014 From: report at bugs.python.org (Florent Xicluna) Date: Fri, 18 Apr 2014 10:46:10 +0000 Subject: [issue11380] Improve reporting of broken stdout pipe during interpreter shutdown In-Reply-To: <1299115966.12.0.337666295395.issue11380@psf.upfronthosting.co.za> Message-ID: <1397817970.3.0.777286337799.issue11380@psf.upfronthosting.co.za> Changes by Florent Xicluna : ---------- nosy: +flox _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 12:49:40 2014 From: report at bugs.python.org (Aivar Annamaa) Date: Fri, 18 Apr 2014 10:49:40 +0000 Subject: [issue21295] Python 3.4 gives wrong col_offset for Call nodes returned from ast.parse Message-ID: <1397818180.59.0.739018200129.issue21295@psf.upfronthosting.co.za> New submission from Aivar Annamaa: Following program gives correct result in Python versions older than 3.4, but incorrect result in 3.4: ---------------------- import ast tree = ast.parse("sin(0.5)") first_stmt = tree.body[0] call = first_stmt.value print("col_offset of call expression:", call.col_offset) print("col_offset of func of the call:", call.func.col_offset) ----------------------- it should print: col_offset of call expression: 0 col_offset of func of the call: 0 but in 3.4 it prints: col_offset of call expression: 3 col_offset of func of the call: 0 ---------- components: Interpreter Core files: py34_ast_call_bug.py messages: 216777 nosy: Aivar.Annamaa priority: normal severity: normal status: open title: Python 3.4 gives wrong col_offset for Call nodes returned from ast.parse versions: Python 3.4 Added file: http://bugs.python.org/file34962/py34_ast_call_bug.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 12:58:03 2014 From: report at bugs.python.org (Aivar Annamaa) Date: Fri, 18 Apr 2014 10:58:03 +0000 Subject: [issue21295] Python 3.4 gives wrong col_offset for Call nodes returned from ast.parse In-Reply-To: <1397818180.59.0.739018200129.issue21295@psf.upfronthosting.co.za> Message-ID: <1397818683.44.0.315392152605.issue21295@psf.upfronthosting.co.za> Aivar Annamaa added the comment: ... also, lineno is wrong for both Call and call's func, when func and arguments are on different lines: import ast tree = ast.parse("(sin\n(0.5))") first_stmt = tree.body[0] call = first_stmt.value print("col_offset of call expression:", call.col_offset) print("col_offset of func of the call:", call.func.col_offset) print("lineno of call expression:", call.lineno) print("lineno of func of the call:", call.lineno) # lineno-s should be 1 for both call and func ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 13:02:30 2014 From: report at bugs.python.org (Aivar Annamaa) Date: Fri, 18 Apr 2014 11:02:30 +0000 Subject: [issue16806] col_offset is -1 and lineno is wrong for multiline string expressions In-Reply-To: <1356739702.66.0.625233113719.issue16806@psf.upfronthosting.co.za> Message-ID: <1397818950.12.0.36327436281.issue16806@psf.upfronthosting.co.za> Changes by Aivar Annamaa : ---------- nosy: +Aivar.Annamaa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 13:03:16 2014 From: report at bugs.python.org (Luiji Maryo) Date: Fri, 18 Apr 2014 11:03:16 +0000 Subject: [issue21296] smtplib Sends Commands in Lower-Case Message-ID: <1397818996.26.0.83241644449.issue21296@psf.upfronthosting.co.za> New submission from Luiji Maryo: It has occurred to me while testing an SMTP server with smtplib that it sends commands in lower-case. This is problematic because, although most SMTP servers seem to be case-insensitive, RFC 5321 (SMTP) doesn't seem to explicitly require this and there may be systems out there which require upper-case commands. Additionally, the output just looks unclean because the parameters are given capitalized (e.g. we get "mail FROM:" instead of "MAIL FROM:" or "mail from:". I would propose that putcmd() use cmd.upper(). Alternatively, all instances of putcmd() and docmd() could be updated to have the commands in capitalized form so that, should the user desire, they could send lower-case commands, though I don't quite see what would be useful about that. ---------- messages: 216779 nosy: luiji priority: normal severity: normal status: open title: smtplib Sends Commands in Lower-Case type: behavior versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 13:52:21 2014 From: report at bugs.python.org (Daniel Andersson) Date: Fri, 18 Apr 2014 11:52:21 +0000 Subject: [issue21297] skipinitialspace in the csv module only skips spaces, not "whitespace" in general Message-ID: <1397821941.61.0.706896478348.issue21297@psf.upfronthosting.co.za> New submission from Daniel Andersson: Regarding the `skipinitialspace` parameter to the different CSV reader dialects in the `csv` module, the official documentation asserts: When True, whitespace immediately following the delimiter is ignored. and the `help(csv)` style module documentation says: * skipinitialspace - specifies how to interpret whitespace which immediately follows a delimiter. It defaults to False, which means that whitespace immediately following a delimiter is part of the following field. "Whitespace" is a bit too general in both cases (at least a red herring in the second case), since it only skips spaces and not e.g. tabs [1]. In `Modules/_csv.c`, it more correctly describes the parameter. At line 81: int skipinitialspace; /* ignore spaces following delimiter? */ and the actual implementation at line 638: else if (c == ' ' && dialect->skipinitialspace) /* ignore space at start of field */ ; No-one will probably assume that the whole UTF-8 spectrum of "whitespace" is skipped, but at least I initially assumed that the tab character was included. [1]: http://en.wikipedia.org/wiki/Whitespace_character ---------- assignee: docs at python components: Documentation, Library (Lib) messages: 216780 nosy: Daniel.Andersson, docs at python priority: normal severity: normal status: open title: skipinitialspace in the csv module only skips spaces, not "whitespace" in general type: behavior versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 14:04:52 2014 From: report at bugs.python.org (Thomas Levine) Date: Fri, 18 Apr 2014 12:04:52 +0000 Subject: [issue21298] Cheese shop registration stopped working for me recently Message-ID: <1397822692.79.0.7421176535.issue21298@psf.upfronthosting.co.za> New submission from Thomas Levine: This command used to work just fine for me. :: python setup.py register Now it doesn't. For example, :: $ python3 setup.py register /usr/lib/python3.3/distutils/dist.py:257: UserWarning: Unknown distribution option: 'install_requires' warnings.warn(msg) /usr/lib/python3.3/distutils/dist.py:257: UserWarning: Unknown distribution option: 'tests_require' warnings.warn(msg) running register running check Registering sheetmusic to http://pypi.python.org/pypi Server response (401): Unauthorized But I can submit just fine with the form at https://pypi.python.org/pypi?%3Aaction=submit_form, and the following works once I do that. :: python setup.py sdist upload The attached setup.py file is from this package https://pypi.python.org/pypi/sheetmusic ---------- components: Distutils files: setup.py messages: 216781 nosy: dstufft, eric.araujo, tlevine priority: normal severity: normal status: open title: Cheese shop registration stopped working for me recently type: behavior versions: Python 2.7, Python 3.4 Added file: http://bugs.python.org/file34963/setup.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 14:54:56 2014 From: report at bugs.python.org (Bernie Keimel) Date: Fri, 18 Apr 2014 12:54:56 +0000 Subject: [issue21299] Einladung in mein Netzwerk bei LinkedIn Message-ID: <1461749625.20636330.1397825684014.JavaMail.app@ela4-app1549.prod> New submission from Bernie Keimel: LinkedIn ------------ Ich m?chte Sie zu meinem beruflichen Netzwerk auf LinkedIn hinzuf?gen. - Bernard Keimel Bernard Keimel Business bei privat Berlin und Umgebung, Deutschland Best?tigen, dass Sie Bernard Keimel kennen: https://www.linkedin.com/e/-3qcne3-hu5hbkmh-1s/isd/16078050493/NNc4mKPz/?hs=false&tok=0SvHBVq3J6v6c1 -- Sie erhalten Einladungen zum Netwerkbeitritt per E-Mail. Klicken Sie hier, wenn Sie kein Interesse daran haben: http://www.linkedin.com/e/-3qcne3-hu5hbkmh-1s/z2oU7dKDzpt2G7xQz2FC2SclHmnUGzmsk0c/goo/report%40bugs%2Epython%2Eorg/20061/I6913898468_1/?hs=false&tok=35uA1JgJ56v6c1 (c) 2012 LinkedIn Corporation. 2029 Stierlin Ct., Mountain View, CA 94043, USA ---------- messages: 216782 nosy: Bernie.Keimel priority: normal severity: normal status: open title: Einladung in mein Netzwerk bei LinkedIn _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 15:13:06 2014 From: report at bugs.python.org (Berker Peksag) Date: Fri, 18 Apr 2014 13:13:06 +0000 Subject: [issue21299] Spam In-Reply-To: <1461749625.20636330.1397825684014.JavaMail.app@ela4-app1549.prod> Message-ID: <1397826786.15.0.008297395832.issue21299@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: -Bernie.Keimel resolution: -> not a bug stage: -> committed/rejected status: open -> closed title: Einladung in mein Netzwerk bei LinkedIn -> Spam _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 15:13:17 2014 From: report at bugs.python.org (Berker Peksag) Date: Fri, 18 Apr 2014 13:13:17 +0000 Subject: [issue21299] Spam Message-ID: <1397826797.31.0.0430273649364.issue21299@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- Removed message: http://bugs.python.org/msg216782 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 15:51:28 2014 From: report at bugs.python.org (Merlijn van Deen) Date: Fri, 18 Apr 2014 13:51:28 +0000 Subject: [issue21300] Docs (incorrectly) suggest email.policy.default is the default policy Message-ID: <1397829088.9.0.524887326408.issue21300@psf.upfronthosting.co.za> New submission from Merlijn van Deen: Which would make sense, but email.policy.Compat32 is *actually* the default policy. This patch adapts the documentation to reflect this. ---------- assignee: docs at python components: Documentation files: defaultpolicy.diff keywords: patch messages: 216783 nosy: docs at python, r.david.murray, valhallasw priority: normal severity: normal status: open title: Docs (incorrectly) suggest email.policy.default is the default policy versions: Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file34964/defaultpolicy.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 16:37:02 2014 From: report at bugs.python.org (Aaron Briel) Date: Fri, 18 Apr 2014 14:37:02 +0000 Subject: [issue21290] imaplib.error when importing email package In-Reply-To: <1397770954.41.0.647416164199.issue21290@psf.upfronthosting.co.za> Message-ID: <1397831822.53.0.539046682028.issue21290@psf.upfronthosting.co.za> Aaron Briel added the comment: I had a rouge compiled python file named email.pyc. My apologies. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 17:58:27 2014 From: report at bugs.python.org (Steve) Date: Fri, 18 Apr 2014 15:58:27 +0000 Subject: [issue21292] C API in debug fails In-Reply-To: <1397771478.75.0.526004579779.issue21292@psf.upfronthosting.co.za> Message-ID: <1397836707.11.0.29618160112.issue21292@psf.upfronthosting.co.za> Steve added the comment: It is under windows ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 17:59:25 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 18 Apr 2014 15:59:25 +0000 Subject: [issue21292] C API in debug fails In-Reply-To: <1397771478.75.0.526004579779.issue21292@psf.upfronthosting.co.za> Message-ID: <1397836765.43.0.130580820069.issue21292@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 18:36:03 2014 From: report at bugs.python.org (Steve) Date: Fri, 18 Apr 2014 16:36:03 +0000 Subject: [issue21292] C API in debug fails In-Reply-To: <1397771478.75.0.526004579779.issue21292@psf.upfronthosting.co.za> Message-ID: <1397838963.34.0.870117186667.issue21292@psf.upfronthosting.co.za> Steve added the comment: A bit more info: - When building in debug you need the Pythonxx_d.lib. - This lib does not come with the normal install (or any other install). That part is fine and normal (you don't include debug libs with install). - To get that lib you have to build Python in debug to get it. This is too much, I should not have to rebuild a library just because I want to build MY application in debug. - Copying the Pythonxx.lib file to Pythonxx_d.lib works for many basic functions, but for others, it is missing necessary defiitions (i.e. linking fails). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 18:39:54 2014 From: report at bugs.python.org (Thomas Wouters) Date: Fri, 18 Apr 2014 16:39:54 +0000 Subject: [issue21277] don't try to link _ctypes with a ffi_convenience library In-Reply-To: <1397688266.23.0.303919517358.issue21277@psf.upfronthosting.co.za> Message-ID: <1397839194.72.0.446514103625.issue21277@psf.upfronthosting.co.za> Thomas Wouters added the comment: I don't understand the story with ffi_convenience here. Perhaps someone else on python-dev remembers what it was for and whether we need it for any platforms, still? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 18:41:17 2014 From: report at bugs.python.org (Zachary Ware) Date: Fri, 18 Apr 2014 16:41:17 +0000 Subject: [issue21289] make.bat not building documentation In-Reply-To: <1397765643.91.0.331086007996.issue21289@psf.upfronthosting.co.za> Message-ID: <1397839277.86.0.157692041784.issue21289@psf.upfronthosting.co.za> Zachary Ware added the comment: Your more recent patch looks like it's missing the changes to Doc/make.bat, which I assume was unintentional :). Also, thinking about it again, it would be good to use a %SPHINXBUILD% variable rather than hard-coding "sphinx-build" into the script, the same way %PYTHON% is used currently. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 20:26:06 2014 From: report at bugs.python.org (Matthew Woodcraft) Date: Fri, 18 Apr 2014 18:26:06 +0000 Subject: [issue13475] Add '-p'/'--path0' command line option to override sys.path[0] initialisation In-Reply-To: <1322181994.22.0.955887054946.issue13475@psf.upfronthosting.co.za> Message-ID: <1397845566.42.0.457028599382.issue13475@psf.upfronthosting.co.za> Matthew Woodcraft added the comment: For the record: the '-I' option (#16499) in Python 3.4 disables sys.path[0] initialisation (among other things). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 20:33:14 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 18 Apr 2014 18:33:14 +0000 Subject: [issue21068] Make ssl.PROTOCOL_* an enum In-Reply-To: <1395789227.19.0.206884350375.issue21068@psf.upfronthosting.co.za> Message-ID: <3g9Qsk0c5Hz7LjN@mail.python.org> Roundup Robot added the comment: New changeset f776771ab0ee by Antoine Pitrou in branch 'default': Issue #21068: The ssl.PROTOCOL* constants are now enum members. http://hg.python.org/cpython/rev/f776771ab0ee ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 20:39:14 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 18 Apr 2014 18:39:14 +0000 Subject: [issue21068] Make ssl.PROTOCOL_* an enum In-Reply-To: <1395789227.19.0.206884350375.issue21068@psf.upfronthosting.co.za> Message-ID: <1397846354.58.0.508960037251.issue21068@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok, since this is a low-risk change I've made it anyway. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 20:41:06 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 18 Apr 2014 18:41:06 +0000 Subject: [issue20421] expose SSL socket protocol version In-Reply-To: <1390927014.41.0.169425093715.issue20421@psf.upfronthosting.co.za> Message-ID: <1397846466.72.0.549969013812.issue20421@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok, it came to me that converting to one of the PROTOCOL* constants can fail in the following case: Python is linked with an OpenSSL that supports a more recent protocol version than the ssl module is aware of. SSL_get_version() can then return a protocol (e.g. "TLSv1.3") that we don't know about, and have no way of converting to an existing constant. So perhaps we should really simply return the same string as OpenSSL? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 20:51:07 2014 From: report at bugs.python.org (Giampaolo Rodola') Date: Fri, 18 Apr 2014 18:51:07 +0000 Subject: [issue20421] expose SSL socket protocol version In-Reply-To: <1390927014.41.0.169425093715.issue20421@psf.upfronthosting.co.za> Message-ID: <1397847067.53.0.95254413159.issue20421@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: Debatable. Maybe I'm +0.1 for returning the plain string. IMO when it comes to stdlib modules, enums are only really useful for converting integer constants. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 21:08:12 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 18 Apr 2014 19:08:12 +0000 Subject: [issue21207] urandom persistent fd - not re-openned after fd close In-Reply-To: <1397316819.31.0.463593532744.issue21207@psf.upfronthosting.co.za> Message-ID: <1397848092.56.0.697716628775.issue21207@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is a proposed patch (with tests). ---------- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file34965/urandom_fd_reopen.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 21:23:44 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 18 Apr 2014 19:23:44 +0000 Subject: [issue21207] urandom persistent fd - not re-openned after fd close In-Reply-To: <1397316819.31.0.463593532744.issue21207@psf.upfronthosting.co.za> Message-ID: <1397849024.95.0.667059940384.issue21207@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Hmm, the patch doesn't release the GIL around the fstat() calls, I wonder if that's necessary. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 21:31:05 2014 From: report at bugs.python.org (Alain Mellan) Date: Fri, 18 Apr 2014 19:31:05 +0000 Subject: [issue21301] pathlib missing Path.expandvars(env=os.environ) Message-ID: <1397849465.53.0.177138390921.issue21301@psf.upfronthosting.co.za> New submission from Alain Mellan: A lot of times paths are manipulated with environment variables that may even be expanded multiple times in a loop. For example, I have a path defined as "$RUNDIR/logfile.txt" and expanding the path for a bunch of different RUNDIRs in a loop. By default, it should take os.environ and optionally a different dictionary. Just like os.path.expandvars(), it should expand $VAR, ${VAR} and %VAR% ---------- components: Library (Lib) messages: 216796 nosy: Alain.Mellan priority: normal severity: normal status: open title: pathlib missing Path.expandvars(env=os.environ) type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 21:33:28 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 18 Apr 2014 19:33:28 +0000 Subject: [issue21301] pathlib missing Path.expandvars(env=os.environ) In-Reply-To: <1397849465.53.0.177138390921.issue21301@psf.upfronthosting.co.za> Message-ID: <1397849608.47.0.990232581707.issue21301@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +pitrou versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 22:03:21 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 18 Apr 2014 20:03:21 +0000 Subject: [issue21204] multiprocessing example does not work on Windows In-Reply-To: <1397267440.3.0.253901505287.issue21204@psf.upfronthosting.co.za> Message-ID: <1397851401.7.0.789989793274.issue21204@psf.upfronthosting.co.za> Terry J. Reedy added the comment: When quoting from the docs, it is helpful to give a link. https://docs.python.org/2/library/multiprocessing.html#examples That also identifies the version. I verified that the example fails on my 2.7.6 Windows 7 with PicklingError: Can't pickle : it's not found as thread.lock Since the example has been removed for 3.x, a possible minimal fix would be to say that it does not work on Windows and remove the statement that implies that it does. if sys.platform == 'win32': import multiprocessing.reduction # make sockets pickable/inheritable ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 22:04:24 2014 From: report at bugs.python.org (Fletcher Tomalty) Date: Fri, 18 Apr 2014 20:04:24 +0000 Subject: [issue19776] Provide expanduser() on Path objects In-Reply-To: <1385409778.55.0.842571848249.issue19776@psf.upfronthosting.co.za> Message-ID: <1397851464.68.0.207095711799.issue19776@psf.upfronthosting.co.za> Fletcher Tomalty added the comment: +1 It's very annoying to have to import expand user from os.path, when pathlib should be a full replacement for that module. Thanks to those working on this! ---------- nosy: +fletom _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 22:12:03 2014 From: report at bugs.python.org (Shankar Unni) Date: Fri, 18 Apr 2014 20:12:03 +0000 Subject: [issue21302] time.sleep (floatsleep()) should use clock_nanosleep() on Linux Message-ID: <1397851923.06.0.0550198760464.issue21302@psf.upfronthosting.co.za> New submission from Shankar Unni: I know that an earlier request to use nanosleep() has been rejected as "wontfix", but I'm filing this one for a different reason. Today, timemodule.c:floatsleep() calls select() on platforms that support it. On Linux, select() with a timeout has an unfortunate property that it is very sensitive to clock jumps, because it computes a sleep end time based on the current kernel timestamp. If the system clock is yanked back (by ntpd, or other processes), then the process can end up sleeping for a very long time. (E.g. if the clock is yanked back by half an hour while we are in the middle of, say, a sleep(10), then the process will sleep until "original_kernel_clock+10", which will turn into a half-hour sleep. Yes, systems shouldn't jerk their clocks around, but we can't often control this sort of thing on end-user environments. Using clock_nanosleep(CLOCK_MONOTONIC, 0, , NULL) makes the sleep a much more reliable thing, and mostly insensitive to such jumps. (It'll still be affected by any adjtime(), but that's OK in this case). ---------- components: Library (Lib) messages: 216799 nosy: shankarunni priority: normal severity: normal status: open title: time.sleep (floatsleep()) should use clock_nanosleep() on Linux type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 22:18:46 2014 From: report at bugs.python.org (Florent Xicluna) Date: Fri, 18 Apr 2014 20:18:46 +0000 Subject: [issue21295] Python 3.4 gives wrong col_offset for Call nodes returned from ast.parse In-Reply-To: <1397818180.59.0.739018200129.issue21295@psf.upfronthosting.co.za> Message-ID: <1397852326.7.0.606132400169.issue21295@psf.upfronthosting.co.za> Changes by Florent Xicluna : ---------- keywords: +3.4regression nosy: +flox type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 22:31:42 2014 From: report at bugs.python.org (Michael Boldischar) Date: Fri, 18 Apr 2014 20:31:42 +0000 Subject: [issue21303] Python 2.7 Spinbox Format Behaves Differently On Windows Versus Linux Message-ID: <1397853102.02.0.000549588678959.issue21303@psf.upfronthosting.co.za> New submission from Michael Boldischar: Here is my code: self._image_set_number = Spinbox(self._ramp_group, from_=0, to=999, command=self.reset_rep, format="%03.0f") self._repetition_change = Spinbox(self._ramp_group, from_=00, to=99, format="%02.0f") On Linux, the spinners behave as expected. There are always three digits in "_image_set_number" and two digits in "_repetition_change". The values are padded on the left by zeros. When I use the small arrows to increase the value, it works as expected. But, on Windows 7 64-bit, the small arrows do not behave as expected. They go up to "008" and then go back to "000" on the next click. Am I missing something or is this a bug in the the Windows version of Tkinter? ---------- messages: 216800 nosy: mboldisc priority: normal severity: normal status: open title: Python 2.7 Spinbox Format Behaves Differently On Windows Versus Linux _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 22:32:13 2014 From: report at bugs.python.org (Michael Boldischar) Date: Fri, 18 Apr 2014 20:32:13 +0000 Subject: [issue21303] Python 2.7 Spinbox Format Behaves Differently On Windows Versus Linux In-Reply-To: <1397853102.02.0.000549588678959.issue21303@psf.upfronthosting.co.za> Message-ID: <1397853133.36.0.0100975387946.issue21303@psf.upfronthosting.co.za> Changes by Michael Boldischar : ---------- components: +Tkinter versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 22:32:33 2014 From: report at bugs.python.org (Michael Boldischar) Date: Fri, 18 Apr 2014 20:32:33 +0000 Subject: [issue21303] Python 2.7 Spinbox Format Behaves Differently On Windows Versus Linux In-Reply-To: <1397853102.02.0.000549588678959.issue21303@psf.upfronthosting.co.za> Message-ID: <1397853153.86.0.880522910529.issue21303@psf.upfronthosting.co.za> Changes by Michael Boldischar : ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 22:42:39 2014 From: report at bugs.python.org (Zachary Ware) Date: Fri, 18 Apr 2014 20:42:39 +0000 Subject: [issue21303] Python 2.7 Spinbox Format Behaves Differently On Windows Versus Linux In-Reply-To: <1397853102.02.0.000549588678959.issue21303@psf.upfronthosting.co.za> Message-ID: <1397853759.74.0.414180040764.issue21303@psf.upfronthosting.co.za> Zachary Ware added the comment: Can you tell us some version numbers, please? Specifically, which micro version of Python 2.7 (e.g. 2.7.6) on both platforms, and what version of Tcl on Linux? Tcl on Windows should be version 8.5.2; if it's different, please tell us that too. Here's the easiest way to get the Tcl version: >>> import Tkinter >>> root = Tkinter.Tcl() >>> root.tk.eval('info patchlevel') '8.5.2' ---------- nosy: +gpolo, serhiy.storchaka, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 22:45:47 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 18 Apr 2014 20:45:47 +0000 Subject: [issue21289] make.bat not building documentation In-Reply-To: <1397765643.91.0.331086007996.issue21289@psf.upfronthosting.co.za> Message-ID: <3g9Tpf3Yrpz7LjS@mail.python.org> Roundup Robot added the comment: New changeset 02fec733f760 by Zachary Ware in branch '3.4': Issue #21289: Fix documentation building on Windows using Doc/make.bat. http://hg.python.org/cpython/rev/02fec733f760 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 22:48:13 2014 From: report at bugs.python.org (Zachary Ware) Date: Fri, 18 Apr 2014 20:48:13 +0000 Subject: [issue21289] make.bat not building documentation In-Reply-To: <1397765643.91.0.331086007996.issue21289@psf.upfronthosting.co.za> Message-ID: <1397854093.02.0.812052926649.issue21289@psf.upfronthosting.co.za> Zachary Ware added the comment: Fixed, thanks for the patch! I went ahead and implemented my comments and committed it. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 22:55:12 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 18 Apr 2014 20:55:12 +0000 Subject: [issue21232] Use of '1' instead of 'True' as 'splitlines' argument in difflib documentation In-Reply-To: <1397542231.28.0.662234584475.issue21232@psf.upfronthosting.co.za> Message-ID: <1397854512.7.0.475973864643.issue21232@psf.upfronthosting.co.za> Terry J. Reedy added the comment: In 2.x, 1 is guaranteed to be true, in that sense that if 1: print 'true' is guaranteed to print 'true', while True is not necessarily true. >>> True = 0 >>> if True: print 'yes' >>> So 2.x docs should not be changed. ---------- nosy: +terry.reedy versions: -Python 2.7, Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 22:55:23 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 18 Apr 2014 20:55:23 +0000 Subject: [issue21232] Use of '1' instead of 'True' as 'splitlines' argument in difflib documentation In-Reply-To: <1397542231.28.0.662234584475.issue21232@psf.upfronthosting.co.za> Message-ID: <1397854523.54.0.578567617924.issue21232@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- assignee: docs at python -> terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 23:01:33 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 18 Apr 2014 21:01:33 +0000 Subject: [issue21232] Use of '1' instead of 'True' as 'splitlines' argument in difflib documentation In-Reply-To: <1397542231.28.0.662234584475.issue21232@psf.upfronthosting.co.za> Message-ID: <3g9V8r3pk1z7Ljf@mail.python.org> Roundup Robot added the comment: New changeset 604b74f9a07d by Terry Jan Reedy in branch '3.4': Issue #21232: Replace .splitlines arg '1' with 'keepends=True'. http://hg.python.org/cpython/rev/604b74f9a07d New changeset c82dcad83438 by Terry Jan Reedy in branch 'default': Merge with 3.4. Closes #21232. http://hg.python.org/cpython/rev/c82dcad83438 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 23:30:17 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 18 Apr 2014 21:30:17 +0000 Subject: [issue21251] Standard library trace module crashes with exception In-Reply-To: <1397652137.22.0.406999160837.issue21251@psf.upfronthosting.co.za> Message-ID: <1397856617.46.0.773450890167.issue21251@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Third party compiled C crashers are nasty. Two suggestions: 1. Reduce the failing example to the minimum needed to fail. If you bypass all the python code in maps.py and device.py and just 'import dmraid', do you still get a crash at that point. 2. What happens if you run a minimal crasher with 3.4 or .5? I don't know if all the 3.x work on trace was backported. ---------- nosy: +belopolsky, ncoghlan, terry.reedy stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 23:35:12 2014 From: report at bugs.python.org (Dave Sawyer) Date: Fri, 18 Apr 2014 21:35:12 +0000 Subject: [issue21289] make.bat not building documentation In-Reply-To: <1397854093.02.0.812052926649.issue21289@psf.upfronthosting.co.za> Message-ID: <3b00f5f7200cac843a68095b0fac9274@mail.gmail.com> Dave Sawyer added the comment: Thanks Zach, I'm used to Git and this was my first foray with Hg and trying to rebase (I knew I shoulda branched before starting on another patch). BTW, the devs at PyCon Montreal said "Zach's a good guy. One of maybe 4 Windows devs." -Dave ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 23:35:46 2014 From: report at bugs.python.org (Ned Batchelder) Date: Fri, 18 Apr 2014 21:35:46 +0000 Subject: [issue21232] Use of '1' instead of 'True' as 'splitlines' argument in difflib documentation In-Reply-To: <1397542231.28.0.662234584475.issue21232@psf.upfronthosting.co.za> Message-ID: <1397856946.41.0.557940450465.issue21232@psf.upfronthosting.co.za> Ned Batchelder added the comment: Although the OP was incorrect about 1 being guaranteed to be True, it is still better documentation to use True rather than 1 for a boolean argument. ---------- nosy: +nedbat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 18 23:38:51 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 18 Apr 2014 21:38:51 +0000 Subject: [issue21253] Difflib.compare() crashes on mostly different sequences In-Reply-To: <1397663686.19.0.71446048811.issue21253@psf.upfronthosting.co.za> Message-ID: <1397857131.35.0.564157929832.issue21253@psf.upfronthosting.co.za> Terry J. Reedy added the comment: An obvious fix for the recursion limit error is to convert the .compare recursion to iteration with a stack (which I could try to do), but I don't know if the deep recursion is expected in this case, or is a bug. Tim? ---------- nosy: +terry.reedy, tim.peters title: Difflib.compare() crashes when sequences contain little or no common elements -> Difflib.compare() crashes on mostly different sequences _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 00:01:41 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 18 Apr 2014 22:01:41 +0000 Subject: [issue16261] Fix bare excepts in various places in std lib In-Reply-To: <1350461165.29.0.129000928595.issue16261@psf.upfronthosting.co.za> Message-ID: <1397858501.97.0.959574296413.issue16261@psf.upfronthosting.co.za> Terry J. Reedy added the comment: See more discussion on duplicate #21259. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 00:07:22 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 18 Apr 2014 22:07:22 +0000 Subject: [issue21259] replace "except: pass" by "except Exception: pass" In-Reply-To: <1397671015.92.0.0555120458036.issue21259@psf.upfronthosting.co.za> Message-ID: <1397858842.81.0.967035628757.issue21259@psf.upfronthosting.co.za> Terry J. Reedy added the comment: This is definitely a duplicate of #16261 and should be closed at such. On that issue, in msg202448, I explained that #15313 is about except: in idlelib and idlelib must be patched separately for the reason Raymond repeated (point 2). The other reason (point 1) is to keep different versions the same as much as possible. I agree that bare excepts should eventually be replaced -- but on a case by case basis to the right specific exception. A bare except is easy to grep for. Once converted to something else, it is no longer visible as needing attention. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 00:09:02 2014 From: report at bugs.python.org (paul j3) Date: Fri, 18 Apr 2014 22:09:02 +0000 Subject: [issue11874] argparse assertion failure with brackets in metavars In-Reply-To: <1303201252.58.0.236363581255.issue11874@psf.upfronthosting.co.za> Message-ID: <1397858942.92.0.244707252518.issue11874@psf.upfronthosting.co.za> paul j3 added the comment: Another example of code hitting this AssertionError. Here the problem was a space in the option argument, '--out '. http://stackoverflow.com/questions/23159845/python-argparse-assertionerror 'parser.add_argument('-o', '--out ', help='b', required = True)' That space would have cause problems later when trying access the 'args' attributes. But producing the error during the help formatting didn't help. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 00:09:53 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 18 Apr 2014 22:09:53 +0000 Subject: [issue21261] Teach IDLE to Autocomplete dictionary keys In-Reply-To: <1397672472.64.0.119805531416.issue21261@psf.upfronthosting.co.za> Message-ID: <1397858993.06.0.424942266087.issue21261@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Looks sensible. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 00:25:03 2014 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 18 Apr 2014 22:25:03 +0000 Subject: [issue21302] time.sleep (floatsleep()) should use clock_nanosleep() on Linux In-Reply-To: <1397851923.06.0.0550198760464.issue21302@psf.upfronthosting.co.za> Message-ID: <1397859903.99.0.859823875719.issue21302@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +haypo, yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 00:47:14 2014 From: report at bugs.python.org (Shankar Unni) Date: Fri, 18 Apr 2014 22:47:14 +0000 Subject: [issue21302] time.sleep (floatsleep()) should use clock_nanosleep() on Linux In-Reply-To: <1397851923.06.0.0550198760464.issue21302@psf.upfronthosting.co.za> Message-ID: <1397861234.54.0.409413576842.issue21302@psf.upfronthosting.co.za> Shankar Unni added the comment: I'm working on a patch, but I noticed a similar issue in Condition.wait(), which also keeps re-evaluating the "remaining sleep time" based on the current kernel clock, with similar effects. I'll try to address both issues, or we could open a separate bug for the latter.. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 00:47:22 2014 From: report at bugs.python.org (Kinga Farkas) Date: Fri, 18 Apr 2014 22:47:22 +0000 Subject: [issue21279] str.translate documentation incomplete In-Reply-To: <1397696482.87.0.486412592823.issue21279@psf.upfronthosting.co.za> Message-ID: <1397861242.93.0.340464957671.issue21279@psf.upfronthosting.co.za> Kinga Farkas added the comment: I have created a patch based on Martin Panter's suggestions. Please let me know if it is off or there should be additional changes included. ---------- keywords: +patch nosy: +lilbludot Added file: http://bugs.python.org/file34966/issue21279.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 01:52:20 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 18 Apr 2014 23:52:20 +0000 Subject: [issue21253] Difflib.compare() crashes on mostly different sequences In-Reply-To: <1397663686.19.0.71446048811.issue21253@psf.upfronthosting.co.za> Message-ID: <1397865140.2.0.325819609858.issue21253@psf.upfronthosting.co.za> Gregory P. Smith added the comment: It appears to devolve into linear recursion in this case, one per each item in one of the sequences being searched for a match, so even using a stack seems wrong as it'd still be linear (though it would prevent the recursion depth problem). The mutual _fancy_replace + _fancy_helper linear recursion comes from http://hg.python.org/cpython/file/604b74f9a07d/Lib/difflib.py#l1021 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 01:57:12 2014 From: report at bugs.python.org (Eric Snow) Date: Fri, 18 Apr 2014 23:57:12 +0000 Subject: [issue19771] runpy should check ImportError.name before wrapping it In-Reply-To: <1385383187.11.0.803942496087.issue19771@psf.upfronthosting.co.za> Message-ID: <1397865432.08.0.164183310501.issue19771@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 02:08:48 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 19 Apr 2014 00:08:48 +0000 Subject: [issue21279] str.translate documentation incomplete In-Reply-To: <1397696482.87.0.486412592823.issue21279@psf.upfronthosting.co.za> Message-ID: <1397866128.12.0.739102602152.issue21279@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The docstring is more accurate. ">>> str.translate.__doc__ 'S.translate(table) -> str\n\nReturn a copy of the string S, where all characters have been mapped\nthrough the given translation table, which must be a mapping of\nUnicode ordinals to Unicode ordinals, strings, or None.\nUnmapped characters are left untouched. Characters mapped to None\nare deleted.'"" To me, even this is a bit unclear on exceptions and 'unmapped'. Based on experiments and then reading the C source, I determined that LookupErrors mean 'unmapped' while other exceptions are passed on and terminate the translation. "Return a copy of the string S, where all characters have been mapped through the given translation table. When subscripted by a Unicode ordinal (integer in range(1048576)), the table must return a Unicode ordinal, string, or None, or else raise a LookupError. A LookupError, which includes instances of subclasses IndexError and KeyError, indicates that the character is unmapped and should be left untouched. Characters mapped to None are deleted." class Table: def __getitem__(self, key): if key == 99: raise LookupError() #'c' elif key == 100: return None # 'd' elif key == 101: return 'xyz' # 'e' else: return key+1 print('abcdef'.translate(Table())) # bccxyzg The current doc ends with "Note An even more flexible approach is to create a custom character mapping codec using the codecs module (see encodings.cp1251 for an example)." I don't see how this is supposed to help. Encodings.cp1251 uses a string of 256 chars as a lookup table. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 02:10:17 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 19 Apr 2014 00:10:17 +0000 Subject: [issue21279] str.translate documentation incomplete In-Reply-To: <1397696482.87.0.486412592823.issue21279@psf.upfronthosting.co.za> Message-ID: <1397866217.97.0.342892705466.issue21279@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I see that we mostly added the same info. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 02:26:49 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 19 Apr 2014 00:26:49 +0000 Subject: [issue21284] IDLE reformat tests fail in presence of non-default FormatParagraph setting In-Reply-To: <1397747979.02.0.575213731893.issue21284@psf.upfronthosting.co.za> Message-ID: <1397867209.67.0.655373641493.issue21284@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I noticed the same while working on #21139 and posted there a patch, 21139-34-fpe.diff, that adds a limit parameter to .format_paragraph_event. Test could then specify a width for each test without touching the user configuration. Different tests could use different widths. An explicit width is already used for testing the implementaton functions called by this method. ---------- assignee: -> terry.reedy nosy: +terry.reedy stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 02:30:17 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 19 Apr 2014 00:30:17 +0000 Subject: [issue21295] Python 3.4 gives wrong col_offset for Call nodes returned from ast.parse In-Reply-To: <1397818180.59.0.739018200129.issue21295@psf.upfronthosting.co.za> Message-ID: <1397867417.37.0.973170210114.issue21295@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: +benjamin.peterson, brett.cannon, georg.brandl, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 02:35:27 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 19 Apr 2014 00:35:27 +0000 Subject: [issue21297] csv.skipinitialspace only skips spaces, not "whitespace" in general In-Reply-To: <1397821941.61.0.706896478348.issue21297@psf.upfronthosting.co.za> Message-ID: <1397867727.01.0.298725400673.issue21297@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Do I understand correctly that only one space is ignored? ---------- nosy: +terry.reedy stage: -> needs patch title: skipinitialspace in the csv module only skips spaces, not "whitespace" in general -> csv.skipinitialspace only skips spaces, not "whitespace" in general versions: -Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 02:38:26 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 19 Apr 2014 00:38:26 +0000 Subject: [issue21295] Python 3.4 gives wrong col_offset for Call nodes returned from ast.parse In-Reply-To: <1397818180.59.0.739018200129.issue21295@psf.upfronthosting.co.za> Message-ID: <1397867905.99.0.513828698615.issue21295@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I suspect this was an intentional result of #16795. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 02:45:55 2014 From: report at bugs.python.org (Alok Singhal) Date: Sat, 19 Apr 2014 00:45:55 +0000 Subject: [issue6305] islice doesn't accept large stop values In-Reply-To: <1245309263.43.0.625809679675.issue6305@psf.upfronthosting.co.za> Message-ID: <1397868355.21.0.14815405627.issue6305@psf.upfronthosting.co.za> Alok Singhal added the comment: Here's a proposed patch. I need more tests for large values, but all the tests I could think of take a long time to get to a long value. I added some tests that don't take much time but work correctly for long values. If anyone has any ideas for some other tests, please let me know. ---------- keywords: +patch Added file: http://bugs.python.org/file34967/islice_large_values.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 02:47:14 2014 From: report at bugs.python.org (Martin Panter) Date: Sat, 19 Apr 2014 00:47:14 +0000 Subject: [issue19829] _pyio.BufferedReader and _pyio.TextIOWrapper destructor don't emit ResourceWarning if the file is not closed In-Reply-To: <1385721421.95.0.384748799117.issue19829@psf.upfronthosting.co.za> Message-ID: <1397868434.61.0.829017536879.issue19829@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 02:49:06 2014 From: report at bugs.python.org (Alex Gaynor) Date: Sat, 19 Apr 2014 00:49:06 +0000 Subject: [issue21304] Backport hashlib.pbkdf2_hmac to Python 2.7 Message-ID: <1397868546.19.0.546105502788.issue21304@psf.upfronthosting.co.za> New submission from Alex Gaynor: Pursuant to PEP466, this is a backport of Python 3.4's hashlib.pbkdf2_hmac. Of note in this patch: * None of the utilities for testing both a python and a C implementation simultaneously were present, so this only tests whichever implementation is available. * Due to a variety of API changes and missing APIs, the code is not an exact copy-paste, tough luck :-) * I haven't done docs yet. * It currently accepts unicode values because the ``y*`` format from Python3 doesn't have any parallel in Python2. I'm not sure whether consistency with the rest of the 2-verse is more important than consistency with a sane way to treat data / the 3-verse. ---------- components: Extension Modules, Library (Lib) files: pbkdf2.diff keywords: patch, security_issue messages: 216823 nosy: alex priority: normal severity: normal status: open title: Backport hashlib.pbkdf2_hmac to Python 2.7 versions: Python 2.7 Added file: http://bugs.python.org/file34968/pbkdf2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 02:49:36 2014 From: report at bugs.python.org (Alex Gaynor) Date: Sat, 19 Apr 2014 00:49:36 +0000 Subject: [issue21304] Backport hashlib.pbkdf2_hmac to Python 2.7 In-Reply-To: <1397868546.19.0.546105502788.issue21304@psf.upfronthosting.co.za> Message-ID: <1397868576.97.0.172409586694.issue21304@psf.upfronthosting.co.za> Changes by Alex Gaynor : ---------- nosy: +christian.heimes, dstufft, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 02:51:14 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 19 Apr 2014 00:51:14 +0000 Subject: [issue21305] PEP 466: update os.urandom Message-ID: <1397868674.52.0.918643592406.issue21305@psf.upfronthosting.co.za> New submission from Nick Coghlan: Tracker issue for the os.urandom persistent file descriptor backport to 2.7 described in PEP 466. ---------- messages: 216824 nosy: alex, benjamin.peterson, christian.heimes, dstufft, giampaolo.rodola, janssen, ncoghlan, pitrou priority: normal severity: normal stage: needs patch status: open title: PEP 466: update os.urandom type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 02:53:02 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 19 Apr 2014 00:53:02 +0000 Subject: [issue21232] Use of '1' instead of 'True' as 'splitlines' argument in difflib documentation In-Reply-To: <1397542231.28.0.662234584475.issue21232@psf.upfronthosting.co.za> Message-ID: <1397868782.64.0.257254209549.issue21232@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I believe that there have been discussions on this point and my memory is to leave 1 alone in 2.x docs. I could be mistaken though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 02:53:07 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 19 Apr 2014 00:53:07 +0000 Subject: [issue21306] PEP 466: backport hmac.compare_digest Message-ID: <1397868787.47.0.118679212536.issue21306@psf.upfronthosting.co.za> New submission from Nick Coghlan: Tracker issue for the hmac.compare_digest backport to 2.7 described in PEP 466. ---------- messages: 216826 nosy: alex, benjamin.peterson, christian.heimes, dstufft, giampaolo.rodola, janssen, ncoghlan, pitrou priority: normal severity: normal stage: needs patch status: open title: PEP 466: backport hmac.compare_digest type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 02:54:56 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 19 Apr 2014 00:54:56 +0000 Subject: [issue21307] PEP 466: backport hashlib changes Message-ID: <1397868896.33.0.304799131089.issue21307@psf.upfronthosting.co.za> New submission from Nick Coghlan: Tracker issue for the hashlib PBKDF2 and algorithm availability details backport to 2.7 described in PEP 466. ---------- messages: 216827 nosy: alex, benjamin.peterson, christian.heimes, dstufft, giampaolo.rodola, janssen, ncoghlan, pitrou priority: normal severity: normal stage: needs patch status: open title: PEP 466: backport hashlib changes type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 02:55:20 2014 From: report at bugs.python.org (Alex Gaynor) Date: Sat, 19 Apr 2014 00:55:20 +0000 Subject: [issue21307] PEP 466: backport hashlib changes In-Reply-To: <1397868896.33.0.304799131089.issue21307@psf.upfronthosting.co.za> Message-ID: <1397868920.31.0.194519049994.issue21307@psf.upfronthosting.co.za> Alex Gaynor added the comment: issue21304 has the implementation of the PBKDF2 work. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 02:55:56 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 19 Apr 2014 00:55:56 +0000 Subject: [issue21308] PEP 466: backport ssl changes Message-ID: <1397868956.56.0.0572466011298.issue21308@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- nosy: alex, benjamin.peterson, christian.heimes, dstufft, giampaolo.rodola, janssen, ncoghlan, pitrou priority: normal severity: normal stage: needs patch status: open title: PEP 466: backport ssl changes type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 03:05:23 2014 From: report at bugs.python.org (Alex Gaynor) Date: Sat, 19 Apr 2014 01:05:23 +0000 Subject: [issue21304] Backport hashlib.pbkdf2_hmac to Python 2.7 In-Reply-To: <1397868546.19.0.546105502788.issue21304@psf.upfronthosting.co.za> Message-ID: <1397869523.74.0.689474869638.issue21304@psf.upfronthosting.co.za> Changes by Alex Gaynor : ---------- nosy: +benjamin.peterson, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 03:33:28 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 19 Apr 2014 01:33:28 +0000 Subject: [issue21307] PEP 466: backport hashlib changes In-Reply-To: <1397868896.33.0.304799131089.issue21307@psf.upfronthosting.co.za> Message-ID: <1397871208.62.0.612614774384.issue21307@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Let's dup this then. ---------- resolution: -> duplicate status: open -> closed superseder: -> Backport hashlib.pbkdf2_hmac to Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 03:35:24 2014 From: report at bugs.python.org (Tim Peters) Date: Sat, 19 Apr 2014 01:35:24 +0000 Subject: [issue21253] Difflib.compare() crashes on mostly different sequences In-Reply-To: <1397663686.19.0.71446048811.issue21253@psf.upfronthosting.co.za> Message-ID: <1397871324.49.0.975166389939.issue21253@psf.upfronthosting.co.za> Tim Peters added the comment: Comparison can certainly trigger a recursion error if the sequences contain no (or few) matching non-junk elements, but contain many "almost matching" elements. If the sequences have lengths M and N, recursion can go as deep as 2*min(M, N) then. Now in the test case, we have two lists of integers. Difflib has no idea what "almost match" might mean for integers. But difflib isn't passed two lists of integers. Instead unittest appears to be converting the input lists to giant strings, then splitting the giant strings on whitespace (or just linefeeds?), and then feeding the resulting lists of substrings to difflib. That doesn't make much sense to me, but so it goes. There are no matches in the two lists of strings, so difflib starts looking for "close matches", and there are a lot of these. At first it decides "[1," and "[100," aren't close enough, but " 10," and " 101," are close enough. That's used as a synch point, and then there's recursion to match the sublists before and after the synch point. Then " 12," and " 102," are close enough, so that pair is used as the next synch point, and another layer of 2-sided recursion. Etc. Whether someone wants to rip the recursion out of _fancy_replace and _fancy_helper is up to them. I wouldn't bother, if this unittest-created problem is the only reported instance. Comparing strings seems a poor idea from the start (there's no guarantee in general, e.g., that A != B implies str(A) != str(B) or repr(A) != repr(B)), and difflib isn't good in any case at comparing sequences with few matching elements (e.g., remove the recursion and it will still take time at best cubic in the common length of the sequences - would it really help to change "a failing unittest bombs with RecursionError" to "a failing unittest seems to take forever"?). I'd suggest instead that unittest, say, locate the first pair of non-equal elements itself, and display that along with a few elements of context on either side. Or something ;-) Something worst-case linear-time, and using != directly on sequence elements (not on strings derived from the sequence elements). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 03:40:18 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 19 Apr 2014 01:40:18 +0000 Subject: [issue21307] PEP 466: backport hashlib changes In-Reply-To: <1397868896.33.0.304799131089.issue21307@psf.upfronthosting.co.za> Message-ID: <1397871618.65.0.70715609329.issue21307@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Rather #21304 should be a dep... ---------- dependencies: +Backport hashlib.pbkdf2_hmac to Python 2.7 resolution: duplicate -> status: closed -> open superseder: Backport hashlib.pbkdf2_hmac to Python 2.7 -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 03:48:03 2014 From: report at bugs.python.org (Charles-Axel Dein) Date: Sat, 19 Apr 2014 01:48:03 +0000 Subject: [issue20351] Add doc examples for DictReader and DictWriter In-Reply-To: <1390414077.91.0.281809568509.issue20351@psf.upfronthosting.co.za> Message-ID: <1397872083.69.0.00519960920259.issue20351@psf.upfronthosting.co.za> Charles-Axel Dein added the comment: New version of the patch. ---------- Added file: http://bugs.python.org/file34969/add_csvdict_examples.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 04:04:23 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 19 Apr 2014 02:04:23 +0000 Subject: [issue21253] unittest assertSequenceEqual can lead to Difflib.compare() crashing on mostly different sequences In-Reply-To: <1397663686.19.0.71446048811.issue21253@psf.upfronthosting.co.za> Message-ID: <1397873063.07.0.156666360365.issue21253@psf.upfronthosting.co.za> Gregory P. Smith added the comment: that seems reasonable. unittest's assertSequenceEqual is using this to attempt to display a useful error message as to what the delta was; it should try harder to avoid difflib corner cases. At the very least, unittest should recover from a difflib failure and report a test failure without the possibly nicer message. ---------- title: Difflib.compare() crashes on mostly different sequences -> unittest assertSequenceEqual can lead to Difflib.compare() crashing on mostly different sequences _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 04:17:06 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 19 Apr 2014 02:17:06 +0000 Subject: [issue21309] Confusing "see also" for generic C-level __init__ methods in help output Message-ID: <1397873826.04.0.28447838355.issue21309@psf.upfronthosting.co.za> New submission from R. David Murray: >>> help(ImportError.__init__) Help on wrapper_descriptor: __init__(self, /, *args, **kwargs) Initialize self. See help(type(self)) for accurate signature. The above also appears (without the wrapper_descriptor bit) in the help output for help(ImportError). In neither case does 'help(type(self))' tell the naive user anything useful, since 'self' doesn't exist in the scope in which they are executing help. I don't know where this text is coming from (Argument Clinic?), but it could use improvement. I believe it is trying to say that one should see the help information for the class object. I'm not sure how you'd spell that usefully. Maybe "See the object's main help for a more accurate signature"? And maybe I shouldn't have said naive user: I'm an experienced python developer, and I tried 'help(type(ImportError))', since I saw the above when I'd typed 'help(ImportError)', and it was only when I got the help for 'type' that I realized what it was trying to tell me. Now, I tried this because the ImportError help does not in fact give the "more accurate signature", which is a different issue, but you get the point. We also have: >>> x = ImportError() >>> help(x.__init__) Help on method-wrapper object: __init__ = class method-wrapper(object) | Methods defined here: | | __call__(self, /, *args, **kwargs) | Call self as a function. Maybe that's another bug? Maybe not. NB: in 3.3 the text is: | __init__(...) | x.__init__(...) initializes x; see help(type(x)) for signature So that was worse, since the only time you would see in isolation would be when you are calling help on the class (help(ImportError.__init__)...in which case 'x' is ImportError, and type(x) is...type. So 3.4 is *better*, but I don't think it is as good as we can do. ---------- components: Interpreter Core messages: 216836 nosy: larry, r.david.murray priority: normal severity: normal status: open title: Confusing "see also" for generic C-level __init__ methods in help output type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 04:21:11 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Sat, 19 Apr 2014 02:21:11 +0000 Subject: [issue21308] PEP 466: backport ssl changes Message-ID: <1397874071.85.0.698117966406.issue21308@psf.upfronthosting.co.za> Changes by Josh Rosenberg : ---------- nosy: +josh.rosenberg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 04:21:32 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Sat, 19 Apr 2014 02:21:32 +0000 Subject: [issue21305] PEP 466: update os.urandom In-Reply-To: <1397868674.52.0.918643592406.issue21305@psf.upfronthosting.co.za> Message-ID: <1397874092.35.0.403578972343.issue21305@psf.upfronthosting.co.za> Changes by Josh Rosenberg : ---------- nosy: +josh.rosenberg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 04:23:08 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 19 Apr 2014 02:23:08 +0000 Subject: [issue21230] imghdr does not accept adobe photoshop mime type In-Reply-To: <1397524431.49.0.471880586962.issue21230@psf.upfronthosting.co.za> Message-ID: <1397874188.79.0.280489328356.issue21230@psf.upfronthosting.co.za> R. David Murray added the comment: Well, it's 'expected' behavior in the sense that we don't know about 'adobe' format. Is there some better way to detect jpeg format than to look for particular format identifiers in a specific byte position? ---------- type: enhancement -> behavior versions: +Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 04:25:19 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 19 Apr 2014 02:25:19 +0000 Subject: [issue21304] PEP 446: Backport hashlib.pbkdf2_hmac to Python 2.7 In-Reply-To: <1397868546.19.0.546105502788.issue21304@psf.upfronthosting.co.za> Message-ID: <1397874319.49.0.815920666046.issue21304@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- title: Backport hashlib.pbkdf2_hmac to Python 2.7 -> PEP 446: Backport hashlib.pbkdf2_hmac to Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 04:32:26 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 19 Apr 2014 02:32:26 +0000 Subject: [issue21304] PEP 466: Backport hashlib.pbkdf2_hmac to Python 2.7 In-Reply-To: <1397868546.19.0.546105502788.issue21304@psf.upfronthosting.co.za> Message-ID: <1397874746.46.0.157820794632.issue21304@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- title: PEP 446: Backport hashlib.pbkdf2_hmac to Python 2.7 -> PEP 466: Backport hashlib.pbkdf2_hmac to Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 05:23:49 2014 From: report at bugs.python.org (Martin Panter) Date: Sat, 19 Apr 2014 03:23:49 +0000 Subject: [issue21310] ResourceWarning when open() fails with io.UnsupportedOperation: File or stream is not seekable Message-ID: <1397877829.49.0.0015217310404.issue21310@psf.upfronthosting.co.za> New submission from Martin Panter: >>> f = open("/dev/stdout", "w+b") # Or any non-seekable file, pipe, etc __main__:1: ResourceWarning: unclosed file <_io.FileIO name='/dev/stdout' mode='rb+'> Traceback (most recent call last): File "", line 1, in io.UnsupportedOperation: File or stream is not seekable. It is mainly just the annoyance of the ResourceWarning, so nothing major. I think this was previously identified in Issue 18116, but it looks like that bug was side-stepped by removing an equivalent fdopen() call. No ResourceWarning happens with an unbuffered file. I haven?t looked at the code but I guess the UnsupportedOperation might only be raised after trying to wrap the open FileIO object in a BufferedWriter object. ---------- components: IO messages: 216838 nosy: vadmium priority: normal severity: normal status: open title: ResourceWarning when open() fails with io.UnsupportedOperation: File or stream is not seekable versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 05:25:13 2014 From: report at bugs.python.org (Martin Panter) Date: Sat, 19 Apr 2014 03:25:13 +0000 Subject: [issue18116] getpass.unix_getpass() always fallback to sys.stdin In-Reply-To: <1370130607.39.0.486408621645.issue18116@psf.upfronthosting.co.za> Message-ID: <1397877913.05.0.826775810136.issue18116@psf.upfronthosting.co.za> Martin Panter added the comment: I opened Issue 21310 about a ResourceWarning from open() which I suspect is the same as what was originally described here. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 05:34:59 2014 From: report at bugs.python.org (Eric Snow) Date: Sat, 19 Apr 2014 03:34:59 +0000 Subject: [issue21211] pkgutil.find_loader() raises ImportError instead of returning None In-Reply-To: <1397440098.66.0.10150246835.issue21211@psf.upfronthosting.co.za> Message-ID: <1397878499.04.0.163157251124.issue21211@psf.upfronthosting.co.za> Eric Snow added the comment: On second thought, all modules (except __main__) must have both __spec__ and __loader__ set to their correct respective objects. So the current behavior is correct in that it exposes poorly formed modules. ---------- resolution: -> not a bug stage: test needed -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 06:33:48 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 19 Apr 2014 04:33:48 +0000 Subject: [issue21304] PEP 466: Backport hashlib.pbkdf2_hmac to Python 2.7 In-Reply-To: <1397868546.19.0.546105502788.issue21304@psf.upfronthosting.co.za> Message-ID: <1397882028.57.0.0794865229231.issue21304@psf.upfronthosting.co.za> Gregory P. Smith added the comment: See also http://bugs.python.org/issue21288 to consider one fix/oversite/addition to the existing API as part of this process. (discuss that there) by default: use the exact same API as 3.4 if it is suitable for PEP 466 and 2.7.7's needs. the above issue is about fixing a possible oversight; so if it happens in 3.4 it should happen in 2.7.7. ---------- nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 06:34:53 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 19 Apr 2014 04:34:53 +0000 Subject: [issue21307] PEP 466: backport hashlib changes In-Reply-To: <1397868896.33.0.304799131089.issue21307@psf.upfronthosting.co.za> Message-ID: <1397882093.14.0.882350930463.issue21307@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 06:35:26 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 19 Apr 2014 04:35:26 +0000 Subject: [issue21308] PEP 466: backport ssl changes Message-ID: <1397882126.07.0.743903196648.issue21308@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 06:38:55 2014 From: report at bugs.python.org (Alex Gaynor) Date: Sat, 19 Apr 2014 04:38:55 +0000 Subject: [issue21304] PEP 466: Backport hashlib.pbkdf2_hmac to Python 2.7 In-Reply-To: <1397868546.19.0.546105502788.issue21304@psf.upfronthosting.co.za> Message-ID: <1397882335.31.0.0156623641049.issue21304@psf.upfronthosting.co.za> Alex Gaynor added the comment: Yup, I've got my eyes on it, if anything lands there I'll include it in this in the 2.7 code, whether it's before or after this patch lands :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 07:07:12 2014 From: report at bugs.python.org (Maciej Szulik) Date: Sat, 19 Apr 2014 05:07:12 +0000 Subject: [issue19662] smtpd.py should not decode utf-8 In-Reply-To: <1384944703.82.0.967643613195.issue19662@psf.upfronthosting.co.za> Message-ID: <1397884032.2.0.996160163018.issue19662@psf.upfronthosting.co.za> Maciej Szulik added the comment: Sreepriya, are you still working on this issue? If no I'll be happy to take it over, is yes start with fixing following things: - start with test - this is the most important to have each feautre tested - decode_data, as David mentioned, needs to have default value True, meaning that __init__ should look like this: def __init__(self, server, conn, addr, data_size_limit=DATA_SIZE_DEFAULT, map=None, decode_data=True) Assigning True in __init__ will make this value always True, and that's not the point. - add deprecation warning about this parameter using warnings module: warnings.warn('decode_data=True is deprecated, data will not be decoded by default', DeprecationWarning, 2) - as for the found_terminator method what David means is to decode data in the first if, where commands are checked, to simplify processing of this part (David please correct me if I'm wrong) and not what you did - and finally you need to update the docs to include decode_data parameter with information about how it works and it's deprecation ---------- nosy: +maciej.szulik _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 07:31:11 2014 From: report at bugs.python.org (Jessica McKellar) Date: Sat, 19 Apr 2014 05:31:11 +0000 Subject: [issue11748] test_ftplib failure in test for source_address In-Reply-To: <1301846814.75.0.746123609794.issue11748@psf.upfronthosting.co.za> Message-ID: <1397885471.34.0.425054899614.issue11748@psf.upfronthosting.co.za> Jessica McKellar added the comment: Antoine, thanks for the patch, and Giampaolo, thanks for the ping. I confirmed that http://hg.python.org/cpython/rev/8a2d848244a2 does address the issue: Before the patch, if another process bound to the port selected for the test before the test ran, the test would error out. After the patch, if this race happens the test is skipped instead. Anecdotally from local tests and from looking at recent buildbot builds, the test does generally run (so we don't have a problem with it skipping all the time and the behavior not getting tested). => Closing as resolved. ---------- nosy: +jesstess resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 07:45:47 2014 From: report at bugs.python.org (Igor Pashev) Date: Sat, 19 Apr 2014 05:45:47 +0000 Subject: [issue21287] Better support for AF_PACKET on opensolaris (illumos) In-Reply-To: <1397759947.91.0.17620010785.issue21287@psf.upfronthosting.co.za> Message-ID: <1397886347.32.0.160754423082.issue21287@psf.upfronthosting.co.za> Igor Pashev added the comment: Related to http://bugs.python.org/issue8852 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 07:46:14 2014 From: report at bugs.python.org (Igor Pashev) Date: Sat, 19 Apr 2014 05:46:14 +0000 Subject: [issue21287] Better support for AF_PACKET on opensolaris (illumos) In-Reply-To: <1397759947.91.0.17620010785.issue21287@psf.upfronthosting.co.za> Message-ID: <1397886374.25.0.941787450912.issue21287@psf.upfronthosting.co.za> Changes by Igor Pashev : Removed file: http://bugs.python.org/file34952/dyson-socketmodule-ifindex.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 08:14:02 2014 From: report at bugs.python.org (Aivar Annamaa) Date: Sat, 19 Apr 2014 06:14:02 +0000 Subject: [issue21295] Python 3.4 gives wrong col_offset for Call nodes returned from ast.parse In-Reply-To: <1397818180.59.0.739018200129.issue21295@psf.upfronthosting.co.za> Message-ID: <1397888042.42.0.58492972513.issue21295@psf.upfronthosting.co.za> Aivar Annamaa added the comment: Regarding #16795, the documentation says "The lineno is the line number of source text and the col_offset is the UTF-8 byte offset of the first token that generated the node", not that lineno and col_offset indicate a suitable position to mention in the error messages related to this node. IMO lineno and col_offset should stay as predictable means for finding the (beginning of) source text of the node. In error reporting code one could inspect the situation and compute locations suitable for this. Alternatively, these attributes could be left for purposes mentioned in #16795 and parser developers could introduce new attributes in ast nodes which indicate both start and end positions of corresponding source. (Hopefully this would resolve also #18374 and #16806) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 08:17:48 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 19 Apr 2014 06:17:48 +0000 Subject: [issue21200] pkgutil.get_loader() fails on "__main__" In-Reply-To: <1397225255.72.0.022634576387.issue21200@psf.upfronthosting.co.za> Message-ID: <3g9kVg1KWJz7LjN@mail.python.org> Roundup Robot added the comment: New changeset bc4eb1b3db5d by Eric Snow in branch '3.4': Issue #21200: Return None from pkgutil.get_loader() when __spec__ is missing. http://hg.python.org/cpython/rev/bc4eb1b3db5d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 08:20:35 2014 From: report at bugs.python.org (Eric Snow) Date: Sat, 19 Apr 2014 06:20:35 +0000 Subject: [issue21200] pkgutil.get_loader() fails on "__main__" In-Reply-To: <1397225255.72.0.022634576387.issue21200@psf.upfronthosting.co.za> Message-ID: <1397888435.42.0.308971807152.issue21200@psf.upfronthosting.co.za> Eric Snow added the comment: The change is pretty minor so I went ahead and pushed it. To be honest, we should consider deprecating both get_loader and find_loader. I'm just not going to worry about it right now. :) ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 09:34:44 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Sat, 19 Apr 2014 07:34:44 +0000 Subject: [issue15002] urllib2 does not download 4 MB file completely using ftp In-Reply-To: <1338840881.84.0.164546182047.issue15002@psf.upfronthosting.co.za> Message-ID: <1397892884.36.0.754928748544.issue15002@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Christian's patch is good.It helps in setting the socket.makefile file descriptor to a well behaving well file close wrapper and thus will help us prevent some tricky fd close issues. I added tests for coverage to ensure that we are asserting the type and covering all the methods in urllib.response. Attaching the patch built on top of Chritians one. ---------- Added file: http://bugs.python.org/file34970/issue15002.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 09:49:57 2014 From: report at bugs.python.org (Eric Snow) Date: Sat, 19 Apr 2014 07:49:57 +0000 Subject: [issue21226] PyImport_ExecCodeModuleObject not setting module attributes In-Reply-To: <1397509467.13.0.547431443442.issue21226@psf.upfronthosting.co.za> Message-ID: <1397893797.55.0.907646796097.issue21226@psf.upfronthosting.co.za> Eric Snow added the comment: Here's a (currently segfaulting) patch that demonstrates how I'd like to solve this. Feedback on the approach is welcome. :) When I get a chance I'll debug the segfault. ---------- assignee: -> eric.snow keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file34971/fix-PyImport_ExecCodeModuleObject.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 10:30:42 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Sat, 19 Apr 2014 08:30:42 +0000 Subject: [issue10362] AttributeError: addinfourl instance has no attribute 'tell' In-Reply-To: <1289237897.0.0.279670034262.issue10362@psf.upfronthosting.co.za> Message-ID: <1397896242.44.0.118508087883.issue10362@psf.upfronthosting.co.za> Senthil Kumaran added the comment: I agree. Having tell on a file descriptor of a URL request is not going to be of help. You can easily write to a local file and use all the local file features, if it is things like .tell is desired. ---------- resolution: -> not a bug stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 11:10:49 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 19 Apr 2014 09:10:49 +0000 Subject: [issue21305] PEP 466: update os.urandom In-Reply-To: <1397868674.52.0.918643592406.issue21305@psf.upfronthosting.co.za> Message-ID: <1397898649.91.0.48102966795.issue21305@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Why exactly does it need to be backported? os.urandom under 2.7 works fine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 11:13:33 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 19 Apr 2014 09:13:33 +0000 Subject: [issue21292] C API in debug fails In-Reply-To: <1397771478.75.0.526004579779.issue21292@psf.upfronthosting.co.za> Message-ID: <1397898813.41.0.649598673101.issue21292@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I think the issue is actually slightly different. You can certainly build your Python "in debug", and still link with the release mode Python. The question is what "in debug" means, and the normal definition would be "with the generation of debug symbols by the compiler". What you cannot do is 1. to build with _DEBUG defined (or whatever the exact spelling of the macro is, or 2. to link with the debug version of msvcrt. We could fix 1, i.e. allowing you to define _DEBUG, and still bind the release version. I think we cannot reasonably fix 2; this is a Microsoft issue. You can work around by simply not defining _DEBUG, and still build "in debug" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 11:39:27 2014 From: report at bugs.python.org (Cory Benfield) Date: Sat, 19 Apr 2014 09:39:27 +0000 Subject: [issue21308] PEP 466: backport ssl changes Message-ID: <1397900367.61.0.249367049284.issue21308@psf.upfronthosting.co.za> Changes by Cory Benfield : ---------- nosy: +Lukasa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 11:46:09 2014 From: report at bugs.python.org (Christian Heimes) Date: Sat, 19 Apr 2014 09:46:09 +0000 Subject: [issue21308] PEP 466: backport ssl changes In-Reply-To: <1397900367.74.0.456208226652.issue21308@psf.upfronthosting.co.za> Message-ID: <9f606957-c0fc-42fe-b0e1-52ea1cb44333@email.android.com> New submission from Christian Heimes: I'm interested to assist with all back port tickets as soon as my internet connection is fixed. A technician is going to check my line again on Tuesday. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 11:46:44 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 19 Apr 2014 09:46:44 +0000 Subject: [issue21308] PEP 466: backport ssl changes In-Reply-To: <9f606957-c0fc-42fe-b0e1-52ea1cb44333@email.android.com> Message-ID: <1397900804.86.0.150288625644.issue21308@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I'm not really interested to assist with backport tickets myself. You may nosy me but I may not care at all :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 12:06:26 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 19 Apr 2014 10:06:26 +0000 Subject: [issue21287] Better support for AF_PACKET on opensolaris (illumos) In-Reply-To: <1397759947.91.0.17620010785.issue21287@psf.upfronthosting.co.za> Message-ID: <1397901986.46.0.437290448176.issue21287@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +neologix stage: -> patch review versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 15:21:02 2014 From: report at bugs.python.org (John Szakmeister) Date: Sat, 19 Apr 2014 13:21:02 +0000 Subject: [issue21311] Fix compiler detection when brew's ccache is installed on Mac OS X Message-ID: <1397913662.53.0.885648478854.issue21311@psf.upfronthosting.co.za> New submission from John Szakmeister: It's pretty typical for ccache packages to install symlinks for compilers that may not be present on the system, such as Homebrew's ccache package. Unfortunately, the _osx_support.py file is mislead by the presence of the symlink and ends up backtracing. This issue is present in 2.7 and onwards. I'm attaching two possible fixes for the problem, both created against 2.7. The issue is that the symlink in detected, but _read_output() returns None, which then fails when the output is examined (if 'str' in None...). The first patch does a simple non-empty check. The alternate version makes _read_output() return an empty string instead of None. ---------- components: Distutils files: fix-osx-llvm-detection-with-ccache.patch keywords: patch messages: 216856 nosy: dstufft, eric.araujo, jszakmeister priority: normal severity: normal status: open title: Fix compiler detection when brew's ccache is installed on Mac OS X versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file34972/fix-osx-llvm-detection-with-ccache.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 15:21:40 2014 From: report at bugs.python.org (John Szakmeister) Date: Sat, 19 Apr 2014 13:21:40 +0000 Subject: [issue21311] Fix compiler detection when brew's ccache is installed on Mac OS X In-Reply-To: <1397913662.53.0.885648478854.issue21311@psf.upfronthosting.co.za> Message-ID: <1397913700.25.0.504675824461.issue21311@psf.upfronthosting.co.za> John Szakmeister added the comment: Here's the alternate fix. ---------- Added file: http://bugs.python.org/file34973/alt-fix-osx-llvm-detection-with-ccache.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 15:59:13 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 19 Apr 2014 13:59:13 +0000 Subject: [issue21305] PEP 466: update os.urandom In-Reply-To: <1397898649.91.0.48102966795.issue21305@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: It was in the list of security fixes Alex and Donald wanted to reduce vulnerabilities in 2.x network services, and Guido was OK with backporting it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 16:05:38 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 19 Apr 2014 14:05:38 +0000 Subject: [issue21305] PEP 466: update os.urandom In-Reply-To: Message-ID: <1397916335.2345.10.camel@fsol> Antoine Pitrou added the comment: > It was in the list of security fixes Alex and Donald wanted to reduce > vulnerabilities in 2.x network services, and Guido was OK with backporting > it. What security issue is there exactly? os.urandom() does a similar thing in 2.7 and 3.x (it reads from /dev/urandom). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 16:34:59 2014 From: report at bugs.python.org (Alex Gaynor) Date: Sat, 19 Apr 2014 14:34:59 +0000 Subject: [issue21305] PEP 466: update os.urandom In-Reply-To: <1397868674.52.0.918643592406.issue21305@psf.upfronthosting.co.za> Message-ID: <1397918099.8.0.212907016537.issue21305@psf.upfronthosting.co.za> Alex Gaynor added the comment: It's not a security issue per-se, but if you're doing many small reads, there's such an enormous performance and scalability difference that if users run into an issue, they're likely to work around it by using a non-CS PRNG, and compromising their application security. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 16:39:22 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 19 Apr 2014 14:39:22 +0000 Subject: [issue21305] PEP 466: update os.urandom In-Reply-To: <1397918099.8.0.212907016537.issue21305@psf.upfronthosting.co.za> Message-ID: <1397918360.2345.12.camel@fsol> Antoine Pitrou added the comment: > It's not a security issue per-se, but if you're doing many small > reads, there's such an enormous performance and scalability difference > that if users run into an issue, they're likely to work around it by > using a non-CS PRNG, and compromising their application security. Do you have any examples of this or is it just a gratuitous inference? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 16:41:29 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 19 Apr 2014 14:41:29 +0000 Subject: [issue21305] PEP 466: update os.urandom In-Reply-To: <1397868674.52.0.918643592406.issue21305@psf.upfronthosting.co.za> Message-ID: <1397918489.45.0.395607580977.issue21305@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Note that the 3.4 scheme is not fully debugged yet: issue21207. There is a reason we don't backport new features! Regardless, I'm not interested in this, so I'll let you take the risk of regressions if you want to. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 16:41:39 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 19 Apr 2014 14:41:39 +0000 Subject: [issue21305] PEP 466: update os.urandom In-Reply-To: <1397868674.52.0.918643592406.issue21305@psf.upfronthosting.co.za> Message-ID: <1397918499.11.0.24945347118.issue21305@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: -pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 16:43:31 2014 From: report at bugs.python.org (Alex Gaynor) Date: Sat, 19 Apr 2014 14:43:31 +0000 Subject: [issue21207] urandom persistent fd - not re-openned after fd close In-Reply-To: <1397316819.31.0.463593532744.issue21207@psf.upfronthosting.co.za> Message-ID: <1397918611.82.0.916939344531.issue21207@psf.upfronthosting.co.za> Changes by Alex Gaynor : ---------- nosy: +alex _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 17:47:27 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Sat, 19 Apr 2014 15:47:27 +0000 Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za> Message-ID: <1397922447.89.0.795159750475.issue18967@psf.upfronthosting.co.za> Changes by Senthil Kumaran : ---------- nosy: -orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 17:55:30 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Sat, 19 Apr 2014 15:55:30 +0000 Subject: [issue16827] Remove the relatively advanced content from section 2 in tutorial In-Reply-To: <1356964896.19.0.673901752517.issue16827@psf.upfronthosting.co.za> Message-ID: <1397922930.5.0.00560842047566.issue16827@psf.upfronthosting.co.za> Senthil Kumaran added the comment: For this bug, I think, section 2.2.4 and section 2.2.5 can be moved to section 13 and inserted between section 13.1 and 13.2 as it seem to be fit in naturally there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 18:00:57 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Sat, 19 Apr 2014 16:00:57 +0000 Subject: [issue2052] Allow changing difflib._file_template character encoding. In-Reply-To: <1202505714.47.0.79762903943.issue2052@psf.upfronthosting.co.za> Message-ID: <1397923257.23.0.155161940679.issue2052@psf.upfronthosting.co.za> Changes by Senthil Kumaran : ---------- nosy: -orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 18:53:09 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 19 Apr 2014 16:53:09 +0000 Subject: [issue21226] PyImport_ExecCodeModuleObject not setting module attributes In-Reply-To: <1397509467.13.0.547431443442.issue21226@psf.upfronthosting.co.za> Message-ID: <1397926389.68.0.175805039772.issue21226@psf.upfronthosting.co.za> Benjamin Peterson added the comment: The last argument to _PyObject_CallMethodIdObjArgs needs to be NULL... ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 19:06:47 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 19 Apr 2014 17:06:47 +0000 Subject: [issue9364] some problems with the documentation of pydoc In-Reply-To: <1279949027.26.0.1869842795.issue9364@psf.upfronthosting.co.za> Message-ID: <3gB0vV35BLz7Ljf@mail.python.org> Roundup Robot added the comment: New changeset 16207b8495bf by R David Murray in branch '3.4': #9364: Improve the text printed by help(pydoc) and help(help). http://hg.python.org/cpython/rev/16207b8495bf New changeset 256c782ab078 by R David Murray in branch 'default': Merge: #9364: Improve the text printed by help(pydoc) and help(help). http://hg.python.org/cpython/rev/256c782ab078 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 19:09:30 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 19 Apr 2014 17:09:30 +0000 Subject: [issue9364] some problems with the documentation of pydoc In-Reply-To: <1279949027.26.0.1869842795.issue9364@psf.upfronthosting.co.za> Message-ID: <1397927370.48.0.940544256572.issue9364@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, Glenn. I tweaked the wording further. If someone thinks it is worth the effort to backport this to 2.7, they can do so and reopen the issue. ---------- assignee: eric.araujo -> nosy: +r.david.murray resolution: -> fixed stage: needs patch -> resolved status: open -> closed versions: +Python 3.4, Python 3.5 -Python 2.7, Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 19:30:33 2014 From: report at bugs.python.org (Jack McCracken) Date: Sat, 19 Apr 2014 17:30:33 +0000 Subject: [issue21312] Update thread_foobar.h to include timed locking and TLS support Message-ID: <1397928633.2.0.869900067411.issue21312@psf.upfronthosting.co.za> New submission from Jack McCracken: The thread_foobar.h reference for the interface for abstracting the platform-specific thread implementation does not include newer features such as timed locking and TLS support. ---------- components: Interpreter Core files: update_thread_foobar.diff keywords: patch messages: 216867 nosy: Jack.McCracken priority: normal severity: normal status: open title: Update thread_foobar.h to include timed locking and TLS support type: enhancement Added file: http://bugs.python.org/file34974/update_thread_foobar.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 19:33:38 2014 From: report at bugs.python.org (Jack McCracken) Date: Sat, 19 Apr 2014 17:33:38 +0000 Subject: [issue21312] Update thread_foobar.h to include timed locking and TLS support In-Reply-To: <1397928633.2.0.869900067411.issue21312@psf.upfronthosting.co.za> Message-ID: <1397928818.32.0.898880709052.issue21312@psf.upfronthosting.co.za> Jack McCracken added the comment: Missed a word in a comment ---------- Added file: http://bugs.python.org/file34975/update_thread_foobar_v2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 19:34:43 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 19 Apr 2014 17:34:43 +0000 Subject: [issue21312] Update thread_foobar.h to include timed locking and TLS support In-Reply-To: <1397928633.2.0.869900067411.issue21312@psf.upfronthosting.co.za> Message-ID: <1397928883.29.0.0212771768758.issue21312@psf.upfronthosting.co.za> Antoine Pitrou added the comment: You may want to provide an implementation of PyThread_acquire_lock() that simply defers to PyThread_acquire_lock_timed() (see thread_pthread.h, which does the same). ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 19:45:39 2014 From: report at bugs.python.org (Jack McCracken) Date: Sat, 19 Apr 2014 17:45:39 +0000 Subject: [issue21312] Update thread_foobar.h to include timed locking and TLS support In-Reply-To: <1397928633.2.0.869900067411.issue21312@psf.upfronthosting.co.za> Message-ID: <1397929539.95.0.713355341657.issue21312@psf.upfronthosting.co.za> Jack McCracken added the comment: Added an example of deferring to PyThread_acquire_lock_timed in PyThread_acquire_lock. Also fixed a mistake in the string of a dprintf in PyThread_acquire_lock_timed. ---------- Added file: http://bugs.python.org/file34976/update_thread_foobar_v3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 19:48:09 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 19 Apr 2014 17:48:09 +0000 Subject: [issue21312] Update thread_foobar.h to include timed locking and TLS support In-Reply-To: <1397928633.2.0.869900067411.issue21312@psf.upfronthosting.co.za> Message-ID: <1397929689.28.0.897099269338.issue21312@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Hum, your comment about deferring is wrong, since thread_nt.h also does the deferring: int PyThread_acquire_lock(PyThread_type_lock aLock, int waitflag) { return PyThread_acquire_lock_timed(aLock, waitflag ? -1 : 0, 0); } ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 19:50:54 2014 From: report at bugs.python.org (Jack McCracken) Date: Sat, 19 Apr 2014 17:50:54 +0000 Subject: [issue21312] Update thread_foobar.h to include timed locking and TLS support In-Reply-To: <1397928633.2.0.869900067411.issue21312@psf.upfronthosting.co.za> Message-ID: <1397929854.45.0.558446932499.issue21312@psf.upfronthosting.co.za> Jack McCracken added the comment: Oops... I removed that and just put the deferral in there. ---------- Added file: http://bugs.python.org/file34977/update_thread_foobar_v4.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 19:55:00 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 19 Apr 2014 17:55:00 +0000 Subject: [issue21312] Update thread_foobar.h to include timed locking and TLS support In-Reply-To: <1397928633.2.0.869900067411.issue21312@psf.upfronthosting.co.za> Message-ID: <1397930100.16.0.423136002294.issue21312@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thanks! The patch looks good to me, I'll let it sleep a bit to see if other people have an opinion. ---------- nosy: +tim.peters stage: -> patch review versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 20:54:10 2014 From: report at bugs.python.org (Jessica McKellar) Date: Sat, 19 Apr 2014 18:54:10 +0000 Subject: [issue7221] DispatcherWithSendTests_UsePoll with test_asyncore does nothing In-Reply-To: <1256668022.66.0.873968126347.issue7221@psf.upfronthosting.co.za> Message-ID: <1397933650.58.0.00731963440384.issue7221@psf.upfronthosting.co.za> Jessica McKellar added the comment: This looks like a copy-paste typo from test_asynchat, which does use `usepoll`. Attached is a patch that removes `usepoll` and a `DispatcherWithSendTests_UsePoll` TestCase that did nothing but set `usepoll=True`. * The diff passes `make patchcheck`. * The full test suite passes with this diff. ---------- keywords: +needs review, patch nosy: +jesstess stage: needs patch -> patch review Added file: http://bugs.python.org/file34978/issue7221.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 21:02:14 2014 From: report at bugs.python.org (Ned Deily) Date: Sat, 19 Apr 2014 19:02:14 +0000 Subject: [issue21311] Fix compiler detection when brew's ccache is installed on Mac OS X In-Reply-To: <1397913662.53.0.885648478854.issue21311@psf.upfronthosting.co.za> Message-ID: <1397934134.28.0.587726614675.issue21311@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- assignee: -> ned.deily nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 21:07:33 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 19 Apr 2014 19:07:33 +0000 Subject: [issue7221] DispatcherWithSendTests_UsePoll with test_asyncore does nothing In-Reply-To: <1256668022.66.0.873968126347.issue7221@psf.upfronthosting.co.za> Message-ID: <3gB3Zr5PH9z7Ljf@mail.python.org> Roundup Robot added the comment: New changeset cbe7b5a5a110 by Antoine Pitrou in branch 'default': Issue #7221: remove redundant tests in test_asyncore. Patch by Jessica McKellar. http://hg.python.org/cpython/rev/cbe7b5a5a110 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 21:08:11 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 19 Apr 2014 19:08:11 +0000 Subject: [issue7221] DispatcherWithSendTests_UsePoll with test_asyncore does nothing In-Reply-To: <1256668022.66.0.873968126347.issue7221@psf.upfronthosting.co.za> Message-ID: <1397934491.43.0.961769665054.issue7221@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Now committed. Thanks for the patch! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.5 -Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 22:27:46 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 19 Apr 2014 20:27:46 +0000 Subject: [issue21311] Fix compiler detection when brew's ccache is installed on Mac OS X In-Reply-To: <1397913662.53.0.885648478854.issue21311@psf.upfronthosting.co.za> Message-ID: <3gB5MP4wB0z7LjN@mail.python.org> Roundup Robot added the comment: New changeset e3217efa6edd by Ned Deily in branch '2.7': Issue #21311: Avoid exception in _osx_support with non-standard compiler http://hg.python.org/cpython/rev/e3217efa6edd New changeset 3d1578c705c9 by Ned Deily in branch '3.4': Issue #21311: Avoid exception in _osx_support with non-standard compiler http://hg.python.org/cpython/rev/3d1578c705c9 New changeset 2a4401109672 by Ned Deily in branch 'default': Issue #21311: merge with 3.4 http://hg.python.org/cpython/rev/2a4401109672 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 22:35:17 2014 From: report at bugs.python.org (Ned Deily) Date: Sat, 19 Apr 2014 20:35:17 +0000 Subject: [issue21311] Fix compiler detection when brew's ccache is installed on Mac OS X In-Reply-To: <1397913662.53.0.885648478854.issue21311@psf.upfronthosting.co.za> Message-ID: <1397939717.68.0.0620661344814.issue21311@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks for the report and the patches. I am not sure exactly what problem using ccache is causing but it is clear that, if for whatever reason the call to _read_output fails and returns None, the 'llvm-gcc' test will fail so that test should be fixed as suggested in your first patch which I've applied for release in 2.7.7, 3.4.1, and 3.5.0. ---------- resolution: -> fixed stage: -> resolved status: open -> closed versions: -Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 23:16:30 2014 From: report at bugs.python.org (Ned Deily) Date: Sat, 19 Apr 2014 21:16:30 +0000 Subject: [issue21121] -Werror=declaration-after-statement is added even for extension modules through setup.py In-Reply-To: <1396348933.92.0.0275278232722.issue21121@psf.upfronthosting.co.za> Message-ID: <1397942190.45.0.455638436765.issue21121@psf.upfronthosting.co.za> Ned Deily added the comment: Stefan, the patch LGTM although I sure wish we were removing some CFLAGS-related configuration variables rather than adding another. But I don't have a better suggestion short of a comprehensive cleanup of all of them. ---------- stage: -> commit review versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 23:25:35 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 19 Apr 2014 21:25:35 +0000 Subject: [issue4744] asynchat documentation needs to be more precise In-Reply-To: <1230168171.56.0.381937953807.issue4744@psf.upfronthosting.co.za> Message-ID: <1397942735.77.0.480694894075.issue4744@psf.upfronthosting.co.za> R. David Murray added the comment: The change covered by the patch (which patch rejected as garbage, by the way, I have no idea why) has already been applied by Serhiy Storchaka, apparently as a blanked change of 'empty string' to 'empty bytes object'. There are several other places in the asynchat doc page that mention string. I suspect that none of them is correct, but I haven't read through the page to be sure. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 23:26:39 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 19 Apr 2014 21:26:39 +0000 Subject: [issue4744] asynchat documentation needs to be more precise In-Reply-To: <1230168171.56.0.381937953807.issue4744@psf.upfronthosting.co.za> Message-ID: <1397942799.24.0.717518936368.issue4744@psf.upfronthosting.co.za> R. David Murray added the comment: The change covered by the patch (which patch rejected as garbage, by the way, I have no idea why) has already been applied by Serhiy Storchaka, apparently as a blanket change of 'empty string' to 'empty bytes object'. There are several other places in the asynchat doc page that mention string. I suspect that none of them is correct, but I haven't read through the page to be sure. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 23:26:49 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 19 Apr 2014 21:26:49 +0000 Subject: [issue4744] asynchat documentation needs to be more precise In-Reply-To: <1230168171.56.0.381937953807.issue4744@psf.upfronthosting.co.za> Message-ID: <1397942809.02.0.838118133619.issue4744@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- Removed message: http://bugs.python.org/msg216880 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 19 23:48:30 2014 From: report at bugs.python.org (paul j3) Date: Sat, 19 Apr 2014 21:48:30 +0000 Subject: [issue13966] Add disable_interspersed_args() to argparse.ArgumentParser In-Reply-To: <1328687368.18.0.265955669963.issue13966@psf.upfronthosting.co.za> Message-ID: <1397944110.58.0.663233482089.issue13966@psf.upfronthosting.co.za> paul j3 added the comment: http://bugs.python.org/issue14191 implements the other side of optparse behavior - allowing a complete intermixing of optionals and positionals. It does that with a new 'ArgumentParser.parse_intermixed_args()' method. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 20 00:17:18 2014 From: report at bugs.python.org (Eric Snow) Date: Sat, 19 Apr 2014 22:17:18 +0000 Subject: [issue21313] Py_GetVersion() is broken when using mqueue and a long patch name Message-ID: <1397945838.86.0.227153547567.issue21313@psf.upfronthosting.co.za> New submission from Eric Snow: Py_GetVersion() (in Python/getversion.c) builds the version string returned by sys.version: PyOS_snprintf(version, sizeof(version), "%.80s (%.80s) %.80s", PY_VERSION, Py_GetBuildInfo(), Py_GetCompiler()); In turn, Py_GetBuildInfo() (in Modules/getbuildinfo.c) returns the "build" portion of Python's version string. When available, the tag returned by "hg id -t" constitutes part of that build string. The problem is that when using mqueue the result of "hg id -t" can be pretty long. For example: issue21226-fix-PyImport_ExecCodeModuleObject.diff qbase qtip tip That's 74 characters for just part of a build string that may be well over 100 characters. However, Py_GetVersion() truncates it to 80 characters. The consequence is that this value of sys.version causes platform._sys_version() to fail since the version string does not match the expected pattern. So either Py_GetVersion() should relax (-1) or Py_GetBuildInfo() should restrict the length of the resulting build string (+1). Would it work to truncate just the hgid part so that the whole string returned by Py_GetBuildInfo() is no more than length 80? E.g. - PyOS_snprintf(buildinfo, sizeof(buildinfo), - "%s%s%s, %.20s, %.9s", hgid, sep, revision, DATE, TIME); + PyOS_snprintf(buildinfo, 80, + "%.43s%.1s%.13s, %.20s, %.9s", hgid, sep, revision, DATE, TIME); ---------- components: Interpreter Core messages: 216883 nosy: eric.snow priority: normal severity: normal stage: patch review status: open title: Py_GetVersion() is broken when using mqueue and a long patch name type: behavior versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 20 00:27:12 2014 From: report at bugs.python.org (John Szakmeister) Date: Sat, 19 Apr 2014 22:27:12 +0000 Subject: [issue21311] Fix compiler detection when brew's ccache is installed on Mac OS X In-Reply-To: <1397913662.53.0.885648478854.issue21311@psf.upfronthosting.co.za> Message-ID: <1397946432.79.0.60198163778.issue21311@psf.upfronthosting.co.za> John Szakmeister added the comment: Thank you Ned! The issue is that you can create symlinks to ccache to and put them on your path. Distros do this for you now, but most create symlinks for a bunch of compilers... including ones that may not be installed. So the presence of the name ('gcc', for instance) doesn't mean that the compiler is actually installed. It could be a symlink to the ccache binary and running it could fail. I hope that makes a little more sense. Thanks again for applying the patch! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 20 02:07:32 2014 From: report at bugs.python.org (Jessica McKellar) Date: Sun, 20 Apr 2014 00:07:32 +0000 Subject: [issue10291] Clean-up turtledemo in-package documentation In-Reply-To: <1288663412.18.0.821423720263.issue10291@psf.upfronthosting.co.za> Message-ID: <1397952452.47.0.758254821841.issue10291@psf.upfronthosting.co.za> Jessica McKellar added the comment: Thanks for the bug report and patch, belopolsky! The original patch no longer applies cleanly, so attached is a regenerated version. * The new patch passes `make patchcheck`. * The full test suite passes with this patch. * I manually tested that before the patch, `./python.exe Lib/turtledemo/__main__.py` would start the demo window behind the Terminal on OSX, and after the patch it starts in front as desired. * I manually checked the 3 help menu drop-down options in the demo, and they have the expected content. There is a lot of out of date content in the turtle docs, and I think we should consider that work separate from this ticket and do a full audit of what needs updating in a new ticket. => commit review ---------- keywords: +needs review nosy: +jesstess stage: needs patch -> commit review Added file: http://bugs.python.org/file34979/issue10291_2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 20 02:13:19 2014 From: report at bugs.python.org (Eric Snow) Date: Sun, 20 Apr 2014 00:13:19 +0000 Subject: [issue21226] PyImport_ExecCodeModuleObject not setting module attributes In-Reply-To: <1397509467.13.0.547431443442.issue21226@psf.upfronthosting.co.za> Message-ID: <1397952799.58.0.294022430485.issue21226@psf.upfronthosting.co.za> Eric Snow added the comment: Thanks, Benjamin. Here's an updated patch that passes all tests. It should be good to go. And yet again our zipimport implementation was a pain point. :( ---------- Added file: http://bugs.python.org/file34980/fix-PyImport_ExecCodeModuleObject.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 20 02:39:51 2014 From: report at bugs.python.org (akira) Date: Sun, 20 Apr 2014 00:39:51 +0000 Subject: [issue21302] time.sleep (floatsleep()) should use clock_nanosleep() on Linux In-Reply-To: <1397851923.06.0.0550198760464.issue21302@psf.upfronthosting.co.za> Message-ID: <1397954391.77.0.547458892685.issue21302@psf.upfronthosting.co.za> Changes by akira <4kir4.1i at gmail.com>: ---------- nosy: +akira _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 20 03:42:02 2014 From: report at bugs.python.org (Jessica McKellar) Date: Sun, 20 Apr 2014 01:42:02 +0000 Subject: [issue8387] use universal newline mode in csv module examples In-Reply-To: <1271193086.18.0.201846291594.issue8387@psf.upfronthosting.co.za> Message-ID: <1397958122.62.0.20409058935.issue8387@psf.upfronthosting.co.za> Jessica McKellar added the comment: I ran some experiments to see what the state of the world is. I generated a test.csv by exporting a CSV file from Numbers on OSX. This generated a file with Windows-style \r\n-terminated lines. The attached test_csv.py tries to open this CSV file in binary and universal newlines modes. Here's what happens on various platforms Python 3: * Linux: both binary and universal work * OSX: binary errors out, universal works * Windows: binary errors out, universal works In both cases, the error was: $ python3 test_csv.py Traceback (most recent call last): File "test_csv.py", line 5, in for row in spamreader: _csv.Error: iterator should return strings, not bytes (did you open the file in text mode?) Python 2: * Linux: both binary and universal work * OSX: both binary and universal * Windows: wasn't readily able to test If I manually create a CSV file using TextEdit in plaintext mode on OSX, that produces a file with Mac-style \r-terminated lines. test_csv.py has the same results on this file on OSX (errors out in binary mode in Python 3). ---------- nosy: +jesstess Added file: http://bugs.python.org/file34981/test_csv.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 20 03:42:14 2014 From: report at bugs.python.org (Jessica McKellar) Date: Sun, 20 Apr 2014 01:42:14 +0000 Subject: [issue8387] use universal newline mode in csv module examples In-Reply-To: <1271193086.18.0.201846291594.issue8387@psf.upfronthosting.co.za> Message-ID: <1397958134.61.0.332856511454.issue8387@psf.upfronthosting.co.za> Changes by Jessica McKellar : Added file: http://bugs.python.org/file34982/test.csv _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 20 04:07:22 2014 From: report at bugs.python.org (Jessica McKellar) Date: Sun, 20 Apr 2014 02:07:22 +0000 Subject: [issue8387] use universal newline mode in csv module examples In-Reply-To: <1271193086.18.0.201846291594.issue8387@psf.upfronthosting.co.za> Message-ID: <1397959642.16.0.855965731118.issue8387@psf.upfronthosting.co.za> Jessica McKellar added the comment: All of the examples from https://docs.python.org/3/library/csv.html run without issue on OSX, though. In summary, the Python 2 examples error out on OSX and switching them to use 'U' instead of 'b' would fix this. I don't think any action needs to be taken for Python 3. My one remaining question is about binary files on Windows. The Python 2 csv docs say "If csvfile is a file object, it must be opened with the ?b? flag on platforms where that makes a difference." I don't readily have a Windows machine to play with this -- do "binary" CSV files exist, or can we eliminate the 'b' language entirely and just talk about 'U'? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 20 04:15:34 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 20 Apr 2014 02:15:34 +0000 Subject: [issue10291] Clean-up turtledemo in-package documentation In-Reply-To: <1288663412.18.0.821423720263.issue10291@psf.upfronthosting.co.za> Message-ID: <3gBF4h5GPBz7LjT@mail.python.org> Roundup Robot added the comment: New changeset 004fe3449193 by Ned Deily in branch 'default': Issue #10291: Cleanup turtledemo to use docstrings for help. http://hg.python.org/cpython/rev/004fe3449193 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 20 04:15:34 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 20 Apr 2014 02:15:34 +0000 Subject: [issue11571] Turtle window pops under the terminal on OSX In-Reply-To: <1300287451.35.0.164099198094.issue11571@psf.upfronthosting.co.za> Message-ID: <3gBF4j3Y8rz7LjT@mail.python.org> Roundup Robot added the comment: New changeset 1f3946b22e64 by Ned Deily in branch '3.4': Issue #11571: Ensure that the turtle window becomes the topmost window http://hg.python.org/cpython/rev/1f3946b22e64 New changeset 01228d7b5e01 by Ned Deily in branch 'default': Issue #11571: merge with 3.4 http://hg.python.org/cpython/rev/01228d7b5e01 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 20 04:19:43 2014 From: report at bugs.python.org (Ned Deily) Date: Sun, 20 Apr 2014 02:19:43 +0000 Subject: [issue11571] Turtle window pops under the terminal on OSX In-Reply-To: <1300287451.35.0.164099198094.issue11571@psf.upfronthosting.co.za> Message-ID: <1397960383.44.0.220574176615.issue11571@psf.upfronthosting.co.za> Ned Deily added the comment: The fix for turtle has been applied for release in 3.4.1 and 3.5.0. ---------- resolution: wont fix -> fixed stage: commit review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 20 04:19:55 2014 From: report at bugs.python.org (Ned Deily) Date: Sun, 20 Apr 2014 02:19:55 +0000 Subject: [issue11571] Turtle window pops under the terminal on OSX In-Reply-To: <1300287451.35.0.164099198094.issue11571@psf.upfronthosting.co.za> Message-ID: <1397960395.03.0.320736074723.issue11571@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- versions: +Python 3.4, Python 3.5 -Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 20 04:23:14 2014 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 20 Apr 2014 02:23:14 +0000 Subject: [issue8387] use universal newline mode in csv module examples In-Reply-To: <1271193086.18.0.201846291594.issue8387@psf.upfronthosting.co.za> Message-ID: <1397960594.51.0.877164418681.issue8387@psf.upfronthosting.co.za> Mark Lawrence added the comment: I think that it's complete nonsense to talk about binary csv files on Windows. They are just plain text files that can be manipulated with any old editor or a spreadsheet. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 20 04:27:55 2014 From: report at bugs.python.org (Ned Deily) Date: Sun, 20 Apr 2014 02:27:55 +0000 Subject: [issue10291] Clean-up turtledemo in-package documentation In-Reply-To: <1288663412.18.0.821423720263.issue10291@psf.upfronthosting.co.za> Message-ID: <1397960875.51.0.0476515237438.issue10291@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks for the refresh, Jessica. I decided to separate out the turtle window raise for OS X and apply that for 3.4.1 and 3.5.0 in Issue11571. The remainder of the patch to use the docstrings, plus removal of the two other obsolete text files, is spplied here for 3.5.0. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 20 04:27:56 2014 From: report at bugs.python.org (R. David Murray) Date: Sun, 20 Apr 2014 02:27:56 +0000 Subject: [issue8387] use universal newline mode in csv module examples In-Reply-To: <1271193086.18.0.201846291594.issue8387@psf.upfronthosting.co.za> Message-ID: <1397960876.64.0.837132738426.issue8387@psf.upfronthosting.co.za> R. David Murray added the comment: The magic of newline='' in python3 is that it *preserves* the line end characters, which is the same thing binary mode does on windows. The place that matters, as I remember it, is when there is a newline embedded inside a quoted string. I don't remember *why* that matters, though :(. But it had something to do with how the csv module processes the data internally. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 20 05:10:20 2014 From: report at bugs.python.org (Luiji Maryo) Date: Sun, 20 Apr 2014 03:10:20 +0000 Subject: [issue21296] smtplib Sends Commands in Lower-Case In-Reply-To: <1397818996.26.0.83241644449.issue21296@psf.upfronthosting.co.za> Message-ID: <1397963420.37.0.770668035299.issue21296@psf.upfronthosting.co.za> Luiji Maryo added the comment: Apologies, I was tired when I looked into this. It turns out that SMTP is explicitly case-insensitive with command names. I still think it'd be nice to use upper-case commands for consistency with the FROM: and TO: lines, though, or to put the FROM: and TO: lines in lower-case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 20 06:03:52 2014 From: report at bugs.python.org (R. David Murray) Date: Sun, 20 Apr 2014 04:03:52 +0000 Subject: [issue21296] smtplib Sends Commands in Lower-Case In-Reply-To: <1397818996.26.0.83241644449.issue21296@psf.upfronthosting.co.za> Message-ID: <1397966632.38.0.660650353872.issue21296@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- components: +email nosy: +barry, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 20 06:10:58 2014 From: report at bugs.python.org (R. David Murray) Date: Sun, 20 Apr 2014 04:10:58 +0000 Subject: [issue837046] pyport.h redeclares gethostname() if SOLARIS is defined Message-ID: <1397967058.97.0.0770510492399.issue837046@psf.upfronthosting.co.za> R. David Murray added the comment: Can you confirm that this is really still a problem, despite the Solaris cleanup in issue 1759169? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 20 06:48:40 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 20 Apr 2014 04:48:40 +0000 Subject: [issue12220] minidom xmlns not handling spaces in xmlns attribute value field In-Reply-To: <1306789573.92.0.875996944294.issue12220@psf.upfronthosting.co.za> Message-ID: <3gBJTN0XXbz7LjV@mail.python.org> Roundup Robot added the comment: New changeset 13c1c5e3d2ee by R David Murray in branch '3.4': #12220: improve minidom error when URI contains spaces. http://hg.python.org/cpython/rev/13c1c5e3d2ee New changeset 3e67d923a0df by R David Murray in branch 'default': Merge: #12220: improve minidom error when URI contains spaces. http://hg.python.org/cpython/rev/3e67d923a0df ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 20 06:49:39 2014 From: report at bugs.python.org (R. David Murray) Date: Sun, 20 Apr 2014 04:49:39 +0000 Subject: [issue12220] minidom xmlns not handling spaces in xmlns attribute value field In-Reply-To: <1306789573.92.0.875996944294.issue12220@psf.upfronthosting.co.za> Message-ID: <1397969379.14.0.398286571797.issue12220@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, amathew and Marek. ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 20 07:57:42 2014 From: report at bugs.python.org (R. David Murray) Date: Sun, 20 Apr 2014 05:57:42 +0000 Subject: [issue21221] Minor struct_time documentation bug In-Reply-To: <1397500160.88.0.743491348049.issue21221@psf.upfronthosting.co.za> Message-ID: <1397973462.81.0.111992077793.issue21221@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 20 12:07:19 2014 From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=) Date: Sun, 20 Apr 2014 10:07:19 +0000 Subject: [issue21314] Bizarre help Message-ID: <1397988439.5.0.703056699862.issue21314@psf.upfronthosting.co.za> New submission from Vedran ?a?i?: Please look at the output of help(object.__ge__). 1. What's that $ in front of self? lt and gt don't have it. 2. What's that / as a third argument? Many wrapper functions have it (for example, see help(tuple.__len__). 3. What's that -- as the first line of doc? Similar methods don't have it. ---------- assignee: docs at python components: Documentation messages: 216899 nosy: Vedran.?a?i?, docs at python priority: normal severity: normal status: open title: Bizarre help versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 20 12:29:12 2014 From: report at bugs.python.org (INADA Naoki) Date: Sun, 20 Apr 2014 10:29:12 +0000 Subject: [issue10614] ZipFile: add a filename_encoding argument In-Reply-To: <1291362121.18.0.976785403189.issue10614@psf.upfronthosting.co.za> Message-ID: <1397989752.1.0.870714460991.issue10614@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- nosy: +naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 20 13:29:20 2014 From: report at bugs.python.org (Georg Brandl) Date: Sun, 20 Apr 2014 11:29:20 +0000 Subject: [issue21314] Bizarre help In-Reply-To: <1397988439.5.0.703056699862.issue21314@psf.upfronthosting.co.za> Message-ID: <1397993360.75.0.19107690859.issue21314@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- assignee: docs at python -> larry nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 20 14:47:07 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Sun, 20 Apr 2014 12:47:07 +0000 Subject: [issue21314] Bizarre help In-Reply-To: <1397988439.5.0.703056699862.issue21314@psf.upfronthosting.co.za> Message-ID: <1397998027.13.0.470690397567.issue21314@psf.upfronthosting.co.za> Josh Rosenberg added the comment: I don't know about the other bits, but that trailing '/' is how Argument Clinic (which makes full featured inspection available to built-in functions) notes that the parameters are positional only, and cannot be passed by keyword. See PEP436. ---------- nosy: +josh.rosenberg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 20 14:49:30 2014 From: report at bugs.python.org (Zachary Ware) Date: Sun, 20 Apr 2014 12:49:30 +0000 Subject: [issue21314] Bizarre help In-Reply-To: <1397988439.5.0.703056699862.issue21314@psf.upfronthosting.co.za> Message-ID: <1397998170.5.0.56329850665.issue21314@psf.upfronthosting.co.za> Zachary Ware added the comment: 1) This was due to a typo. The release of Python 3.4 saw the introduction of new introspection information on many C-implemented functions thanks to Argument Clinic (see PEP 436, I think it is). As part of that (still ongoing) transition, the default doctrings for type slots like __ge__ were given Argument Clinic-style signatures, and __ge__ had a typo. I fixed that typo on Friday (actually prompted by your previous issue about len's bad signature). 2) That marker now shows that all proceeding arguments are positional-only. We should probably make sure that is well documented somewhere, possibly in the tutorial. 3) This was also due to the typo I fixed. ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 20 15:10:01 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 20 Apr 2014 13:10:01 +0000 Subject: [issue21209] q.put(some_tuple) fails when PYTHONASYNCIODEBUG=1 In-Reply-To: <1397351442.01.0.248805040826.issue21209@psf.upfronthosting.co.za> Message-ID: <1397999401.56.0.538404758179.issue21209@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: The added comment contains "This workaround should be removed in 3.5.0.". Since default branch now contains Python 3.5, maybe it is time to remove workaround on default branch? ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 20 16:43:31 2014 From: report at bugs.python.org (Tim Golden) Date: Sun, 20 Apr 2014 14:43:31 +0000 Subject: [issue9291] mimetypes initialization fails on Windows because of non-Latin characters in registry In-Reply-To: <1279454095.41.0.733053669611.issue9291@psf.upfronthosting.co.za> Message-ID: <1398005011.92.0.0951479273511.issue9291@psf.upfronthosting.co.za> Changes by Tim Golden : Removed file: http://bugs.python.org/file34925/issue9291.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 20 16:47:11 2014 From: report at bugs.python.org (Tim Golden) Date: Sun, 20 Apr 2014 14:47:11 +0000 Subject: [issue9291] mimetypes initialization fails on Windows because of non-Latin characters in registry In-Reply-To: <1279454095.41.0.733053669611.issue9291@psf.upfronthosting.co.za> Message-ID: <1398005231.6.0.590453992014.issue9291@psf.upfronthosting.co.za> Tim Golden added the comment: Another version of the patch: this one, in addition to removing the unnecessary encodes, also does the check for extensions before attempting to open the registry key, and narrows down the try-catch block to just the attempt to read the "Content Type" value. This does mean that if any process is unable to read HKCR or its subkeys the mimetypes.init will fail. Frankly, I can't see how that could happen, but if anyone feels strongly enough I can add extra guards so it fails silently. ---------- Added file: http://bugs.python.org/file34983/issue9291.8.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 20 17:08:57 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 20 Apr 2014 15:08:57 +0000 Subject: [issue8387] use universal newline mode in csv module examples In-Reply-To: <1271193086.18.0.201846291594.issue8387@psf.upfronthosting.co.za> Message-ID: <1398006537.55.0.886619097659.issue8387@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Note that 'U' is a no-op under Python 3, it's just there for compatibility reasons; i.e. 'rU' is the same as 'r'. Also, from a quick glance, the CSV parser in _csv.c looks newline-agnostic. @sfinnie: can you explain which problems you encountered running the examples? Please also post the resulting exception tracebacks, if any. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 20 17:15:28 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 20 Apr 2014 15:15:28 +0000 Subject: [issue21296] smtplib Sends Commands in Lower-Case In-Reply-To: <1397818996.26.0.83241644449.issue21296@psf.upfronthosting.co.za> Message-ID: <1398006928.17.0.679146576479.issue21296@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- priority: normal -> low type: behavior -> enhancement versions: -Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 20 17:34:21 2014 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 20 Apr 2014 15:34:21 +0000 Subject: [issue21209] q.put(some_tuple) fails when PYTHONASYNCIODEBUG=1 In-Reply-To: <1397351442.01.0.248805040826.issue21209@psf.upfronthosting.co.za> Message-ID: <1398008061.06.0.160755513851.issue21209@psf.upfronthosting.co.za> Guido van Rossum added the comment: IMO the comment is too aggressive. I want the workaround to stay in the codebase so CPython asyncio ans Tulip asyncio (== upstream) don't diverge. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 20 17:45:01 2014 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 20 Apr 2014 15:45:01 +0000 Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za> Message-ID: <1398008701.89.0.526554124831.issue18967@psf.upfronthosting.co.za> Ezio Melotti added the comment: Have you considered how this is going to change if/when PEP 462 will be implemented? AFAIU PEP 462 suggests that commits happen directly from the bug tracker (or something equivalent), so we will likely start to add the NEWS entry there as well. Assuming this will happen and it's not too far away in the future, it might be wiser to wait or move toward a system that will make the switch to PEP 462 easier. FWIW I still think that the current situation is fine as is. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 20 17:47:57 2014 From: report at bugs.python.org (Daniel Andersson) Date: Sun, 20 Apr 2014 15:47:57 +0000 Subject: [issue21297] csv.skipinitialspace only skips spaces, not "whitespace" in general In-Reply-To: <1397821941.61.0.706896478348.issue21297@psf.upfronthosting.co.za> Message-ID: <1398008877.48.0.789379045576.issue21297@psf.upfronthosting.co.za> Daniel Andersson added the comment: No, multiple spaces are ignored as advertised (according to actual tests; not just reading the code), but only spaces (U+0020) and not e.g. tabs (U+0009), which are also included in the term "whitespace", along with several other characters. In light of your followup question, the internal comment at `Modules/_csv.c`, line 639: /* ignore space at start of field */ could perhaps be clarified to say "spaces" instead of "space", but the code context makes it quite clear, and it does not face the users anyway. The main point of this issue is meant to be the wording in the module docstring and the official docs regarding "whitespace" contra "space". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 20 17:58:18 2014 From: report at bugs.python.org (Merlijn van Deen) Date: Sun, 20 Apr 2014 15:58:18 +0000 Subject: [issue21315] email._header_value_parser does not recognise in-line encoding changes Message-ID: <1398009498.59.0.139606640186.issue21315@psf.upfronthosting.co.za> New submission from Merlijn van Deen: Bugzilla sends e-mail in a format where =?UTF-8 is not preceded by whitespace. This makes email.headerregistry.UnstructuredHeader (and email._header_value_parser on the background) not recognise the structure. >>> import email.headerregistry, pprint >>> x = {}; email.headerregistry.UnstructuredHeader.parse('[Bug 64155]\tNew:=?UTF-8?Q?=20non=2Dascii=20bug=20t=C3=A9st?=;\trussian text:=?UTF-8?Q?=20=D0=90=D0=91=D0=92=D0=93=D2=90=D0=94', x); pprint.pprint(x) {'decoded': '[Bug 64155]\tNew:=?UTF-8?Q?=20non=2Dascii=20bug=20t=C3=A9st?=;\t' 'russian text:=?UTF-8?Q?=20=D0=90=D0=91=D0=92=D0=93=D2=90=D0=94', 'parse_tree': UnstructuredTokenList([ValueTerminal('[Bug'), WhiteSpaceTerminal(' '), ValueTerminal('64155]'), WhiteSpaceTerminal('\t'), ValueTerminal('New:=?UTF-8?Q?=20non=2Dascii=20bug=20t=C3=A9st?=;'), WhiteSpaceTerminal('\t'), ValueTerminal('russian'), WhiteSpaceTerminal(' '), ValueTerminal('text:=?UTF-8?Q?=20=D0=90=D0=91=D0=92=D0=93=D2=90=D0=94')])} versus >>> x = {}; email.headerregistry.UnstructuredHeader.parse('[Bug 64155]\tNew: =?UTF-8?Q?=20non=2Dascii=20bug=20t=C3=A9st?=;\trussian text: =?UTF-8?Q?=20=D0=90=D0=91=D0=92=D0=93=D2=90=D0=94', x); pprint.pprint(x) {'decoded': '[Bug 64155]\tNew: non-ascii bug t?st;\trussian text: ??????', 'parse_tree': UnstructuredTokenList([ValueTerminal('[Bug'), WhiteSpaceTerminal(' '), ValueTerminal('64155]'), WhiteSpaceTerminal('\t'), ValueTerminal('New:'), WhiteSpaceTerminal(' '), EncodedWord([WhiteSpaceTerminal(' '), ValueTerminal('non-ascii'), WhiteSpaceTerminal(' '), ValueTerminal('bug'), WhiteSpaceTerminal(' '), ValueTerminal('t?st')]), ValueTerminal(';'), WhiteSpaceTerminal('\t'), ValueTerminal('russian'), WhiteSpaceTerminal(' '), ValueTerminal('text:'), WhiteSpaceTerminal(' '), EncodedWord([WhiteSpaceTerminal(' '), ValueTerminal('??????')])])} I have attached the raw e-mail as attachment. Judging by the code, this is supposed to work (while raising a Defect -- "missing whitespace before encoded word"), but the code splits by whitespace: tok, *remainder = _wsp_splitter(value, 1) which swallows the encoded section in one go. In a second attachment, I added a patch which 1) adds a test case for this and 2) implements a solution, but the solution is unfortunately not in the style of the rest of the module. In the meanwhile, I've chosen a monkey-patching approach to work around the issue: import email._header_value_parser, email.headerregistry def get_unstructured(value): value = value.replace("=?UTF-8?Q?=20", " =?UTF-8?Q?") return email._header_value_parser.get_unstructured(value) email.headerregistry.UnstructuredHeader.value_parser = staticmethod(get_unstructured) ---------- components: email files: 000359.raw messages: 216908 nosy: barry, r.david.murray, valhallasw priority: normal severity: normal status: open title: email._header_value_parser does not recognise in-line encoding changes versions: Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file34984/000359.raw _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 20 17:58:51 2014 From: report at bugs.python.org (Merlijn van Deen) Date: Sun, 20 Apr 2014 15:58:51 +0000 Subject: [issue21315] email._header_value_parser does not recognise in-line encoding changes In-Reply-To: <1398009498.59.0.139606640186.issue21315@psf.upfronthosting.co.za> Message-ID: <1398009531.42.0.610349286286.issue21315@psf.upfronthosting.co.za> Changes by Merlijn van Deen : ---------- keywords: +patch type: -> behavior Added file: http://bugs.python.org/file34985/unstructured_ew_without_whitespace.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 20 18:22:59 2014 From: report at bugs.python.org (Jessica McKellar) Date: Sun, 20 Apr 2014 16:22:59 +0000 Subject: [issue8387] use universal newline mode in csv module examples In-Reply-To: <1271193086.18.0.201846291594.issue8387@psf.upfronthosting.co.za> Message-ID: <1398010979.29.0.378066370088.issue8387@psf.upfronthosting.co.za> Jessica McKellar added the comment: I realized that I typo'd 2 instead of 3 in http://bugs.python.org/issue8387#msg216888 which makes that message confusing. Here's a restatement of my findings: * All of the Python 3 csv examples work in Python 3 on all platforms. * The Python 2 binary-mode csv examples work in Python 2.7 on all platforms. * The Python 2 binary-mode csv examples error out on Windows and OSX when run under Python 3. We could do nothing to address this, or, if we determine that there's no negative impact to removing the 'b', update the examples to accommodate readers who are running Python 2 examples using Python 3 for whatever reason. Which does bring me to the same question as @pitrou, which is what data and code cause an error for @sfinnie on Python 2. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 20 18:45:09 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 20 Apr 2014 16:45:09 +0000 Subject: [issue15002] urllib2 does not download 4 MB file completely using ftp In-Reply-To: <1338840881.84.0.164546182047.issue15002@psf.upfronthosting.co.za> Message-ID: <3gBcN438yPz7Lk2@mail.python.org> Roundup Robot added the comment: New changeset bb71b71322a3 by Senthil Kumaran in branch '3.4': urllib.response object to use _TemporaryFileWrapper (and _TemporaryFileCloser) http://hg.python.org/cpython/rev/bb71b71322a3 New changeset 72fe23edfec6 by Senthil Kumaran in branch '3.4': NEWS entry for #15002 http://hg.python.org/cpython/rev/72fe23edfec6 New changeset 8c8315bac6a8 by Senthil Kumaran in branch 'default': merge 3.4 http://hg.python.org/cpython/rev/8c8315bac6a8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 20 18:47:02 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Sun, 20 Apr 2014 16:47:02 +0000 Subject: [issue15002] urllib2 does not download 4 MB file completely using ftp In-Reply-To: <1338840881.84.0.164546182047.issue15002@psf.upfronthosting.co.za> Message-ID: <1398012422.59.0.168577241233.issue15002@psf.upfronthosting.co.za> Senthil Kumaran added the comment: This is fixed in 3.4 and 3.5. I will backport to 2.7 ( I think, it is worth it). ---------- resolution: -> fixed stage: patch review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 20 20:23:18 2014 From: report at bugs.python.org (Aapo Rantalainen) Date: Sun, 20 Apr 2014 18:23:18 +0000 Subject: [issue20760] test_compileall test getting failed on 3.4 RC In-Reply-To: <1393247194.23.0.0410918224117.issue20760@psf.upfronthosting.co.za> Message-ID: <1398018198.14.0.93094378308.issue20760@psf.upfronthosting.co.za> Aapo Rantalainen added the comment: I got exactly same trace with Python-3.4.0. == CPython 3.4.0 (default, Apr 19 2014, 16:37:49) [GCC 4.2.1] == Linux-2.6.28.10-power52-armv7l-with-debian-testing-unstable little-endian Btw: My test-directory is writable. (This seems to be duplicate, but is explicitly mentioning non-writable directory: http://bugs.python.org/issue21264 ) ---------- nosy: +AapoRantalainen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 20 20:36:52 2014 From: report at bugs.python.org (Aapo Rantalainen) Date: Sun, 20 Apr 2014 18:36:52 +0000 Subject: [issue21316] mark test_devpoll to be meaningfull only for Solaris Message-ID: <1398019012.76.0.381361357153.issue21316@psf.upfronthosting.co.za> New submission from Aapo Rantalainen: [ 96/389/2] test_devpoll Actual happened: test_devpoll skipped -- select.devpoll not defined Excepted: test works only on Solaris Took me a while until I read documentation: select.devpoll() -> (Only supported on Solaris and derivatives.) Even test itself, test_devpoll.py, doesn't mention it is only for Solaris. ---------- components: Tests messages: 216913 nosy: AapoRantalainen priority: normal severity: normal status: open title: mark test_devpoll to be meaningfull only for Solaris type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 20 20:47:54 2014 From: report at bugs.python.org (Lita Cho) Date: Sun, 20 Apr 2014 18:47:54 +0000 Subject: [issue20585] urllib2 unrelease KQUEUE on Mac OSX 10.9+ In-Reply-To: <1392057963.63.0.832878598113.issue20585@psf.upfronthosting.co.za> Message-ID: <1398019674.55.0.119253435439.issue20585@psf.upfronthosting.co.za> Lita Cho added the comment: Going to try working on this. ---------- nosy: +Lita.Cho _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 20 20:57:00 2014 From: report at bugs.python.org (Giampaolo Rodola') Date: Sun, 20 Apr 2014 18:57:00 +0000 Subject: [issue17552] socket.sendfile() In-Reply-To: <1364326073.47.0.699222209849.issue17552@psf.upfronthosting.co.za> Message-ID: <1398020220.84.0.838037889682.issue17552@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: New patch in attachment. Changes: - docs - replaced select() / poll() with the new selectors module - file position is always updated both on return and on error; this means file.tell() is the designated way to know how many bytes were sent - replaced sendall() with send() so that we can count the number of bytes transmitted (related and rejected proposal: https://mail.python.org/pipermail/python-ideas/2014-April/027689.html) - send() now uses memoryview() for better performances to re-transmit data which was not sent by the first send() call - pre-emptively raise exception if file is not opened in binary mode - tests for ssl module I've tried to work on Windows TransmitFile support but I got stuck as I'm not sure how to convert a file object into a HANDLE in C. I suppose Windows support can also be added later as a separate ticket and in the meantime I'd like to push this forward. Open questions: - Is the current return value desirable (do we really care if os.sendfile() was used internally?)? Should the returned tuple also include the number transmitted bytes? - default blocksize: Charles-Fran?ois was suggesting to remove the blocksize argument; FWIW I've made some quick benchmarks by using "time" cmdline utility with different blocksizes and I didn't notice substantial difference. I still think a blocksize parameter is necessary in case we fallback on using send() and also for consistency with ftplib's storbinary() method which will be involved later (issue 13564). ---------- Added file: http://bugs.python.org/file34986/socket-sendfile3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 20 20:57:38 2014 From: report at bugs.python.org (Giampaolo Rodola') Date: Sun, 20 Apr 2014 18:57:38 +0000 Subject: [issue17552] socket.sendfile() In-Reply-To: <1364326073.47.0.699222209849.issue17552@psf.upfronthosting.co.za> Message-ID: <1398020258.14.0.794754620173.issue17552@psf.upfronthosting.co.za> Changes by Giampaolo Rodola' : ---------- versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 20 21:32:58 2014 From: report at bugs.python.org (James Bostock) Date: Sun, 20 Apr 2014 19:32:58 +0000 Subject: [issue837046] pyport.h redeclares gethostname() if SOLARIS is defined Message-ID: <1398022378.87.0.358528078245.issue837046@psf.upfronthosting.co.za> James Bostock added the comment: I have not compiled Python from source code for many years and no longer have access to Solaris machines so I cannot say whether or not this is still a problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 20 22:43:42 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 20 Apr 2014 20:43:42 +0000 Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS In-Reply-To: <1398008701.89.0.526554124831.issue18967@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: PEP 462 is months away from going anywhere, and I personally find the current NEWS handling a major barrier to feeling inclined to work on bug fixes. The status quo will *definitely* be PEP 462 incompatible, though, since it would typically prevent applying the same patch to multiple branches. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 00:37:28 2014 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 20 Apr 2014 22:37:28 +0000 Subject: [issue20962] Rather modest chunk size in gzip.GzipFile In-Reply-To: <1395082726.87.0.730756156096.issue20962@psf.upfronthosting.co.za> Message-ID: <1398033448.12.0.00836351512236.issue20962@psf.upfronthosting.co.za> Ezio Melotti added the comment: You should try with different chunk and file sizes and see what is the best compromise. Tagging as "easy" in case someone wants to put together a small script to benchmark this (maybe it could even be added to http://hg.python.org/benchmarks/), or even a patch. ---------- keywords: +easy nosy: +ezio.melotti stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 00:38:28 2014 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 20 Apr 2014 22:38:28 +0000 Subject: [issue20969] Author of EPUB version of Python docs is set to Unknown instead of PSF In-Reply-To: <1395153249.12.0.327856107433.issue20969@psf.upfronthosting.co.za> Message-ID: <1398033508.7.0.172835780034.issue20969@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- keywords: +easy nosy: +ezio.melotti stage: -> needs patch versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 00:40:26 2014 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 20 Apr 2014 22:40:26 +0000 Subject: [issue20977] pyflakes: undefined "ctype" in 2 except blocks in the email module In-Reply-To: <1395226153.72.0.859360673019.issue20977@psf.upfronthosting.co.za> Message-ID: <1398033626.5.0.972300464137.issue20977@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- keywords: +easy stage: -> needs patch type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 00:42:42 2014 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 20 Apr 2014 22:42:42 +0000 Subject: [issue20997] Wrong URL fragment identifier in search result In-Reply-To: <1395327003.08.0.0901954371896.issue20997@psf.upfronthosting.co.za> Message-ID: <1398033762.07.0.132149714544.issue20997@psf.upfronthosting.co.za> Ezio Melotti added the comment: It might be a bug in the older Sphinx version used to build the 2.x docs. If this is the case, it's probably not worth fixing. Georg? ---------- nosy: +ezio.melotti, georg.brandl resolution: -> wont fix status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 00:56:45 2014 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 20 Apr 2014 22:56:45 +0000 Subject: [issue21213] Memory bomb by incorrect custom serializer to json.dumps In-Reply-To: <1397472980.58.0.747239124099.issue21213@psf.upfronthosting.co.za> Message-ID: <1398034605.31.0.969107155804.issue21213@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti, pitrou, rhettinger type: -> behavior versions: +Python 3.4, Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 00:57:25 2014 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 20 Apr 2014 22:57:25 +0000 Subject: [issue21221] Minor struct_time documentation bug In-Reply-To: <1397500160.88.0.743491348049.issue21221@psf.upfronthosting.co.za> Message-ID: <1398034645.78.0.029590583773.issue21221@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- keywords: +easy stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 01:00:17 2014 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 20 Apr 2014 23:00:17 +0000 Subject: [issue21231] Issue a python 3 warning when old style classes are defined. In-Reply-To: <1397530913.57.0.912065211904.issue21231@psf.upfronthosting.co.za> Message-ID: <1398034817.12.0.703001952046.issue21231@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- components: +Interpreter Core nosy: +ezio.melotti stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 01:03:07 2014 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 20 Apr 2014 23:03:07 +0000 Subject: [issue21232] Use of '1' instead of 'True' as 'splitlines' argument in difflib documentation In-Reply-To: <1397542231.28.0.662234584475.issue21232@psf.upfronthosting.co.za> Message-ID: <1398034987.89.0.0993143752529.issue21232@psf.upfronthosting.co.za> Ezio Melotti added the comment: I think that the general consensus is that changing the value of True and False is not supported, and the result of doing it is undefined, so I think Ned request is reasonable. ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 01:10:45 2014 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 20 Apr 2014 23:10:45 +0000 Subject: [issue21278] Running the test suite with -v makes the test_ctypes and the test_zipimport erroneously reported as failed In-Reply-To: <1397689360.76.0.544034222842.issue21278@psf.upfronthosting.co.za> Message-ID: <1398035445.28.0.0549224679642.issue21278@psf.upfronthosting.co.za> Ezio Melotti added the comment: Do you want to propose a patch? ---------- components: +Tests nosy: +ezio.melotti type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 01:32:04 2014 From: report at bugs.python.org (R. David Murray) Date: Sun, 20 Apr 2014 23:32:04 +0000 Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za> Message-ID: <1398036724.78.0.293691228482.issue18967@psf.upfronthosting.co.za> R. David Murray added the comment: Yes, after thinking about this this weekend, it is clear to me that in the future we will *need* a scheme where by the NEWS entry can be safely included in the patch in some form. I think the commit message is also going to be in the patch, which will be in 'hg export' form, if I'm understanding the stuff the Mecurial folks were telling us at PyCon correctly. So, in theory the script approach would still work, if anybody can run it (to commit locally and then export) and if what it produces is something that won't get stale. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 01:41:13 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 20 Apr 2014 23:41:13 +0000 Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za> Message-ID: <1398037273.16.0.761920957091.issue18967@psf.upfronthosting.co.za> Terry J. Reedy added the comment: A file per news entry seems a bit much, but an optional file per developer would solve most of the problem for those who have a problem with the status quo. Add a directory named, for instance, news.3.4.1. Put in a template with the allowed section headings. Call it something like aaTemplate.txt to sort first. To avoid merge conflicts due to entries for new features in default, quadruple space between headers so the only non-blank context would be the section header above. Developers like me who have a problem with the existing system could copy the file, rename it with their name (terry.reedy.txt, etc), hg add it, and use it for news entries (with extra blank lines to maintain the clean context. A script could be written to sync the working directory (pull and merge), move entries into NEWS (skipping over blank lines), recopy the template, commit and push. If I were working on non-Idle code issues, I would seriously consider doing the above with a private, non-repository file in /MISC that I might merge one a week or so. Someone objected to changes that result in news entries being out patch push order. This is already not a rule because the devguide mentions inserting new items at random positions to avoid conflicts due to another commit. Also, News items are frequently pushed sometime after the corresponding patch. I don't know if this is because people forget or because they want to isolate any hassle with a news conflict. In any case, the News entries are not necessarily time ordered now. >From a user perspective, having library news items sorted by affected module, with code, doc, and test changes collected together, would generally be more useful. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 01:54:15 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 20 Apr 2014 23:54:15 +0000 Subject: [issue21232] Use of '1' instead of 'True' as 'splitlines' argument in difflib documentation In-Reply-To: <1397542231.28.0.662234584475.issue21232@psf.upfronthosting.co.za> Message-ID: <1398038055.09.0.63988960948.issue21232@psf.upfronthosting.co.za> Terry J. Reedy added the comment: If you want to backport, go ahead. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 01:59:41 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 20 Apr 2014 23:59:41 +0000 Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za> Message-ID: <1398038381.28.0.0719956846162.issue18967@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > This is already not a rule because the devguide mentions inserting new > items at random positions to avoid conflicts due to another commit. Really? """New NEWS entries are customarily added at or near the top of their respective sections, so that entries within a section appear in approximate order from newest to oldest. However, this is customary and not a requirement.""" > In any case, the News entries are not necessarily time ordered now. IME, they mostly are. It's true it's not a requirement. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 02:05:35 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 21 Apr 2014 00:05:35 +0000 Subject: [issue21231] Issue a python 3 warning when old style classes are defined. In-Reply-To: <1397530913.57.0.912065211904.issue21231@psf.upfronthosting.co.za> Message-ID: <1398038735.4.0.804604217307.issue21231@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Your changes in ceval.c introduce a bug (missing braces). Besides, I'm not sure it's a good idea. What if you're extending a class provided by a third-party library? (just because it's an old-style class doesn't mean it won't work fine under 3.x) ---------- nosy: +benjamin.peterson, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 02:10:18 2014 From: report at bugs.python.org (Skip Montanaro) Date: Mon, 21 Apr 2014 00:10:18 +0000 Subject: [issue20962] Rather modest chunk size in gzip.GzipFile In-Reply-To: <1395082726.87.0.730756156096.issue20962@psf.upfronthosting.co.za> Message-ID: <1398039018.88.0.330711865193.issue20962@psf.upfronthosting.co.za> Skip Montanaro added the comment: Here's a straightforward patch. I didn't want to change the public API of the module, so just defined the chunk size with a leading underscore. Gzip tests continue to pass. ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file34987/gzip.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 02:18:07 2014 From: report at bugs.python.org (Dolda2000) Date: Mon, 21 Apr 2014 00:18:07 +0000 Subject: [issue21317] Home page certificate troubles Message-ID: <1398039487.2.0.185470776483.issue21317@psf.upfronthosting.co.za> New submission from Dolda2000: This is misfiled under "Documentation" since it affects the documentation peripherally and I couldn't find any better component to file it under. To get to the point, the website seems to have certificate troubles for some URLs affecting the older versions of documentation. For instance, at this URL: For me at least, it says "400 Bad Request // The SSL certificate error [sic] // nginx". I am also not allowed to access it over HTTP, since that just redirects me to the HTTPS version. (As an aside, you may also want to fix the typo in the error message while your at it. ;) ---------- assignee: docs at python components: Documentation messages: 216928 nosy: Dolda2000, docs at python priority: normal severity: normal status: open title: Home page certificate troubles type: crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 02:20:25 2014 From: report at bugs.python.org (Alex Gaynor) Date: Mon, 21 Apr 2014 00:20:25 +0000 Subject: [issue21317] Home page certificate troubles In-Reply-To: <1398039487.2.0.185470776483.issue21317@psf.upfronthosting.co.za> Message-ID: <1398039625.81.0.731460435458.issue21317@psf.upfronthosting.co.za> Alex Gaynor added the comment: The infra team is looking into this, and I believe it should be fixed by now. (None of the infra people really are on this issue tracker, so I'm closing this, sorry :-/) ---------- nosy: +alex resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 02:31:06 2014 From: report at bugs.python.org (Jan Gosmann) Date: Mon, 21 Apr 2014 00:31:06 +0000 Subject: [issue21318] sdist fails with symbolic links do non-existing files Message-ID: <1398040266.25.0.437462468374.issue21318@psf.upfronthosting.co.za> New submission from Jan Gosmann: If there is a symbolic link to a non-existing file anywhere in the source tree "python setup.py sdist" fails with an output like the following: running sdist running check warning: check: missing required meta-data: url error: abc: No such file or directory Pruning the problematic path with a MANIFEST.in file does not help. I could locate the culprit in filelist.py in line 267: stat = os.stat(fullname) fails for symlinks to non-existing files. Maybe os.lstat should be used? Or it should be checked before os.stat if it is a symlink to a nonexisting file? In case you wonder why I have links to non-existing files in my source tree: Those can be left behind by automated tests I'm using and are not supposed to be part of the source (or any other) distribution. But as I said, the error is not prevented by excluding them with a MANIFEST.in file. My current workaround is to delete all the leftovers from the test as first thing in setup.py. ---------- components: Distutils messages: 216930 nosy: dstufft, eric.araujo, jgosmann priority: normal severity: normal status: open title: sdist fails with symbolic links do non-existing files type: behavior versions: Python 2.7, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 02:34:30 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 21 Apr 2014 00:34:30 +0000 Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS In-Reply-To: <1398038381.28.0.0719956846162.issue18967@psf.upfronthosting.co.za> Message-ID: <53546763.5030408@udel.edu> Terry J. Reedy added the comment: On 4/20/2014 7:59 PM, Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > >> This is already not a rule because the devguide mentions inserting new >> items at random positions to avoid conflicts due to another commit. > > Really? > > """New NEWS entries are customarily added at or near the top of their respective sections, so that entries within a section appear in approximate order from newest to oldest. However, this is customary and not a requirement.""" Random is too loose for what was actually committed and I will correct it. Further down in the same section: "A nice trick to make Mercurial?s automatic file merge work more smoothly is to put a new entry after the first or first two entries rather than at the very top. This way if you commit, pull new changesets and merge, the merge will succeed automatically." >> In any case, the News entries are not necessarily time ordered now. > > IME, they mostly are. It's true it's not a requirement. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 02:49:15 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 21 Apr 2014 00:49:15 +0000 Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za> Message-ID: <1398041355.48.0.150058975156.issue18967@psf.upfronthosting.co.za> Terry J. Reedy added the comment: For the recommendation actually put in the devguide, change 'random position' to 'position near but not at the top'. https://docs.python.org/devguide/committing.html#news-entries ends with "A nice trick to make Mercurial?s automatic file merge work more smoothly is to put a new entry after the first or first two entries rather than at the very top. This way if you commit, pull new changesets and merge, the merge will succeed automatically." My main point was that the devguide a) recognizes that there is an issue and b) does not require strict date order. Merging items into the NEWS on a daily basis would keep approximate time order. Hourly merges would do even better. This recommendation, however, is not very effective. It only only avoids conflict with another patch if the other person does not use the 'nice trick' but puts the news entry at the top. Unless one looks carefully, it does not help the problen of merging maintenance bugfix items into a default list that also contains enhancement news not in the maintenance list*. In fact, blindly putting an item between two news items rather than a header and one news item makes that conflict more likely. * There have been times, like last Jan-Feb, when default only items dominated the default news list. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 03:20:52 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 21 Apr 2014 01:20:52 +0000 Subject: [issue21231] Issue a python 3 warning when old style classes are defined. In-Reply-To: <1397530913.57.0.912065211904.issue21231@psf.upfronthosting.co.za> Message-ID: <1398043252.26.0.51206429982.issue21231@psf.upfronthosting.co.za> Benjamin Peterson added the comment: As I said on irc, I predict this will be extremely spammy not only on the stdlib but also on dependencies which people have no control over. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 04:18:08 2014 From: report at bugs.python.org (Luiz Poleto) Date: Mon, 21 Apr 2014 02:18:08 +0000 Subject: [issue19771] runpy should check ImportError.name before wrapping it In-Reply-To: <1385383187.11.0.803942496087.issue19771@psf.upfronthosting.co.za> Message-ID: <1398046688.88.0.413584907999.issue19771@psf.upfronthosting.co.za> Luiz Poleto added the comment: The attached patch provide test cases to validate this error. As noted by R. David Murray in a discussion in the Core-Mentorship list, this error in fact happens then __init__.py throws an ImportError. ---------- keywords: +patch nosy: +poleto Added file: http://bugs.python.org/file34988/issue_19771_tests.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 04:36:55 2014 From: report at bugs.python.org (Luiz Poleto) Date: Mon, 21 Apr 2014 02:36:55 +0000 Subject: [issue19771] runpy should check ImportError.name before wrapping it In-Reply-To: <1385383187.11.0.803942496087.issue19771@psf.upfronthosting.co.za> Message-ID: <1398047815.57.0.128924486528.issue19771@psf.upfronthosting.co.za> Luiz Poleto added the comment: As suggested by Nick, the fix is done be verifying the name attribute of the raised ImportError exception; the exception is then re-raised with the appropriate description. ---------- Added file: http://bugs.python.org/file34989/issue_19771.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 07:04:26 2014 From: report at bugs.python.org (Eric Snow) Date: Mon, 21 Apr 2014 05:04:26 +0000 Subject: [issue21319] WindowsRegistryFinder never added to sys.meta_path Message-ID: <1398056666.81.0.531490496163.issue21319@psf.upfronthosting.co.za> New submission from Eric Snow: For #14578 we added WindowsRegistryFinder to importlib and try adding it to sys.meta_path during bootstrap (see bd58c421057c). I happened to notice that in _install() in Lib/importlib/_bootstrap.py we check os.__name__. Shouldn't it be os.name? os.__name__ is always going to be "os"! p.s. I'm guessing that finder doesn't get used a whole lot. ;) ---------- components: Interpreter Core messages: 216936 nosy: brett.cannon, eric.snow, loewis priority: normal severity: normal stage: test needed status: open title: WindowsRegistryFinder never added to sys.meta_path type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 07:04:39 2014 From: report at bugs.python.org (Eric Snow) Date: Mon, 21 Apr 2014 05:04:39 +0000 Subject: [issue21319] WindowsRegistryFinder never added to sys.meta_path In-Reply-To: <1398056666.81.0.531490496163.issue21319@psf.upfronthosting.co.za> Message-ID: <1398056679.88.0.400252251634.issue21319@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- versions: +Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 07:17:44 2014 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 21 Apr 2014 05:17:44 +0000 Subject: [issue21314] Bizarre help In-Reply-To: <1397988439.5.0.703056699862.issue21314@psf.upfronthosting.co.za> Message-ID: <1398057464.88.0.248617314565.issue21314@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 07:34:55 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 21 Apr 2014 05:34:55 +0000 Subject: [issue16801] Preserve original representation for integers / floats in docstrings In-Reply-To: <1356699853.91.0.313275944642.issue16801@psf.upfronthosting.co.za> Message-ID: <1398058495.85.0.564465860153.issue16801@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 10:30:17 2014 From: report at bugs.python.org (Steven Barker) Date: Mon, 21 Apr 2014 08:30:17 +0000 Subject: [issue1234674] filecmp.cmp's "shallow" option Message-ID: <1398069017.38.0.801601615296.issue1234674@psf.upfronthosting.co.za> Steven Barker added the comment: A recent Stack Overflow question (http://stackoverflow.com/q/23192359/1405065) relates to this bug. The questioner was surprised that filecmp.cmp is much slower than usual for certain large files, despite the "shallow" parameter being True. It is pretty clear to me that the behavior of filecmp.cmp does not match its docstring with respect to "shallow". Either the docstring should be updated to match the existing behavior, or (more likely?) the behavior should change to match the docs. ---------- components: +Library (Lib) -Extension Modules nosy: +Steven.Barker versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 13:54:59 2014 From: report at bugs.python.org (Cyphase) Date: Mon, 21 Apr 2014 11:54:59 +0000 Subject: [issue21320] dict() allows keyword expansion with integer keys, e.g. dict(**{5:'v'}) Message-ID: <1398081299.38.0.288058317096.issue21320@psf.upfronthosting.co.za> New submission from Cyphase: Python 2.7.6: Affected Python 3.2.3: Not affected dict() allows keyword expansion using a dict() with integer keys, whereas attempting to do so with most other functions raises a TypeError with the message, "keywords must be strings". The same thing happens with collections.defaultdict(), but not collections.Counter() or collections.OrderedDict, presumably because they override dict.__init__(). >>> old_dict = {'a': 1, 2: 'b'} >>> old_dict {'a': 1, 2: 'b'} >>> other_dict = {'c': 3, 4: 'd'} >>> other_dict >>> new_dict = dict(old_dict, **other_dict) >>> new_dict {'a': 1, 2: 'b', 4: 'd', 'c': 3} I feel like this must be known, but I didn't find anything with a search. ---------- components: Interpreter Core messages: 216938 nosy: Cyphase priority: normal severity: normal status: open title: dict() allows keyword expansion with integer keys, e.g. dict(**{5:'v'}) type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 14:13:50 2014 From: report at bugs.python.org (Anton Afanasyev) Date: Mon, 21 Apr 2014 12:13:50 +0000 Subject: [issue21321] itertools.islice() doesn't release reference to the source iterator when the slice is exhausted Message-ID: <1398082430.51.0.59207810702.issue21321@psf.upfronthosting.co.za> New submission from Anton Afanasyev: This issue results in redundant memory consumption for e.g. in this case: ================================================ from itertools import * def test_islice(): items, lookahead = tee(repeat(1, int(1e9))) lookahead = islice(lookahead, 10) for item in lookahead: pass for item in items: pass if __name__ == "__main__": test_islice() ================================================ This demo is taken from real case where one needs to look ahead input stream before processing it. For my PC this demo stops with 'Segmentation fault' message after exhausting all PC memory, while running it with patched python consumes only 0.1% of memory till the end. When one uses pure pythonic implementation of itertools.islice() (taken from docs), the issue goes away as well, since this implementation doesn't store redundant reference to source iterator. ================================================ def islice(iterable, *args): s = slice(*args) it = iter(xrange(s.start or 0, s.stop or sys.maxint, s.step or 1)) nexti = next(it) for i, element in enumerate(iterable): if i == nexti: yield element nexti = next(it) ================================================ Attaching patch for this issue. Have to change '__reduce__()' method since now unpickling of exhausted 'islice()' object cannot return old source iterator. ---------- components: Extension Modules files: patch_3.4_8c8315bac6a8.diff keywords: patch messages: 216939 nosy: Anton.Afanasyev, rhettinger priority: normal severity: normal status: open title: itertools.islice() doesn't release reference to the source iterator when the slice is exhausted type: resource usage versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file34990/patch_3.4_8c8315bac6a8.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 14:41:36 2014 From: report at bugs.python.org (Anton Afanasyev) Date: Mon, 21 Apr 2014 12:41:36 +0000 Subject: [issue21321] itertools.islice() doesn't release reference to the source iterator when the slice is exhausted In-Reply-To: <1398082430.51.0.59207810702.issue21321@psf.upfronthosting.co.za> Message-ID: <1398084096.48.0.576925398781.issue21321@psf.upfronthosting.co.za> Anton Afanasyev added the comment: Added patch for 2.7 version (no need to change '__reduce__()' method since it's not implemented). ---------- Added file: http://bugs.python.org/file34991/issue21321_2.7_e3217efa6edd.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 14:43:20 2014 From: report at bugs.python.org (Michael Boldischar) Date: Mon, 21 Apr 2014 12:43:20 +0000 Subject: [issue21303] Python 2.7 Spinbox Format Behaves Differently On Windows Versus Linux In-Reply-To: <1397853102.02.0.000549588678959.issue21303@psf.upfronthosting.co.za> Message-ID: <1398084200.56.0.650952005456.issue21303@psf.upfronthosting.co.za> Michael Boldischar added the comment: Windows 7 64-bit: >>> root.tk.eval('info patchlevel') '8.5.2' Debian 7 Linux 64-bit: root.tk.eval('info patchlevel') '8.5.11' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 14:46:32 2014 From: report at bugs.python.org (Michael Boldischar) Date: Mon, 21 Apr 2014 12:46:32 +0000 Subject: [issue21303] Python 2.7 Spinbox Format Behaves Differently On Windows Versus Linux In-Reply-To: <1397853102.02.0.000549588678959.issue21303@psf.upfronthosting.co.za> Message-ID: <1398084392.81.0.422431261505.issue21303@psf.upfronthosting.co.za> Michael Boldischar added the comment: Windows 7 64-bit: python --version Python 2.7.6 Debian 7 Linux 64-bit: $ python --version Python 2.7.3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 15:27:06 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 21 Apr 2014 13:27:06 +0000 Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za> Message-ID: <1398086826.2.0.161931934653.issue18967@psf.upfronthosting.co.za> R. David Murray added the comment: In order for things to work with a patch gating system, I believe it will be the most practical for the news items to be each in a separate file. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 15:30:18 2014 From: report at bugs.python.org (Tito Bouzout) Date: Mon, 21 Apr 2014 13:30:18 +0000 Subject: [issue21283] A escape character is used when a REGEXP is an argument of "strip" string function In-Reply-To: <1397742885.45.0.765313151501.issue21283@psf.upfronthosting.co.za> Message-ID: <1398087018.88.0.348604075859.issue21283@psf.upfronthosting.co.za> Tito Bouzout added the comment: Thanks guys for the information! Is still weird to me that the escape character is used, but well ! Will remember this bug. Kind regards, ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 15:57:12 2014 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 21 Apr 2014 13:57:12 +0000 Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za> Message-ID: <1398088632.6.0.804966363718.issue18967@psf.upfronthosting.co.za> Ezio Melotti added the comment: > Unless one looks carefully, it does not help the problen of merging > maintenance bugfix items into a default list that also contains > enhancement news not in the maintenance list*. What if instead of having sections in Misc/NEWS for core/library/documentation/etc., we simply make sections for bug fixes and enhancements? Wouldn't this basically solve the conflict problem (assuming all/most bug fixes are backported, and new features are only on default)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 16:49:34 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 21 Apr 2014 14:49:34 +0000 Subject: [issue21320] dict() allows keyword expansion with integer keys, e.g. dict(**{5:'v'}) In-Reply-To: <1398081299.38.0.288058317096.issue21320@psf.upfronthosting.co.za> Message-ID: <1398091774.66.0.326057753855.issue21320@psf.upfronthosting.co.za> R. David Murray added the comment: 2.7 can't be changed for backward compatibility reasons, and python3 enforces the restriction in dict, as you observe. I don't know if a python2 documentation note is worthwhile, but given the conversations at pycon about adding additional -3 warnings to 2.7, it seems like this is a place such a warning would be justified. ---------- nosy: +r.david.murray stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 17:54:10 2014 From: report at bugs.python.org (Zachary Ware) Date: Mon, 21 Apr 2014 15:54:10 +0000 Subject: [issue21303] Python 2.7 Spinbox Format Behaves Differently On Windows Versus Linux In-Reply-To: <1397853102.02.0.000549588678959.issue21303@psf.upfronthosting.co.za> Message-ID: <1398095650.78.0.302926683298.issue21303@psf.upfronthosting.co.za> Zachary Ware added the comment: >From some testing, this looks like a Tcl/Tk bug, fixed somewhere between 8.5.9 and 8.5.11: Python 3.2.5 which shipped with Tcl/Tk 8.5.9 shows this bug; Python 3.3.5 which shipped with Tcl/Tk 8.5.11 does not, and Python 2.7 built with Tcl/Tk 8.5.11 doesn't show it. Tcl/Tk 8.6.1 is also free of the bug. Benjamin, what's your take on updating the version of Tcl/Tk shipped with the next Python 2.7 Windows installer? Updating to a newer 8.5 is just a matter of changing paths in the buildbot scripts (and making sure whoever does the installer since Martin has retired knows about it); updating to 8.6 also requires some minor updates to PCbuild/pyproject.vsprops, but seems to work fine. See also issue20565. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 17:57:59 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 21 Apr 2014 15:57:59 +0000 Subject: [issue21303] Python 2.7 Spinbox Format Behaves Differently On Windows Versus Linux In-Reply-To: <1398095650.78.0.302926683298.issue21303@psf.upfronthosting.co.za> Message-ID: <1398095876.15915.108675089.4F7F7FBD@webmail.messagingengine.com> Benjamin Peterson added the comment: On Mon, Apr 21, 2014, at 8:54, Zachary Ware wrote: > > Zachary Ware added the comment: > > >From some testing, this looks like a Tcl/Tk bug, fixed somewhere between 8.5.9 and 8.5.11: Python 3.2.5 which shipped with Tcl/Tk 8.5.9 shows this bug; Python 3.3.5 which shipped with Tcl/Tk 8.5.11 does not, and Python 2.7 built with Tcl/Tk 8.5.11 doesn't show it. Tcl/Tk 8.6.1 is also free of the bug. > > Benjamin, what's your take on updating the version of Tcl/Tk shipped with > the next Python 2.7 Windows installer? Updating to a newer 8.5 is just a > matter of changing paths in the buildbot scripts (and making sure whoever > does the installer since Martin has retired knows about it); updating to > 8.6 also requires some minor updates to PCbuild/pyproject.vsprops, but > seems to work fine. Sounds fine to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 18:38:23 2014 From: report at bugs.python.org (Zachary Ware) Date: Mon, 21 Apr 2014 16:38:23 +0000 Subject: [issue21303] Python 2.7 Spinbox Format Behaves Differently On Windows Versus Linux In-Reply-To: <1397853102.02.0.000549588678959.issue21303@psf.upfronthosting.co.za> Message-ID: <1398098303.63.0.128948441032.issue21303@psf.upfronthosting.co.za> Zachary Ware added the comment: Any opinions on which version to update to? 8.5.11 is easy and available and fixes the bug; 8.5.15 is the newest 8.5 but not on svn.python.org; 8.6.1 is available and is also what 3.4 (and currently 3.5) ships with. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 18:42:49 2014 From: report at bugs.python.org (=?utf-8?q?I=C3=B1igo_Serna?=) Date: Mon, 21 Apr 2014 16:42:49 +0000 Subject: [issue21322] Pathlib .owner() and .group() methods fail on broken links Message-ID: <1398098569.86.0.723629898468.issue21322@psf.upfronthosting.co.za> New submission from I?igo Serna: Pathlib .owner() and .group() methods fail on broken symlinks. They use: return pwd.getpwuid(self.stat().st_uid).pw_name and: return grp.getgrgid(self.stat().st_gid).gr_name It should be self.lstat(). Attached simple fix as unified diff. ---------- components: Library (Lib) files: pathlib-34-owner_group_fixed.diff keywords: patch messages: 216950 nosy: inigoserna priority: normal severity: normal status: open title: Pathlib .owner() and .group() methods fail on broken links type: crash versions: Python 3.4 Added file: http://bugs.python.org/file34992/pathlib-34-owner_group_fixed.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 19:00:20 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 21 Apr 2014 17:00:20 +0000 Subject: [issue19771] runpy should check ImportError.name before wrapping it In-Reply-To: <1385383187.11.0.803942496087.issue19771@psf.upfronthosting.co.za> Message-ID: <1398099620.07.0.972684624883.issue19771@psf.upfronthosting.co.za> R. David Murray added the comment: Hmm. It seems to me that .name not being set is a bug in importlib. It appears that importlib doesn't set it in the 'from x import y' case. After a bit of experimenting at the python prompt, I'm not even sure what that code in runpy is *doing* (find_spec('foo.__main__') seems to return None if __main__ doesn't exist but foo does). I'm going to have to leave this to Nick unless I find some more time somewhere ;) ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 19:09:13 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 21 Apr 2014 17:09:13 +0000 Subject: [issue12916] Add inspect.splitdoc In-Reply-To: <1315326747.38.0.43030903994.issue12916@psf.upfronthosting.co.za> Message-ID: <1398100153.83.0.822722910243.issue12916@psf.upfronthosting.co.za> R. David Murray added the comment: It should receive a string. This is parallel to cleandoc, and I think splitdoc should go in the documentation right after cleandoc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 19:10:17 2014 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Mon, 21 Apr 2014 17:10:17 +0000 Subject: [issue12916] Add inspect.splitdoc In-Reply-To: <1398100153.83.0.822722910243.issue12916@psf.upfronthosting.co.za> Message-ID: <004266D0-2A43-4131-B7A7-714E23BB6507@wirtel.be> St?phane Wirtel added the comment: I will fix this issue asap, but I was too tired with the travel to Belgium. Hope to propose patch during this week. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 19:17:41 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 21 Apr 2014 17:17:41 +0000 Subject: [issue18401] Tests for pdb import ~/.pdbrc In-Reply-To: <1373261746.39.0.598108958249.issue18401@psf.upfronthosting.co.za> Message-ID: <1398100661.21.0.107588891346.issue18401@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, Sam. It is more helpful if the NEWS entry is *not* put in the patch given the current state of the tooling. What's needs to be added is an entry in Doc/whatsnew/3.5. For the new test, you can take advantage of the temp_dir and EnvironmentVarGuard helpers in test.support to simplify the code and make it more bullet proof. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 19:53:35 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 21 Apr 2014 17:53:35 +0000 Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za> Message-ID: <1398102815.15.0.313205165526.issue18967@psf.upfronthosting.co.za> R. David Murray added the comment: That would probably work for now, but it wouldn't work for the patch gating system. On the other hand, it would sure make it easier to build/check whatsnew. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 19:56:18 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 21 Apr 2014 17:56:18 +0000 Subject: [issue20962] Rather modest chunk size in gzip.GzipFile In-Reply-To: <1395082726.87.0.730756156096.issue20962@psf.upfronthosting.co.za> Message-ID: <1398102978.66.0.031317351883.issue20962@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +nadeem.vawda, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 20:09:32 2014 From: report at bugs.python.org (Ned Deily) Date: Mon, 21 Apr 2014 18:09:32 +0000 Subject: [issue21303] Python 2.7 Spinbox Format Behaves Differently On Windows Versus Linux In-Reply-To: <1397853102.02.0.000549588678959.issue21303@psf.upfronthosting.co.za> Message-ID: <1398103772.66.0.942139833486.issue21303@psf.upfronthosting.co.za> Ned Deily added the comment: FWIW, ActiveState is shipping 8.5.15 and 8.6.1 in ActiveTcl. For the OS X installers, we have been using 8.5.x (for the 64-bit/32-bit installer) because that's also what Apple has been shipping in recent OS X versions. Serhiy has committed a number of fixes in 3.x for Tk 8.6.x; I'm not sure if they are all backported to 2.7. I'm planning to stick with 8.5.x for OS X for 2.7 at least, and, with the various bugs in the Cocoa (OS X) Tk port, that means the very latest 8.5.15+. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 20:14:16 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 21 Apr 2014 18:14:16 +0000 Subject: [issue21303] Python 2.7 Spinbox Format Behaves Differently On Windows Versus Linux In-Reply-To: <1398098303.63.0.128948441032.issue21303@psf.upfronthosting.co.za> Message-ID: <1398104053.8438.108726113.650D43C8@webmail.messagingengine.com> Benjamin Peterson added the comment: On Mon, Apr 21, 2014, at 9:38, Zachary Ware wrote: > > Zachary Ware added the comment: > > Any opinions on which version to update to? 8.5.11 is easy and available > and fixes the bug; 8.5.15 is the newest 8.5 but not on svn.python.org; > 8.6.1 is available and is also what 3.4 (and currently 3.5) ships with. It would probably be good to have similar versions in the mac and windows installers. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 20:37:15 2014 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 21 Apr 2014 18:37:15 +0000 Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za> Message-ID: <1398105435.56.0.627848427726.issue18967@psf.upfronthosting.co.za> Ezio Melotti added the comment: Also having a list of enhancements and bug fixes might be more meaningful for users than a list of core issues vs library issues vs other similar sections. This could also be done with two separate files, with the "new features/enhancements" file existing only on default and the "bug fixes" file existing across branches. From there it shouldn't be difficult for the gating system to append/prepend/insert the news. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 20:51:09 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 21 Apr 2014 18:51:09 +0000 Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za> Message-ID: <1398106269.95.0.985226989805.issue18967@psf.upfronthosting.co.za> R. David Murray added the comment: That makes the tooling of the gating system harder, though. If the NEWS can just be a file in the patch, we don't have to have any special tooling for it in the gating system. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 21:05:31 2014 From: report at bugs.python.org (Konstantin S. Solnushkin) Date: Mon, 21 Apr 2014 19:05:31 +0000 Subject: [issue21323] CGI HTTP server not running scripts from subdirectories Message-ID: <1398107131.28.0.812868414728.issue21323@psf.upfronthosting.co.za> New submission from Konstantin S. Solnushkin: Somewhere between Python 3.3 and 3.4, a bug was introduced that forbids the "http.server" module, working in CGI server mode, to run scripts residing in subdirectories. This will break existing software that relies on this feature. How to reproduce the bug: 1. Create a temporary directory and enter it. 2. Create a directory "cgi-bin", and then directory "test" inside "cgi-bin". 3. Create a file "test.py" in "cgi-bin/test" with the following contents (see also attachment to this bug report): print("""Content-type: text/plain CGI script executed successfully! """) 4. When run, it should print the following: Content-type: text/plain CGI script executed successfully! 5. Now, run Python 3.3 in CGI HTTP server mode: c:\Python33\python.exe -m http.server --cgi 8000 A request to "http://localhost:8000/cgi-bin/test/test.py" then produces the following in the HTTP server log: Serving HTTP on 0.0.0.0 port 8000 ... 127.0.0.1 - - [21/Apr/2014 22:59:11] "GET /cgi-bin/test/test.py HTTP/1.0" 200 - 127.0.0.1 - - [21/Apr/2014 22:59:11] command: c:\Python33\python.exe -u C:\TMP\cgi-bin\test\test.py "" 127.0.0.1 - - [21/Apr/2014 22:59:11] CGI script exited OK 6. Now, try this with Python 3.4, and the request will fail with the following in the log: C:\TMP>c:\Python34\python.exe -m http.server --cgi 8000 Serving HTTP on 0.0.0.0 port 8000 ... 127.0.0.1 - - [21/Apr/2014 23:02:38] code 403, message CGI script is not a plain file ('/cgi-bin/test') 127.0.0.1 - - [21/Apr/2014 23:02:38] "GET /cgi-bin/test/test.py HTTP/1.0" 403 - This _could_ be related to the change introduced by issue 19435, although I am not sure. Tested with Windows XP SP3. ---------- files: test.py messages: 216960 nosy: k.s.solnushkin priority: normal severity: normal status: open title: CGI HTTP server not running scripts from subdirectories type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file34993/test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 21:19:43 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 21 Apr 2014 19:19:43 +0000 Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za> Message-ID: <1398107983.65.0.828564531387.issue18967@psf.upfronthosting.co.za> Terry J. Reedy added the comment: If we put news items in a database keyed by issue number (and I think it reasonable that all news-worthy patches should have a tracker issue), then there would be no conflicts. (We already avoid simultaneous commits to the same issue.) If the database had fields such as the type of issue/patch and the component affected, then different queries could create text files sorted differently. We already have such a database with such fields and indexed by issue number -- the tracker itself. We could either copy data from the tracker into a separate database or add to the tracker a textbox News field that is only editable by either by the 'Assigned to' person or perhaps any committer. I personally would prefer a box that I could fill out when closing the issue. (The tracker could even ask for verification when closing a 'fixed' issue with a blank news.) News summaries could be extracted at any time by scanning commit messages since the last release for issue numbers. A news box on the tracker would give people looking at the issue thereafter a quick summary of the result of the issue without scanning through all the messages and checking the patches. Since the issue formatting is being reviewed, I think the issue summary should also include the exact releases patched. This would help people to see if an issue is only open for a possible backport, It might also help a program selecting issues for a news report. I am, of course, aware that I have glossed over many details. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 21:24:46 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 21 Apr 2014 19:24:46 +0000 Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za> Message-ID: <1398108286.9.0.999493099879.issue18967@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Moving News items from the repository to the tracker, where I think they initially belong anyway, would also remove them as an issue for a future gating system. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 21:33:03 2014 From: report at bugs.python.org (Zachary Ware) Date: Mon, 21 Apr 2014 19:33:03 +0000 Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za> Message-ID: <1398108783.81.0.596174607921.issue18967@psf.upfronthosting.co.za> Zachary Ware added the comment: Terry J. Reedy wrote: > Moving News items from the repository to the tracker, where I think > they initially belong anyway, would also remove them as an issue for > a future gating system. I think News items are best left in the repository just so that for any given snapshot of the repository, you can see what significant changes are present. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 21:41:20 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 21 Apr 2014 19:41:20 +0000 Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za> Message-ID: <1398109280.12.0.804758006484.issue18967@psf.upfronthosting.co.za> R. David Murray added the comment: Yeah, Guido was strongly in favor of that too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 21:45:14 2014 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 21 Apr 2014 19:45:14 +0000 Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za> Message-ID: <1398109514.44.0.998684940708.issue18967@psf.upfronthosting.co.za> Ezio Melotti added the comment: Agreed. Once the gating system is in place nothing prevent us to read the NEWS entry either from the patch that is being committed or from a field in the tracker and then including it together with the patch once it is approved. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 21:54:44 2014 From: report at bugs.python.org (Marcin Szewczyk) Date: Mon, 21 Apr 2014 19:54:44 +0000 Subject: [issue21324] dbhash leaks random memory fragments to a database Message-ID: <1398110084.7.0.0365348726476.issue21324@psf.upfronthosting.co.za> New submission from Marcin Szewczyk: As stated in the subject. Example is in a remote Git repository: https://bitbucket.org/wodny/python-dbm-experiments/ It shows how some random data gets into the database (into some gaps between keys and values). There is also a C example which hasn't been caught on leaking. ---------- components: Library (Lib) messages: 216966 nosy: wodny priority: normal severity: normal status: open title: dbhash leaks random memory fragments to a database type: security versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 21:55:32 2014 From: report at bugs.python.org (Michael Stahl) Date: Mon, 21 Apr 2014 19:55:32 +0000 Subject: [issue837046] pyport.h redeclares gethostname() if SOLARIS is defined Message-ID: <1398110132.29.0.0623753857913.issue837046@psf.upfronthosting.co.za> Michael Stahl added the comment: (note that i haven't used any Solaris myself since 2011) * the #ifdef SOLARIS block still exists in current hg checkout * according to comment http://bugs.python.org/msg18910 the SOLARIS macro can not be defined during a build of python itself, so: - the #ifdef SOLARIS block does not break build of python itself - the #ifdef SOLARIS block has no useful purpose * the #ifdef SOLARIS block is in a public header that may be included by _other_projects_' source files, and if those other projects happen to define a SOLARIS macro then they get the breakage (as the OOo patch demonstrates) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 22:03:28 2014 From: report at bugs.python.org (Jakub Wilk) Date: Mon, 21 Apr 2014 20:03:28 +0000 Subject: [issue21324] dbhash leaks random memory fragments to a database In-Reply-To: <1398110084.7.0.0365348726476.issue21324@psf.upfronthosting.co.za> Message-ID: <1398110608.08.0.973828261966.issue21324@psf.upfronthosting.co.za> Changes by Jakub Wilk : ---------- nosy: +jwilk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 22:33:32 2014 From: report at bugs.python.org (Giampaolo Rodola') Date: Mon, 21 Apr 2014 20:33:32 +0000 Subject: [issue17552] socket.sendfile() In-Reply-To: <1364326073.47.0.699222209849.issue17552@psf.upfronthosting.co.za> Message-ID: <1398112412.39.0.831264116506.issue17552@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: Attached is a simple benchmark script transmitting a 100MB file. On my Linux box sendfile() is almost twice as fast as send(): send() real 0.0613s user 0.0100s sys 0.0900s total 0.1000s sendfile() real 0.0318s user 0.0000s sys 0.0500s total 0.0500s ---------- Added file: http://bugs.python.org/file34994/bench.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 22:41:48 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 21 Apr 2014 20:41:48 +0000 Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za> Message-ID: <1398112908.13.0.755730209999.issue18967@psf.upfronthosting.co.za> Terry J. Reedy added the comment: A sequential log of commit messages for a particular branch would give one an even better snapshot view of activity since not all commits have news messages and even when they do, commit messages sometimes have additional info. But see below. The essence of my proposal is that the ORIGINAL entry of a news item by a human be into the tracker where there is no conflict and where it can be seen by people looking at the issue. Eliminating that conflict is the subject of this issue. After that, items can be mechanically copied wherever desired, including, possibly, into a file in the repository. My apology if this part was not clear enough. Such mechanical copying and re-arranging should not have the conflicts that are the subject of this issue. In particular, if the gating system is the only entity that edits particular news files (and I propose that there could be more than one), it will not have conflicts with other editors. Since these would be secondary, derived files, I don't see why any or all should be in the hg repository, as opposed to being part of the doc package available online along with other derived files. In other words, the hg repository is for original master files used to create derivative files nearly always not kept in the repository. We do not put .html files derived from master .rst files into the repository. So I do not see why files derived from hg repository commit messages and the tracker sql repository should go into the hg repository either. But I don't especially care if they are. I doubt Guido favors a system that inhibits commits by making them unnecessariy painful and troublesome. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 22:48:53 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 21 Apr 2014 20:48:53 +0000 Subject: [issue21225] io.py: Improve docstrings for classes In-Reply-To: <1397508646.21.0.210626779275.issue21225@psf.upfronthosting.co.za> Message-ID: <1398113333.07.0.582940773677.issue21225@psf.upfronthosting.co.za> R. David Murray added the comment: Looks good to me. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 21 23:39:11 2014 From: report at bugs.python.org (Luiz Poleto) Date: Mon, 21 Apr 2014 21:39:11 +0000 Subject: [issue19771] runpy should check ImportError.name before wrapping it In-Reply-To: <1385383187.11.0.803942496087.issue19771@psf.upfronthosting.co.za> Message-ID: <1398116351.3.0.695596434487.issue19771@psf.upfronthosting.co.za> Changes by Luiz Poleto : Added file: http://bugs.python.org/file34995/issue_19771.patch.v2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 00:19:15 2014 From: report at bugs.python.org (Berker Peksag) Date: Mon, 21 Apr 2014 22:19:15 +0000 Subject: [issue21322] Pathlib .owner() and .group() methods fail on broken links In-Reply-To: <1398098569.86.0.723629898468.issue21322@psf.upfronthosting.co.za> Message-ID: <1398118755.3.0.0529973626598.issue21322@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 00:21:33 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 21 Apr 2014 22:21:33 +0000 Subject: [issue21322] Pathlib .owner() and .group() methods fail on broken links In-Reply-To: <1398098569.86.0.723629898468.issue21322@psf.upfronthosting.co.za> Message-ID: <1398118893.09.0.951219186414.issue21322@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Most other Path methods operate on the link target, not the link itself, so I don't see why these methods would work otherwise. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 00:40:07 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 21 Apr 2014 22:40:07 +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: <1398120007.8.0.174967957611.issue21228@psf.upfronthosting.co.za> R. David Murray added the comment: That section of the docs is indeed rather confusing. Probably it just needs to be changed to say "for the methods supported by this object, see HTTPResponse Objects. I'd like to see the docs reorganized so that the '.. class' declaration in the docs is immediately followed by the class's methods, but that's a much bigger project. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 00:46:33 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Mon, 21 Apr 2014 22:46:33 +0000 Subject: [issue17552] socket.sendfile() In-Reply-To: <1364326073.47.0.699222209849.issue17552@psf.upfronthosting.co.za> Message-ID: <1398120393.93.0.485171693309.issue17552@psf.upfronthosting.co.za> Josh Rosenberg added the comment: For TransmitFile support, the Windows function to turn an integer file descriptor into a WinAPI file HANDLE should be _get_osfhandle: http://msdn.microsoft.com/en-us/library/ks2530z6.aspx ---------- nosy: +josh.rosenberg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 00:56:47 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 21 Apr 2014 22:56:47 +0000 Subject: [issue21225] io.py: Improve docstrings for classes In-Reply-To: <1397508646.21.0.210626779275.issue21225@psf.upfronthosting.co.za> Message-ID: <1398121007.71.0.354441974275.issue21225@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 01:11:25 2014 From: report at bugs.python.org (Alok Singhal) Date: Mon, 21 Apr 2014 23:11:25 +0000 Subject: [issue6305] islice doesn't accept large stop values In-Reply-To: <1245309263.43.0.625809679675.issue6305@psf.upfronthosting.co.za> Message-ID: <1398121885.88.0.261982541663.issue6305@psf.upfronthosting.co.za> Alok Singhal added the comment: This updated patch has support for starting in fast mode until the next count would result in overflow in Py_ssize_t. The first patch started in slow mode as soon as any of 'start', 'stop', or 'step' was outside of the range. With this patch, we start in fast mode if possible and then transition to slow mode when needed. I also tested this patch for correctness for the following cases: - starting in slow mode, - transition from fast -> slow, - pickle/unpickle I did this by temporarily changing the code twice: - to always use fast mode, and - pretending that overflow occurs at value 5 instead of PY_SSIZE_T_MAX. ---------- Added file: http://bugs.python.org/file34996/islice_large_values-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 01:34:51 2014 From: report at bugs.python.org (akira) Date: Mon, 21 Apr 2014 23:34:51 +0000 Subject: [issue17552] socket.sendfile() In-Reply-To: <1364326073.47.0.699222209849.issue17552@psf.upfronthosting.co.za> Message-ID: <1398123291.4.0.589225803358.issue17552@psf.upfronthosting.co.za> akira added the comment: Should socket.sendfile() always return number of bytes sent because file.tell() may be changed by something else that uses the same file descriptor? What happens if the file grows? Instead of returning `(was_os_sendfile_used, os_sendfile_error)`, you could specify `no_fallback=False` that could be set to `True` to assert that the fallback is not used (with `no_fallback=True` the `os_sendfile_error` is raised instead of using socket.send() as a fallback). If possible; always include number of bytes sent in any error that is raised. ---------- nosy: +akira _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 02:14:18 2014 From: report at bugs.python.org (Sam Vilain) Date: Tue, 22 Apr 2014 00:14:18 +0000 Subject: [issue18617] TLS and Intermediate Certificates In-Reply-To: <1375376317.99.0.429350247521.issue18617@psf.upfronthosting.co.za> Message-ID: <1398125658.05.0.461169474156.issue18617@psf.upfronthosting.co.za> Sam Vilain added the comment: Perhaps the simplest thing here is to add a standard verify callback that catches verification errors, and returns the parsed server certificate as an attribute of the raised exception object. From python, the exception can be caught and then the certificate data info used to fetch the intermediate certificate, and pass it into SSLContext.load_verify_locations(). This would force an extra client connection, but be less insane than trying to fetch and return the certificate from inside the SSL_CTX_set_verify() callback IMHO. Does that sound workable? Any hints for a would-be drive-by patcher? ---------- nosy: +samv versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 02:51:05 2014 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 22 Apr 2014 00:51:05 +0000 Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS In-Reply-To: <1398112908.13.0.755730209999.issue18967@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: Folks, this is *really, really, simple*: one file per NEWS entry. How we arrange them is just a detail. Don't go off trying to invent wild exotic alternatives that spread state across multiple sources of truth - significant historical info belongs in the version control system, and NEWS entries are how we highlight "this one is significant" (relative to other commits). A hg extension that prepopulates the commit message from a NEWS entry included in the patch wouldn't be difficult (especially since some of the Mercurial devs are likely to join the new core workflow list). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 04:04:33 2014 From: report at bugs.python.org (karl) Date: Tue, 22 Apr 2014 02:04:33 +0000 Subject: [issue21325] Missing Generic EXIF library for images in the standard library Message-ID: <1398132273.77.0.903866563155.issue21325@psf.upfronthosting.co.za> New submission from karl: There is a room for a consistent and good EXIF library for the Python Standard Library. ---------- components: Library (Lib) messages: 216978 nosy: karlcow priority: normal severity: normal status: open title: Missing Generic EXIF library for images in the standard library type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 04:13:21 2014 From: report at bugs.python.org (Giampaolo Rodola') Date: Tue, 22 Apr 2014 02:13:21 +0000 Subject: [issue17552] socket.sendfile() In-Reply-To: <1364326073.47.0.699222209849.issue17552@psf.upfronthosting.co.za> Message-ID: <1398132801.2.0.998358929348.issue17552@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: > Instead of returning [...] you could specify `no_fallback=False` that > could be set to `True` to assert that the fallback is not used > [...] and return the number of bytes sent. Good idea, thanks, that is much better indeed. Updated patch is in attachment. > [...] file.tell() may be changed by something else that uses > the same file descriptor? What happens if the file grows? I would say that is a use case we should explicitly not support as it probably implies you're doing something you're not supposed to. > If possible always include the number of bytes sent in any error that is raised. That's similar to my recent (rejected) proposal for socket.sendall(): https://mail.python.org/pipermail/python-ideas/2014-April/027689.html IMO the patch as it stands is fine as you can determine the number of bytes which were sent either by using the function return value or file.tell() (in case of error). Also, updating the file offset on exit makes the sendfile() implementation behave exactly like send(). ---------- Added file: http://bugs.python.org/file34997/socket-sendfile4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 04:19:46 2014 From: report at bugs.python.org (Giampaolo Rodola') Date: Tue, 22 Apr 2014 02:19:46 +0000 Subject: [issue17552] socket.sendfile() In-Reply-To: <1364326073.47.0.699222209849.issue17552@psf.upfronthosting.co.za> Message-ID: <1398133186.62.0.722261247838.issue17552@psf.upfronthosting.co.za> Changes by Giampaolo Rodola' : ---------- nosy: +josiah.carlson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 05:05:51 2014 From: report at bugs.python.org (koobs) Date: Tue, 22 Apr 2014 03:05:51 +0000 Subject: [issue20901] test_sqlite fails with SQLite 3.8.4 In-Reply-To: <1394661104.86.0.58139727656.issue20901@psf.upfronthosting.co.za> Message-ID: <1398135951.71.0.801461715109.issue20901@psf.upfronthosting.co.za> koobs added the comment: Updating versions to match branches fix was committed in ---------- nosy: +koobs versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 05:30:20 2014 From: report at bugs.python.org (Kushal Das) Date: Tue, 22 Apr 2014 03:30:20 +0000 Subject: [issue21256] Sort keyword arguments in mock _format_call_signature In-Reply-To: <1397666226.17.0.060483995874.issue21256@psf.upfronthosting.co.za> Message-ID: <1398137420.45.0.768988532124.issue21256@psf.upfronthosting.co.za> Kushal Das added the comment: New patch with test and news entry. ---------- Added file: http://bugs.python.org/file34998/issue21256_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 05:31:54 2014 From: report at bugs.python.org (Martin Panter) Date: Tue, 22 Apr 2014 03:31:54 +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: <1398137514.95.0.700980870513.issue21228@psf.upfronthosting.co.za> Martin Panter added the comment: I interpreted it more along the lines of ?. . . returns a http.client.HTTPResponse object [with] the following [additional] methods.? Indeed, a HTTP urlopen() response I just tried does have info(), geturl() and getcode() methods, and I know the info() method is used in the real world. Also, it would be good to document that the HTTP response?s ?msg? attribute does not actually hold the header, despite the HTTPResponse documentation. Further, the return value of BaseHandler.default_open() is defined to be the same as urlopen(), but when a HTTP error occurs I have found the ?msg? attribute is meant to be the HTTP status text phrase (e.g. ?Not Found?). Perhaps it would be good to add something like these two points wherever they belong: * The ?msg? attribute returned by urlopen() does not hold the HTTP header, despite the ?HTTPResponse? documentation * The ?msg? attribute should be set to the HTTP status text phrase (HTTPResponse.reason) ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 06:24:31 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 22 Apr 2014 04:24:31 +0000 Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za> Message-ID: <1398140671.13.0.845140862889.issue18967@psf.upfronthosting.co.za> Terry J. Reedy added the comment: My concern with a file for each entry is a possible slowdown of some operations, like TortoiseHg resyncing the diff between repository and working directory (it is not instantaneous even now). However, if there are multiple directories and if they are emptied periodically, so that there are never more than a few hundred in any directory, it might not be too bad. I agree that this idea is otherwise an improvement. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 06:34:31 2014 From: report at bugs.python.org (Martin Panter) Date: Tue, 22 Apr 2014 04:34:31 +0000 Subject: [issue21044] tarfile does not handle file .name being an int In-Reply-To: <1395624777.51.0.277506799413.issue21044@psf.upfronthosting.co.za> Message-ID: <1398141271.58.0.566913183651.issue21044@psf.upfronthosting.co.za> Martin Panter added the comment: I ran into a related issue with the gettarinfo() method. Would that fall under the scope of this bug, or should I raise a separate one? >>> with tarfile.open("/dev/null", "w") as tar: ... with open(b"/bin/sh", "rb") as file: ... tar.gettarinfo(fileobj=file) ... Traceback (most recent call last): File "", line 3, in File "/usr/lib/python3.4/tarfile.py", line 1768, in gettarinfo arcname = arcname.replace(os.sep, "/") TypeError: expected bytes, bytearray or buffer compatible object I realise that making TarInfo object with a byte string or integer as a file name is not a good idea. Perhaps the documentation should explicitly say that ?fileobj.name? must be a real unencoded file name string unless ?arcname? is also given. In my particular case I added arcname="", because my code generates the proper file name later on. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 07:12:43 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 22 Apr 2014 05:12:43 +0000 Subject: [issue21284] IDLE reformat tests fail in presence of non-default FormatParagraph setting In-Reply-To: <1397747979.02.0.575213731893.issue21284@psf.upfronthosting.co.za> Message-ID: <3gCXwB1pqcz7LjY@mail.python.org> Roundup Robot added the comment: New changeset 4ff2c0a637cf by Terry Jan Reedy in branch '2.7': Issue 21284: Idle: make test_formatparagraph pass even when a user changes the http://hg.python.org/cpython/rev/4ff2c0a637cf New changeset fe067339af80 by Terry Jan Reedy in branch '3.4': Issue 21284: Idle: make test_formatparagraph pass even when a user changes the http://hg.python.org/cpython/rev/fe067339af80 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 07:13:27 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 22 Apr 2014 05:13:27 +0000 Subject: [issue21284] IDLE reformat tests fail in presence of non-default FormatParagraph setting In-Reply-To: <1397747979.02.0.575213731893.issue21284@psf.upfronthosting.co.za> Message-ID: <1398143607.77.0.882562846875.issue21284@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 07:17:09 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 22 Apr 2014 05:17:09 +0000 Subject: [issue21139] Idle: change default reformat width from 70 to 72 In-Reply-To: <1396492163.57.0.51526901235.issue21139@psf.upfronthosting.co.za> Message-ID: <1398143829.22.0.0293968622637.issue21139@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I applied my patch as part of #21284. When I did so, I added 'limit=70' so that the tests pass otherwise unchanged. The only thing left here is to change config-main.def. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 07:28:09 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 22 Apr 2014 05:28:09 +0000 Subject: [issue21138] mimetypes.MimeType UnicodeDecodeError In-Reply-To: <1396489160.22.0.410580562036.issue21138@psf.upfronthosting.co.za> Message-ID: <3gCYG05qTxz7LjY@mail.python.org> Roundup Robot added the comment: New changeset 374746c5dedc by Terry Jan Reedy in branch '2.7': Issue #21138: Change default reformat paragraph width to PEP 8's 72. http://hg.python.org/cpython/rev/374746c5dedc New changeset dd24099c0cf6 by Terry Jan Reedy in branch '3.4': Issue #21138: Change default reformat paragraph width to PEP 8's 72. http://hg.python.org/cpython/rev/dd24099c0cf6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 07:30:13 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 22 Apr 2014 05:30:13 +0000 Subject: [issue21138] mimetypes.MimeType UnicodeDecodeError In-Reply-To: <1396489160.22.0.410580562036.issue21138@psf.upfronthosting.co.za> Message-ID: <1398144613.96.0.984187673362.issue21138@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The unlinked push message was for #21139. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 07:30:35 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 22 Apr 2014 05:30:35 +0000 Subject: [issue21138] mimetypes.MimeType UnicodeDecodeError In-Reply-To: <1396489160.22.0.410580562036.issue21138@psf.upfronthosting.co.za> Message-ID: <1398144635.11.0.576748768553.issue21138@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- Removed message: http://bugs.python.org/msg216987 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 07:33:30 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 22 Apr 2014 05:33:30 +0000 Subject: [issue21139] Idle: change default reformat width from 70 to 72 In-Reply-To: <1396492163.57.0.51526901235.issue21139@psf.upfronthosting.co.za> Message-ID: <1398144810.84.0.0519188566731.issue21139@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I put 21138 in the commit message. The push messages are these. New changeset 374746c5dedc by Terry Jan Reedy in branch '2.7': Issue #21138: Change default reformat paragraph width to PEP 8's 72. http://hg.python.org/cpython/rev/374746c5dedc New changeset dd24099c0cf6 by Terry Jan Reedy in branch '3.4': Issue #21138: Change default reformat paragraph width to PEP 8's 72. http://hg.python.org/cpython/rev/dd24099c0cf6 ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 08:33:18 2014 From: report at bugs.python.org (paul j3) Date: Tue, 22 Apr 2014 06:33:18 +0000 Subject: [issue9338] argparse optionals with nargs='?', '*' or '+' can't be followed by positionals In-Reply-To: <1279881989.28.0.725806934086.issue9338@psf.upfronthosting.co.za> Message-ID: <1398148398.15.0.628352017295.issue9338@psf.upfronthosting.co.za> paul j3 added the comment: http://bugs.python.org/issue15112 breaks one test that I added to issue +class TestPositionalsAfterOptionalsPlus(ParserTestCase): + """Tests specifying a positional that follows an arg with nargs=+ + http://bugs.python.org/issue9338#msg111270 + prototypical problem""" + + argument_signatures = [ + Sig('-w'), + Sig('-x', nargs='+'), + Sig('y', type=int), + Sig('z', nargs='*', type=int)] + failures = ['1 -x 2 3 -w 4 5 6' # error: unrecognized arguments: 5 6 + # z consumed in 1st argument group '1' + ] This no longer fails. Due to 15112, z=[5,6]. That is, it is no longer consumed by the 1st argument group. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 08:47:14 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 22 Apr 2014 06:47:14 +0000 Subject: [issue6305] islice doesn't accept large stop values In-Reply-To: <1245309263.43.0.625809679675.issue6305@psf.upfronthosting.co.za> Message-ID: <1398149234.56.0.990475194257.issue6305@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The first patch was cleaner. I don't think it is necessary to start-fast and switch-to-slow in the case where not all of the arguments are in the normal range. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 08:58:12 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 22 Apr 2014 06:58:12 +0000 Subject: [issue21321] itertools.islice() doesn't release reference to the source iterator when the slice is exhausted In-Reply-To: <1398082430.51.0.59207810702.issue21321@psf.upfronthosting.co.za> Message-ID: <1398149892.54.0.642128235077.issue21321@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The ref-counts in the islice_reduce code don't look to be correct at first glance. ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 09:50:23 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 22 Apr 2014 07:50:23 +0000 Subject: [issue21320] dict() allows keyword expansion with integer keys, e.g. dict(**{5:'v'}) In-Reply-To: <1398081299.38.0.288058317096.issue21320@psf.upfronthosting.co.za> Message-ID: <1398153023.07.0.314420511069.issue21320@psf.upfronthosting.co.za> Raymond Hettinger added the comment: IIRC, we've only created -3 warnings for things that would be incorrectly accepted by Python 3 (such as floor division using /). I don't think that applies here and isn't worth monkeying with Py2.7. It goes in the harmless nuisance category, something that affects almost no one. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 10:12:43 2014 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 22 Apr 2014 08:12:43 +0000 Subject: [issue21326] asyncio: request clearer error message when event loop closed Message-ID: <1398154363.0.0.853788262895.issue21326@psf.upfronthosting.co.za> New submission from Mark Dickinson: In the new asyncio library, it's easy for newbies (like me) to accidentally try to run a coroutine on a closed event loop. Doing so leads to a rather inscrutable exception and traceback: >>> loop.run_until_complete(compute()) Traceback (most recent call last): File "", line 1, in File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/asyncio/base_events.py", line 203, in run_until_complete self.run_forever() File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/asyncio/base_events.py", line 184, in run_forever self._run_once() File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/asyncio/base_events.py", line 778, in _run_once event_list = self._selector.select(timeout) AttributeError: 'NoneType' object has no attribute 'select' Is it possible to replace this with something clearer? For example, something like: RuntimeError("Can't schedule coroutine on closed event loop.") Here's the full code snippet: Python 3.4.0 (default, Mar 25 2014, 11:07:05) [GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.38)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import asyncio >>> @asyncio.coroutine ... def compute(): ... print("Starting computation") ... yield from asyncio.sleep(2.0) ... print("Complete") ... >>> loop = asyncio.get_event_loop() >>> loop.run_until_complete(compute()) Starting computation Complete >>> loop.close() # whoops >>> # some time later ... >>> loop = asyncio.get_event_loop() >>> loop.run_until_complete(compute()) Traceback (most recent call last): File "", line 1, in File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/asyncio/base_events.py", line 203, in run_until_complete self.run_forever() File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/asyncio/base_events.py", line 184, in run_forever self._run_once() File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/asyncio/base_events.py", line 778, in _run_once event_list = self._selector.select(timeout) AttributeError: 'NoneType' object has no attribute 'select' ---------- components: Library (Lib) messages: 216994 nosy: gvanrossum, mark.dickinson priority: normal severity: normal stage: needs patch status: open title: asyncio: request clearer error message when event loop closed type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 11:29:01 2014 From: report at bugs.python.org (=?utf-8?q?I=C3=B1igo_Serna?=) Date: Tue, 22 Apr 2014 09:29:01 +0000 Subject: [issue21322] Pathlib .owner() and .group() methods fail on broken links In-Reply-To: <1398098569.86.0.723629898468.issue21322@psf.upfronthosting.co.za> Message-ID: <1398158941.93.0.216279129515.issue21322@psf.upfronthosting.co.za> I?igo Serna added the comment: Mainly, 2 reasons: - It can make programs crash *unexpectedly* - Pathlib should provide a complete and uniform API for dealing with all types of files. If not, users would need to use Pathlib for some kind of files and go to os and os.path for others, then why the reason to use Pathlib? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 11:33:44 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 22 Apr 2014 09:33:44 +0000 Subject: [issue21322] Pathlib .owner() and .group() methods fail on broken links In-Reply-To: <1398158941.93.0.216279129515.issue21322@psf.upfronthosting.co.za> Message-ID: <1398159221.2288.3.camel@fsol> Antoine Pitrou added the comment: > - It can make programs crash *unexpectedly* A broken link is an error, so it's normal to have an exception raised here. An exception can always be caught if you were expecting the error. > - Pathlib should provide a complete and uniform API for dealing with > all types of files. If not, users would need to use Pathlib for some > kind of files and go to os and os.path for others, then why the reason > to use Pathlib? I sympathize with this. But you can already use Path.lstat() and inspect the st_uid and st_gid fields if you are really interested in the link's owner and group (rather than the target's). The fact that most Path methods dereference symlinks reflects the semantics of other common filesystem calls (such as those in the os module, or the underlying functions of the POSIX API). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 12:52:43 2014 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 22 Apr 2014 10:52:43 +0000 Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS In-Reply-To: Message-ID: <535649F9.5010307@egenix.com> Marc-Andre Lemburg added the comment: FWIW: I don't think we need to manage the news entries in the NEWS file. Instead, we could simply add a field to the bug tracker called "news entry" and populate that as necessary. During release, this information can then be used to create a NEWS file per release. This file would not be touched by anyone other then the release manager. As a result, there would not longer be any merge conflicts, and the news entries can still be changed before the release if necessary, and, of course, the generated NEWS file can also be edited as the release manager sees fit. Tickets which do not need a news entry simply leave the news entry field blank. We really don't need a file system database for these things. (PS: eGenix has been using such a system internally for several years and it works great.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 12:53:17 2014 From: report at bugs.python.org (Michael Foord) Date: Tue, 22 Apr 2014 10:53:17 +0000 Subject: [issue21256] Sort keyword arguments in mock _format_call_signature In-Reply-To: <1397666226.17.0.060483995874.issue21256@psf.upfronthosting.co.za> Message-ID: <1398163997.06.0.816884850419.issue21256@psf.upfronthosting.co.za> Michael Foord added the comment: I agree with Antoine's review comments. With those changes in place, ok to commit. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 13:55:07 2014 From: report at bugs.python.org (Giampaolo Rodola') Date: Tue, 22 Apr 2014 11:55:07 +0000 Subject: [issue21327] socket.type value changes after using settimeout() Message-ID: <1398167707.44.0.251945553674.issue21327@psf.upfronthosting.co.za> New submission from Giampaolo Rodola': >>> s = socket.socket() >>> s.type >>> s.settimeout(2) >>> s.type 2049 >>> I can reproduce this with Python 3.5, 3.4 and 3.3. 2.7 is not affected. ---------- messages: 216999 nosy: giampaolo.rodola priority: normal severity: normal status: open title: socket.type value changes after using settimeout() versions: Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 14:09:31 2014 From: report at bugs.python.org (Giampaolo Rodola') Date: Tue, 22 Apr 2014 12:09:31 +0000 Subject: [issue21327] socket.type value changes after using settimeout() In-Reply-To: <1398167707.44.0.251945553674.issue21327@psf.upfronthosting.co.za> Message-ID: <1398168571.61.0.891946057061.issue21327@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: It seems this was introduced in issue 7523 / revision 12442ac3f7dd. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 14:27:15 2014 From: report at bugs.python.org (Giampaolo Rodola') Date: Tue, 22 Apr 2014 12:27:15 +0000 Subject: [issue21327] socket.type value changes after using settimeout() In-Reply-To: <1398167707.44.0.251945553674.issue21327@psf.upfronthosting.co.za> Message-ID: <1398169635.4.0.126957853731.issue21327@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: Generally speaking I think it's fine to have this behavior only if the socket object is instantiated like this: >>> s = socket.socket(type=socket.SOCK_STREAM | socket.SOCK_NONBLOCK) >>> s.type 2049 ...but when it comes to using setblocking() I would not expect that to happen (it's not cross platform). Sounds reasonable? ---------- nosy: +BreamoreBoy, exarkun, lekma, nvetoshkin, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 14:27:54 2014 From: report at bugs.python.org (Giampaolo Rodola') Date: Tue, 22 Apr 2014 12:27:54 +0000 Subject: [issue21327] socket.type value changes after using settimeout() In-Reply-To: <1398167707.44.0.251945553674.issue21327@psf.upfronthosting.co.za> Message-ID: <1398169674.97.0.0831686490072.issue21327@psf.upfronthosting.co.za> Changes by Giampaolo Rodola' : ---------- Removed message: http://bugs.python.org/msg217001 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 14:28:09 2014 From: report at bugs.python.org (Giampaolo Rodola') Date: Tue, 22 Apr 2014 12:28:09 +0000 Subject: [issue21327] socket.type value changes after using settimeout() In-Reply-To: <1398167707.44.0.251945553674.issue21327@psf.upfronthosting.co.za> Message-ID: <1398169689.46.0.74103570274.issue21327@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: Generally speaking I think it's fine to have this behavior only if the socket object is instantiated like this: >>> s = socket.socket(type=socket.SOCK_STREAM | socket.SOCK_NONBLOCK) >>> s.type 2049 ...but when it comes to using settimeout() I would not expect that to happen (it's not cross platform). Sounds reasonable? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 15:54:16 2014 From: report at bugs.python.org (Alok Singhal) Date: Tue, 22 Apr 2014 13:54:16 +0000 Subject: [issue6305] islice doesn't accept large stop values In-Reply-To: <1245309263.43.0.625809679675.issue6305@psf.upfronthosting.co.za> Message-ID: <1398174856.81.0.572182157194.issue6305@psf.upfronthosting.co.za> Alok Singhal added the comment: OK. Here is the first patch with a couple of bug fixes for "slow mode". ---------- Added file: http://bugs.python.org/file34999/islice_large_values-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 15:57:12 2014 From: report at bugs.python.org (Alexei Mozhaev) Date: Tue, 22 Apr 2014 13:57:12 +0000 Subject: [issue20147] multiprocessing.Queue.get() raises queue.Empty exception if even if an item is available In-Reply-To: <1389022210.55.0.898891193549.issue20147@psf.upfronthosting.co.za> Message-ID: <1398175032.91.0.639471099228.issue20147@psf.upfronthosting.co.za> Alexei Mozhaev added the comment: We have a similar bug with Queue.get(). Queue.get(False) raises an exception Queue.Empty in the case when the queue is actually not empty! An example of the code is attached and is listed below just in case: ---------------------- import multiprocessing import Queue class TestWorker(multiprocessing.Process): def __init__(self, inQueue): multiprocessing.Process.__init__(self) self.inQueue = inQueue def run(self): while True: try: task = self.inQueue.get(False) except Queue.Empty: # I suppose that Queue.Empty exception is about empty queue # and self.inQueue.empty() must be true in this case # try to check it using assert assert self.inQueue.empty() break def runTest(): queue = multiprocessing.Queue() for _ in xrange(10**5): queue.put(1) workers = [TestWorker(queue) for _ in xrange(4)] map(lambda w: w.start(), workers) map(lambda w: w.join(), workers) if __name__ == "__main__": runTest() ---------------------- ---------- nosy: +Alexei.Mozhaev versions: -Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file35000/py_mult_queue_bug.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 16:02:29 2014 From: report at bugs.python.org (Dustin Oprea) Date: Tue, 22 Apr 2014 14:02:29 +0000 Subject: [issue21328] Resize doesn't change reported length on create_string_buffer() Message-ID: <1398175349.63.0.548870170471.issue21328@psf.upfronthosting.co.za> New submission from Dustin Oprea: The memory is resized, but the value returned by len() doesn't change: >>> b = ctypes.create_string_buffer(23) >>> len(b) 23 >>> b.raw = '0' * 23 >>> b.raw = '0' * 24 Traceback (most recent call last): File "", line 1, in ValueError: string too long >>> ctypes.resize(b, 28) >>> len(b) 23 >>> b.raw = '0' * 28 >>> b.raw = '0' * 29 Traceback (most recent call last): File "", line 1, in ValueError: string too long ---------- components: ctypes messages: 217005 nosy: Dustin.Oprea priority: normal severity: normal status: open title: Resize doesn't change reported length on create_string_buffer() versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 16:15:43 2014 From: report at bugs.python.org (Michael Foord) Date: Tue, 22 Apr 2014 14:15:43 +0000 Subject: [issue21255] Attaching a PropertyMock records calls In-Reply-To: <1397665155.65.0.579203534798.issue21255@psf.upfronthosting.co.za> Message-ID: <1398176143.06.0.0130630361244.issue21255@psf.upfronthosting.co.za> Michael Foord added the comment: Not sure, but I guess it would be easy to find out. It will need some digging into to find out where the actual bug is. It shouldn't be hard to find though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 16:33:10 2014 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 22 Apr 2014 14:33:10 +0000 Subject: [issue21326] asyncio: request clearer error message when event loop closed In-Reply-To: <1398154363.0.0.853788262895.issue21326@psf.upfronthosting.co.za> Message-ID: <1398177190.89.0.837362173816.issue21326@psf.upfronthosting.co.za> Guido van Rossum added the comment: Hm, I've never hear from someone who did this before. It might be easy to fix, but it would be ugly too (every EventLoop method would have to check this), and not very useful (you'll only make this mistake once in your life). How much time did you waste debugging this? Maybe we can just change repr(loop) to make it clear that it's closed? ---------- priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 16:44:53 2014 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 22 Apr 2014 14:44:53 +0000 Subject: [issue21326] asyncio: request clearer error message when event loop closed In-Reply-To: <1398154363.0.0.853788262895.issue21326@psf.upfronthosting.co.za> Message-ID: <1398177893.69.0.431047714879.issue21326@psf.upfronthosting.co.za> Mark Dickinson added the comment: > How much time did you waste debugging this? Not much: less than 5 minutes. While I *probably* won't make this mistake again (though I'm not going to make any promises on that front), it would be nice to prevent other people from doing so. More info: I got to the issue by randomly pasting examples from the asyncio docs, one of which had a `.close` call in, without taking the time to read and understand those docs properly first - I was keen to get to the coroutine part of it and didn't want to spend time on the event loop details. Without having thought about it, I wasn't expecting the result of `get_event_loop` to be a singleton; once I figured that bit out it was clear what was going on. So yes, stupidity on my part. I'd like to bet that I won't be the only person who runs into this, though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 16:45:48 2014 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 22 Apr 2014 14:45:48 +0000 Subject: [issue21326] asyncio: request clearer error message when event loop closed In-Reply-To: <1398154363.0.0.853788262895.issue21326@psf.upfronthosting.co.za> Message-ID: <1398177948.29.0.286095615163.issue21326@psf.upfronthosting.co.za> Mark Dickinson added the comment: > Maybe we can just change repr(loop) to make it clear that it's closed? That sounds good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 16:49:17 2014 From: report at bugs.python.org (Tim Golden) Date: Tue, 22 Apr 2014 14:49:17 +0000 Subject: [issue21138] mimetypes.MimeType UnicodeDecodeError In-Reply-To: <1396489160.22.0.410580562036.issue21138@psf.upfronthosting.co.za> Message-ID: <1398178157.22.0.748235784473.issue21138@psf.upfronthosting.co.za> Tim Golden added the comment: This looks like a duplicate of issue9291; could you test the latest patch over there, please? ---------- assignee: -> tim.golden nosy: +tim.golden _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 16:57:51 2014 From: report at bugs.python.org (Brett Cannon) Date: Tue, 22 Apr 2014 14:57:51 +0000 Subject: [issue21325] Missing Generic EXIF library for images in the standard library In-Reply-To: <1398132273.77.0.903866563155.issue21325@psf.upfronthosting.co.za> Message-ID: <1398178671.83.0.986244453915.issue21325@psf.upfronthosting.co.za> Brett Cannon added the comment: A guide on how to get a module added to the stdlib can be found at https://docs.python.org/devguide/stdlibchanges.html#adding-a-new-module , although I think an EXIF module is going to be too niche to ever be accepted. ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 17:27:33 2014 From: report at bugs.python.org (=?utf-8?q?Dani=C3=ABl_van_Eeden?=) Date: Tue, 22 Apr 2014 15:27:33 +0000 Subject: [issue21329] configparser can't parse MySQL style config Message-ID: <1398180453.28.0.0252275500481.issue21329@psf.upfronthosting.co.za> New submission from Dani?l van Eeden: With Python 2.7 the ConfigParser was enriched with the allow_no_value option which resulted in a much more usable configparser for MySQL configs. It can now parse configs like this: [mysqld] log_bin innodb_file_per_table innodb_io_capacity=800 However it can't parse this config: [mysqld] log_bin innodb_file_per_table innodb_io_capacity=800 replicate-do-db="test1" replicate-do-db="test2" A comma separated config might have been better, but that's not the case with many MySQL config (and probably doesn't even work for this option). >From http://dev.mysql.com/doc/refman/5.6/en/replication-options-slave.html#option_mysqld_replicate-do-db "To specify more than one database, use this option multiple times, once for each database" The dict/orderedDict which is used by configparser doesn't easlily allow to store a config like this. The MySQL config file is used as an example in the documentation: https://docs.python.org/3/library/configparser.html#customizing-parser-behaviour This could be solved by having a list of values if the key exists more than once. Python 3 improves this a bit by giving a DuplicateOptionError by default. ---------- components: Library (Lib) files: demo.py messages: 217012 nosy: dveeden priority: normal severity: normal status: open title: configparser can't parse MySQL style config versions: Python 3.4 Added file: http://bugs.python.org/file35001/demo.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 17:49:37 2014 From: report at bugs.python.org (Zachary Ware) Date: Tue, 22 Apr 2014 15:49:37 +0000 Subject: [issue21303] Python 2.7 Spinbox Format Behaves Differently On Windows Versus Linux In-Reply-To: <1397853102.02.0.000549588678959.issue21303@psf.upfronthosting.co.za> Message-ID: <1398181777.69.0.197181670925.issue21303@psf.upfronthosting.co.za> Zachary Ware added the comment: 8.5.15 sounds good to me; here's the patch to 2.7 once the 8.5.15 sources are on svn.python.org as tcl-8.5.15.0 and tk-8.5.15.0, no modifications necessary. ---------- keywords: +patch Added file: http://bugs.python.org/file35002/issue21303-2.7-tcl-upgrade.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 18:12:26 2014 From: report at bugs.python.org (Berker Peksag) Date: Tue, 22 Apr 2014 16:12:26 +0000 Subject: [issue21328] Resize doesn't change reported length on create_string_buffer() In-Reply-To: <1398175349.63.0.548870170471.issue21328@psf.upfronthosting.co.za> Message-ID: <1398183146.18.0.0804196542008.issue21328@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 18:52:50 2014 From: report at bugs.python.org (Anton Afanasyev) Date: Tue, 22 Apr 2014 16:52:50 +0000 Subject: [issue21321] itertools.islice() doesn't release reference to the source iterator when the slice is exhausted In-Reply-To: <1398082430.51.0.59207810702.issue21321@psf.upfronthosting.co.za> Message-ID: <1398185570.54.0.205219011483.issue21321@psf.upfronthosting.co.za> Anton Afanasyev added the comment: Hi Raymond, do you mean allocation exceptions handling should be more accurate? Attaching fixed version for 3.4 branch. ---------- Added file: http://bugs.python.org/file35003/issue21321_3.4_8c8315bac6a8_2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 19:47:58 2014 From: report at bugs.python.org (Ned Deily) Date: Tue, 22 Apr 2014 17:47:58 +0000 Subject: [issue20147] multiprocessing.Queue.get() raises queue.Empty exception if even if an item is available In-Reply-To: <1389022210.55.0.898891193549.issue20147@psf.upfronthosting.co.za> Message-ID: <1398188878.98.0.0432231711602.issue20147@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 19:49:45 2014 From: report at bugs.python.org (Giampaolo Rodola') Date: Tue, 22 Apr 2014 17:49:45 +0000 Subject: [issue17552] socket.sendfile() In-Reply-To: <1364326073.47.0.699222209849.issue17552@psf.upfronthosting.co.za> Message-ID: <1398188985.97.0.436309259821.issue17552@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: Yet another patch fixing some problems on Windows. Hopefully this should be the last one as for what concerns the POSIX systems. As such I would kindly ask for a review and/or further suggestions. ---------- Added file: http://bugs.python.org/file35004/sendfile5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 19:52:03 2014 From: report at bugs.python.org (Ned Deily) Date: Tue, 22 Apr 2014 17:52:03 +0000 Subject: [issue21329] configparser can't parse MySQL style config In-Reply-To: <1398180453.28.0.0252275500481.issue21329@psf.upfronthosting.co.za> Message-ID: <1398189123.44.0.0609085439804.issue21329@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +lukasz.langa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 21:18:51 2014 From: report at bugs.python.org (Jayanth Raman) Date: Tue, 22 Apr 2014 19:18:51 +0000 Subject: [issue21330] Typo in "Unicode HOWTO" documentation Message-ID: <1398194331.3.0.966698777318.issue21330@psf.upfronthosting.co.za> New submission from Jayanth Raman: It should be "128 such characters" in the following sentence: For example, you can?t fit both the accented characters used in Western Europe and the Cyrillic alphabet used for Russian into the 128-255 range because there are more than 127 such characters. ---------- assignee: docs at python components: Documentation messages: 217016 nosy: docs at python, jayanth priority: normal severity: normal status: open title: Typo in "Unicode HOWTO" documentation type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 21:30:36 2014 From: report at bugs.python.org (Mike Mazurek) Date: Tue, 22 Apr 2014 19:30:36 +0000 Subject: [issue7511] msvc9compiler.py: ValueError when trying to compile with VC Express In-Reply-To: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za> Message-ID: <1398195036.4.0.157891832174.issue7511@psf.upfronthosting.co.za> Mike Mazurek added the comment: In building pycrypto for python 3.4 I applied patch msvccompiler9_33.diff. After applying the patch there is an unassigned variable: KEY_BASE on line 67 of the patched file. After setting KEY_BASE = "Software\\Wow6432Node\\Microsoft\\" before its first use I was able to successfully build pycrypto. ---------- nosy: +mike.mazurek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 22:05:30 2014 From: report at bugs.python.org (Forest Bond) Date: Tue, 22 Apr 2014 20:05:30 +0000 Subject: [issue6721] Locks in python standard library should be sanitized on fork In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za> Message-ID: <1398197129.99.0.436290260384.issue6721@psf.upfronthosting.co.za> Changes by Forest Bond : ---------- nosy: +forest_atq _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 22:36:48 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 22 Apr 2014 20:36:48 +0000 Subject: [issue21303] Python 2.7 Spinbox Format Behaves Differently On Windows Versus Linux In-Reply-To: <1397853102.02.0.000549588678959.issue21303@psf.upfronthosting.co.za> Message-ID: <3gCxQS1Jw5z7LjZ@mail.python.org> Roundup Robot added the comment: New changeset 2b8d9276ad5b by Zachary Ware in branch '2.7': Issue #21303, #20565: Updated the version of Tcl/Tk used on Windows http://hg.python.org/cpython/rev/2b8d9276ad5b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 22:36:49 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 22 Apr 2014 20:36:49 +0000 Subject: [issue20565] Update Tcl/Tk version for buildbots In-Reply-To: <1391883994.31.0.277087136027.issue20565@psf.upfronthosting.co.za> Message-ID: <3gCxQS6jCjz7LjZ@mail.python.org> Roundup Robot added the comment: New changeset 2b8d9276ad5b by Zachary Ware in branch '2.7': Issue #21303, #20565: Updated the version of Tcl/Tk used on Windows http://hg.python.org/cpython/rev/2b8d9276ad5b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 22:42:22 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 22 Apr 2014 20:42:22 +0000 Subject: [issue21327] socket.type value changes after using settimeout() In-Reply-To: <1398167707.44.0.251945553674.issue21327@psf.upfronthosting.co.za> Message-ID: <1398199342.85.0.554483602393.issue21327@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I think distinguishing between the two situations would make the code yet more complicated (and fragile). It's a bit unfortunate that the `type` attribute has become a kitchen sink for disparate pieces of configuration. The fact that you are the first to complain though it was introduced in 3.2 does not make it very compelling to change the current behaviour, IMHO. ---------- nosy: +haypo, neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 22:58:23 2014 From: report at bugs.python.org (Sworddragon) Date: Tue, 22 Apr 2014 20:58:23 +0000 Subject: [issue21331] Reversing an encoding with unicode-escape returns a different result Message-ID: <1398200303.74.0.876201125787.issue21331@psf.upfronthosting.co.za> New submission from Sworddragon: I have made some tests with encoding/decoding in conjunction with unicode-escape and got some strange results: >>> print('?') ? >>> print('?'.encode('utf-8')) b'\xc3\xa4' >>> print('?'.encode('utf-8').decode('unicode-escape')) ?? >>> print('?'.encode('utf-8').decode('unicode-escape').encode('unicode-escape')) b'\\xc3\\xa4' >>> print('?'.encode('utf-8').decode('unicode-escape').encode('unicode-escape').decode('utf-8')) \xc3\xa4 Shouldn't .decode('unicode-escape').encode('unicode-escape') nullify itself and so "'?'.encode('utf-8').decode('unicode-escape').encode('unicode-escape')" return the same result as '?'.encode('utf-8')? ---------- components: Unicode messages: 217021 nosy: Sworddragon, ezio.melotti, haypo priority: normal severity: normal status: open title: Reversing an encoding with unicode-escape returns a different result type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 23:11:09 2014 From: report at bugs.python.org (Zachary Ware) Date: Tue, 22 Apr 2014 21:11:09 +0000 Subject: [issue21303] Python 2.7 Spinbox Format Behaves Differently On Windows Versus Linux In-Reply-To: <1397853102.02.0.000549588678959.issue21303@psf.upfronthosting.co.za> Message-ID: <1398201069.62.0.644873846047.issue21303@psf.upfronthosting.co.za> Zachary Ware added the comment: Done. Michael, thanks for the report! ---------- assignee: -> zach.ware resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 23:13:12 2014 From: report at bugs.python.org (Zachary Ware) Date: Tue, 22 Apr 2014 21:13:12 +0000 Subject: [issue20565] Update Tcl/Tk version for buildbots In-Reply-To: <1391883994.31.0.277087136027.issue20565@psf.upfronthosting.co.za> Message-ID: <1398201192.8.0.389983603648.issue20565@psf.upfronthosting.co.za> Zachary Ware added the comment: 2.7 is now updated to 8.5.15, 3.3 is in security mode, and 3.4+ are on 8.6.1. ---------- nosy: +zach.ware resolution: -> fixed stage: -> resolved status: open -> closed versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 23:13:34 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 22 Apr 2014 21:13:34 +0000 Subject: [issue21331] Reversing an encoding with unicode-escape returns a different result In-Reply-To: <1398200303.74.0.876201125787.issue21331@psf.upfronthosting.co.za> Message-ID: <1398201214.63.0.957843269733.issue21331@psf.upfronthosting.co.za> R. David Murray added the comment: No. x.encode('unicode-escape').decode('unicode-escape') should return the same result, and it does. The bug, I think, is that bytes.decode('unicode-escape') is not objecting to the non-ascii characters. It appears to be treating them as latin1, and that strikes me as broken. ---------- nosy: +lemburg, ncoghlan, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 23:15:22 2014 From: report at bugs.python.org (Zachary Ware) Date: Tue, 22 Apr 2014 21:15:22 +0000 Subject: [issue20560] tkFileFilter.c: ostypeCount not initialized? In-Reply-To: <1391854471.94.0.0196154123534.issue20560@psf.upfronthosting.co.za> Message-ID: <1398201322.54.0.697302421392.issue20560@psf.upfronthosting.co.za> Zachary Ware added the comment: Terry, could you try this again with a fresh build of Tcl/Tk 8.5.15? Update your 2.7 to 2b8d9276ad5b or beyond and run Tools/buildbot/external.bat again, it should take care of it. ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 23:27:08 2014 From: report at bugs.python.org (Alex Gaynor) Date: Tue, 22 Apr 2014 21:27:08 +0000 Subject: [issue21306] PEP 466: backport hmac.compare_digest In-Reply-To: <1397868787.47.0.118679212536.issue21306@psf.upfronthosting.co.za> Message-ID: <1398202028.13.0.882150986754.issue21306@psf.upfronthosting.co.za> Alex Gaynor added the comment: Design question here: compare_digest on Python 3 supports comparing str (text) objects, if they're both ascii-only. This feature is provided, primarily, so you can compare hexdigests or similar. Should the Python 2 version support comparing unicodes? Arguments in favor: some amount of consistency. Against: it's not necessary because hexdigest is still a str (binary), further it's not actually posisble to replicate the ascii only semantic. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 23:30:06 2014 From: report at bugs.python.org (Donald Stufft) Date: Tue, 22 Apr 2014 21:30:06 +0000 Subject: [issue21306] PEP 466: backport hmac.compare_digest In-Reply-To: <1397868787.47.0.118679212536.issue21306@psf.upfronthosting.co.za> Message-ID: <1398202206.11.0.0403318533632.issue21306@psf.upfronthosting.co.za> Donald Stufft added the comment: try: data = data.encode("ascii") except UnicodeEncodeError: raise TypeError("comparing unicode with non-ASCII characters is not supported") ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 23:30:41 2014 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 22 Apr 2014 21:30:41 +0000 Subject: [issue21306] PEP 466: backport hmac.compare_digest In-Reply-To: <1398202028.13.0.882150986754.issue21306@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: 8-bit str only makes more sense to me. The wishy-washiness of some APIs in Py3 is mostly to work around porting issues where stuff that should have become bytes was left as str. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 23:31:20 2014 From: report at bugs.python.org (Alex Gaynor) Date: Tue, 22 Apr 2014 21:31:20 +0000 Subject: [issue21306] PEP 466: backport hmac.compare_digest In-Reply-To: <1397868787.47.0.118679212536.issue21306@psf.upfronthosting.co.za> Message-ID: <1398202280.55.0.867153825729.issue21306@psf.upfronthosting.co.za> Alex Gaynor added the comment: encode("ascii") has data dependent branches, so it's to be avoided. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 23:31:44 2014 From: report at bugs.python.org (Alex Gaynor) Date: Tue, 22 Apr 2014 21:31:44 +0000 Subject: [issue21306] PEP 466: backport hmac.compare_digest In-Reply-To: <1397868787.47.0.118679212536.issue21306@psf.upfronthosting.co.za> Message-ID: <1398202304.71.0.917981196863.issue21306@psf.upfronthosting.co.za> Alex Gaynor added the comment: Thanks Nick. I'll get a patch up for str (bytes) only this afternoon. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 23:40:54 2014 From: report at bugs.python.org (Donald Stufft) Date: Tue, 22 Apr 2014 21:40:54 +0000 Subject: [issue21306] PEP 466: backport hmac.compare_digest In-Reply-To: <1397868787.47.0.118679212536.issue21306@psf.upfronthosting.co.za> Message-ID: <1398202854.73.0.212097432636.issue21306@psf.upfronthosting.co.za> Donald Stufft added the comment: I'm not sure that the timing leakage in an encode is actually something to be worried about. I'm not sure what secret information would be getting leaked in a way that you could determine it by examining the timing. However I think the bigger thing is if I'm an app developer and I attempt to pass a unicode to hmac.compare_digest() and it tells me it only accepts bytes, the first thing I'm going to do is is .encode() it myself before I pass it in. IOW hmac.compare_digest could avoid the encode, but it's just pushing that back up to the user of hmac.compare_digest, who might possibly have a byte string laying around that they won't have to do the encode/decode dance on (although if they have a unicode they have already done it at least once), or they only have a unicode available to them then they'll be forced to do the encode themselves. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 23:51:36 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 22 Apr 2014 21:51:36 +0000 Subject: [issue21327] socket.type value changes after using settimeout() In-Reply-To: <1398199342.85.0.554483602393.issue21327@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: I would prefer to add something to get the type without SOCK_NONBLOCK nor SOCK_CLOEXEC. So new feature can only be added to Python 3.5. For older Python versions, you can to filter manually, which is difficult because you have yo check if SOCK_NONBLOCK and/or SOCK_CLOEXEC are available. You have the same issue in the C language. Anyway, all sockets are now created with SOCK_CLOEXEC since Python 3.4 because of the PEP 446 (cloexec). We can add a new .sock_type attribute. Or .type could be an object with attributes like: type (int/enum), cloexec, nonblock, etc. Or simply a short helper method can be added. Ex: socket.get_socket_type(sock) or socket.get_socket_type(sock.type). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 23:56:14 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 22 Apr 2014 21:56:14 +0000 Subject: [issue21331] Reversing an encoding with unicode-escape returns a different result In-Reply-To: <1398200303.74.0.876201125787.issue21331@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: unicode_escape codec is deprecated since Python 3.3. Please use UTF-8 or something else. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 22 23:59:12 2014 From: report at bugs.python.org (Joe Button) Date: Tue, 22 Apr 2014 21:59:12 +0000 Subject: [issue4913] wave.py: add writesamples() and readsamples() In-Reply-To: <1231640203.22.0.836631115229.issue4913@psf.upfronthosting.co.za> Message-ID: <1398203952.3.0.0529638675467.issue4913@psf.upfronthosting.co.za> Joe Button added the comment: Forgive my unfamiliarity with python's development process, but, what is happening with this? Is there any chance of this enhancement making it into the python libs? What would need to happen? Thanks. ---------- nosy: +Joeboy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 00:06:14 2014 From: report at bugs.python.org (Alex Gaynor) Date: Tue, 22 Apr 2014 22:06:14 +0000 Subject: [issue21306] PEP 466: backport hmac.compare_digest In-Reply-To: <1397868787.47.0.118679212536.issue21306@psf.upfronthosting.co.za> Message-ID: <1398204374.86.0.143671454046.issue21306@psf.upfronthosting.co.za> Alex Gaynor added the comment: Attached patch implements compare_digest. Code is mostly a 1-1 from 3.x, except the Unicode paths are changed, and the tests are a tiny bit different. * Still needs to backport the docs. * Compares all unicode objects, not just ascii ones. If the patch looks good to folks I'll add the docs as well. ---------- keywords: +patch Added file: http://bugs.python.org/file35005/compare_digest.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 00:17:35 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 22 Apr 2014 22:17:35 +0000 Subject: [issue4913] wave.py: add writesamples() and readsamples() In-Reply-To: <1231640203.22.0.836631115229.issue4913@psf.upfronthosting.co.za> Message-ID: <1398205055.54.0.894990372342.issue4913@psf.upfronthosting.co.za> R. David Murray added the comment: Someone has to find the time to do a commit review on the patch. As Guilherme said, there's no specific maintainer for wave, so I'm afraid it just got forgotten about. On the other hand, as a new feature it would now go in 3.5, and we're at the start of the approximately one year window for new features, so if you ping this issue (as you just did) periodically, someone will get to it ;) What you could do to help move it along is to do your own review of the patch, including making sure it still applies to default...which it may not, since there have in fact been some changes in wave.py. If that's the case you can also help by updating the patch. ---------- nosy: +r.david.murray stage: test needed -> patch review versions: +Python 3.5 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 00:17:55 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 22 Apr 2014 22:17:55 +0000 Subject: [issue21207] urandom persistent fd - not re-openned after fd close In-Reply-To: <1397316819.31.0.463593532744.issue21207@psf.upfronthosting.co.za> Message-ID: <1398205075.75.0.580241518009.issue21207@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Updated patch using an anonymous struct. ---------- Added file: http://bugs.python.org/file35006/urandom_fd_reopen2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 00:34:57 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 22 Apr 2014 22:34:57 +0000 Subject: [issue21127] Path objects cannot be constructed from str subclasses In-Reply-To: <1396390108.81.0.285327356985.issue21127@psf.upfronthosting.co.za> Message-ID: <3gD02n04hNz7LjW@mail.python.org> Roundup Robot added the comment: New changeset c24cbd9bd63b by Antoine Pitrou in branch '3.4': Issue #21127: Path objects can now be instantiated from str subclass instances (such as numpy.str_). http://hg.python.org/cpython/rev/c24cbd9bd63b New changeset aad6d6b819ed by Antoine Pitrou in branch 'default': Issue #21127: Path objects can now be instantiated from str subclass instances (such as numpy.str_). http://hg.python.org/cpython/rev/aad6d6b819ed ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 00:36:11 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 22 Apr 2014 22:36:11 +0000 Subject: [issue21127] Path objects cannot be constructed from str subclasses In-Reply-To: <1396390108.81.0.285327356985.issue21127@psf.upfronthosting.co.za> Message-ID: <1398206171.35.0.297738885841.issue21127@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok, I've committed a patch (to 3.4 and 3.5) that force-casts to str. Thank you for reporting this bug! ---------- resolution: -> fixed stage: -> resolved status: open -> closed type: -> behavior versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 00:54:18 2014 From: report at bugs.python.org (Daniel Black) Date: Tue, 22 Apr 2014 22:54:18 +0000 Subject: [issue21207] urandom persistent fd - not re-openned after fd close In-Reply-To: <1397316819.31.0.463593532744.issue21207@psf.upfronthosting.co.za> Message-ID: <1398207258.29.0.974305913401.issue21207@psf.upfronthosting.co.za> Daniel Black added the comment: maybe you've thought and dismissed this already but os.close could call dev_urandom_close for the urandom_fd. Then there's no fstat calls in every random access. As a sweeping close all isn't going to occur that often and extra open probably isn't that much overhead. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 00:57:40 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 22 Apr 2014 22:57:40 +0000 Subject: [issue21207] urandom persistent fd - not re-openned after fd close In-Reply-To: <1398207258.29.0.974305913401.issue21207@psf.upfronthosting.co.za> Message-ID: <1398207458.2288.7.camel@fsol> Antoine Pitrou added the comment: > maybe you've thought and dismissed this already but os.close could > call dev_urandom_close for the urandom_fd. Then there's no fstat calls > in every random access. That's fine if os.close() is indeed used to close fd, but not if some third-party library uses the C close() function directly. I don't know how likely that is, but I think it's better to squash the bug completely, rather than 80% of it :-) (also some other stdlib code might (?) also call C close()...) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 01:04:03 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 22 Apr 2014 23:04:03 +0000 Subject: [issue4913] wave.py: add writesamples() and readsamples() In-Reply-To: <1231640203.22.0.836631115229.issue4913@psf.upfronthosting.co.za> Message-ID: <1398207843.87.0.133744708971.issue4913@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Serhiy, is this something you can review? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 01:05:45 2014 From: report at bugs.python.org (Daniel Black) Date: Tue, 22 Apr 2014 23:05:45 +0000 Subject: [issue21207] urandom persistent fd - not re-openned after fd close In-Reply-To: <1397316819.31.0.463593532744.issue21207@psf.upfronthosting.co.za> Message-ID: <1398207945.34.0.636314680755.issue21207@psf.upfronthosting.co.za> Daniel Black added the comment: fine by me. was just a thought ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 01:35:45 2014 From: report at bugs.python.org (raylu) Date: Tue, 22 Apr 2014 23:35:45 +0000 Subject: [issue21332] subprocess bufsize=1 docs are misleading Message-ID: <1398209745.28.0.851161689347.issue21332@psf.upfronthosting.co.za> New submission from raylu: https://docs.python.org/3.3/library/subprocess.html says "bufsize will be supplied as the corresponding argument to the open() function when creating the stdin/stdout/stderr pipe file objects: ... 1 means line buffered" but it calls io.open with 'wb' and 'rb': http://hg.python.org/cpython/file/c9cb931b20f4/Lib/subprocess.py#l828 This puts the file in binary mode, and https://docs.python.org/3.3/library/functions.html#open says "1 to select line buffering (only usable in text mode)" Even with universal_newlines=True, the TextIOWrapper isn't passed line_buffering=True. There's actually no way to get line buffering any more. ---------- components: Library (Lib) messages: 217044 nosy: raylu priority: normal severity: normal status: open title: subprocess bufsize=1 docs are misleading versions: Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 01:45:52 2014 From: report at bugs.python.org (Joe Button) Date: Tue, 22 Apr 2014 23:45:52 +0000 Subject: [issue4913] wave.py: add writesamples() and readsamples() In-Reply-To: <1231640203.22.0.836631115229.issue4913@psf.upfronthosting.co.za> Message-ID: <1398210352.67.0.906974282948.issue4913@psf.upfronthosting.co.za> Joe Button added the comment: On quickly looking at this, the immediate issue seems to me to be that there is no patch, as I understand the term. If it would be helpful I can look at turning the code in the attached files into a patch against default and ensure the tests pass (but not right now as it's ~1am here). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 02:04:36 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 23 Apr 2014 00:04:36 +0000 Subject: [issue21321] itertools.islice() doesn't release reference to the source iterator when the slice is exhausted In-Reply-To: <1398082430.51.0.59207810702.issue21321@psf.upfronthosting.co.za> Message-ID: <1398211476.36.0.722672701257.issue21321@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 02:41:52 2014 From: report at bugs.python.org (Ian Cordasco) Date: Wed, 23 Apr 2014 00:41:52 +0000 Subject: [issue10510] distutils upload/register should use CRLF in HTTP requests In-Reply-To: <1290489114.33.0.672814735109.issue10510@psf.upfronthosting.co.za> Message-ID: <1398213712.55.0.0153777617561.issue10510@psf.upfronthosting.co.za> Changes by Ian Cordasco : ---------- nosy: +icordasc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 03:12:22 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 23 Apr 2014 01:12:22 +0000 Subject: [issue21324] dbhash leaks random memory fragments to a database In-Reply-To: <1398110084.7.0.0365348726476.issue21324@psf.upfronthosting.co.za> Message-ID: <1398215542.31.0.801899696638.issue21324@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 03:24:40 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 23 Apr 2014 01:24:40 +0000 Subject: [issue21324] dbhash leaks random memory fragments to a database In-Reply-To: <1398110084.7.0.0365348726476.issue21324@psf.upfronthosting.co.za> Message-ID: <1398216280.39.0.321563169575.issue21324@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Marcin, what Berkeley DB version are you using?. Platform?. 32 or 64 bits? Could you be able to compile & test a custom python patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 03:28:46 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 23 Apr 2014 01:28:46 +0000 Subject: [issue21324] dbhash leaks random memory fragments to a database In-Reply-To: <1398110084.7.0.0365348726476.issue21324@psf.upfronthosting.co.za> Message-ID: <1398216526.73.0.247407859369.issue21324@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: dbhash uses bsddb behind the curtain. Could you possibly try current bsddb external module at http://www.jcea.es/programacion/pybsddb.htm ?? Thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 03:56:16 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 23 Apr 2014 01:56:16 +0000 Subject: [issue21330] Typo in "Unicode HOWTO" documentation In-Reply-To: <1398194331.3.0.966698777318.issue21330@psf.upfronthosting.co.za> Message-ID: <1398218176.6.0.439489562077.issue21330@psf.upfronthosting.co.za> Benjamin Peterson added the comment: http://hg.python.org/cpython/rev/b428b803f71f http://hg.python.org/cpython/rev/660d53bfb332 http://hg.python.org/cpython/rev/ae4a9000e925 ---------- nosy: +benjamin.peterson resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 04:34:08 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 23 Apr 2014 02:34:08 +0000 Subject: [issue21324] dbhash leaks random memory fragments to a database In-Reply-To: <1398110084.7.0.0365348726476.issue21324@psf.upfronthosting.co.za> Message-ID: <1398220448.44.0.202251378366.issue21324@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Experimenting with this, looks like the content leak is inside Berkeley DB code. The leak is always on offset X*4096 bytes away when the database pagesize is 4096 bytes. Looks like this is an important hint, since Python itself knows nothing about database pagesize. For instance: >>> a=open("secrets.db").read() >>> a.find("secret") 21184 >>> a.find("secret",21185) 25280 >>> 25280-21184 4096 >>> a.find("secret",25281) 37568 >>> 37568-25280 12288 >>> 12288/4096.0 3.0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 04:37:01 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 23 Apr 2014 02:37:01 +0000 Subject: [issue21324] dbhash leaks random memory fragments to a database In-Reply-To: <1398110084.7.0.0365348726476.issue21324@psf.upfronthosting.co.za> Message-ID: <1398220621.51.0.737947799781.issue21324@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: The C version reuses buffers, so the content leak is less probable. Could you possibly change the buffer for a malloc/free pair and try again?. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 05:32:17 2014 From: report at bugs.python.org (Zachary Ware) Date: Wed, 23 Apr 2014 03:32:17 +0000 Subject: [issue17160] test_urllib2net fails In-Reply-To: <1360341954.01.0.966595141063.issue17160@psf.upfronthosting.co.za> Message-ID: <1398223937.93.0.769665814374.issue17160@psf.upfronthosting.co.za> Zachary Ware added the comment: This was already fixed, just not before 2.7.6 was released. ---------- nosy: +zach.ware status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 05:42:21 2014 From: report at bugs.python.org (Zachary Ware) Date: Wed, 23 Apr 2014 03:42:21 +0000 Subject: [issue17160] test_urllib2net fails In-Reply-To: <1360341954.01.0.966595141063.issue17160@psf.upfronthosting.co.za> Message-ID: <1398224541.42.0.981609448643.issue17160@psf.upfronthosting.co.za> Zachary Ware added the comment: Actually, that's not quite right. It was fixed in 2.7.6, then changes to the website broke it again and it has been fixed again since then. Either way, it ain't broke right now ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 07:20:28 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 23 Apr 2014 05:20:28 +0000 Subject: [issue4913] wave.py: add writesamples() and readsamples() In-Reply-To: <1231640203.22.0.836631115229.issue4913@psf.upfronthosting.co.za> Message-ID: <1398230428.84.0.335506010374.issue4913@psf.upfronthosting.co.za> Terry J. Reedy added the comment: A patch against default, including a test, would be helpful. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 07:57:14 2014 From: report at bugs.python.org (Stefan Schwarzer) Date: Wed, 23 Apr 2014 05:57:14 +0000 Subject: [issue21333] Document recommended exception for objects that shouldn't be pickled Message-ID: <1398232634.34.0.847410110548.issue21333@psf.upfronthosting.co.za> New submission from Stefan Schwarzer: I recently was confused whether to raise a `PicklingError` or `TypeError` in `__getstate__` if objects of my class can't and shouldn't be pickled. [1] Terry Reedy advised I should use `TypeError`. [2] I wonder if the `pickle` module documention should explicitly recommend using `TypeError` if a class wants to say that its objects can't be pickled. What do you think? [1] https://mail.python.org/pipermail/python-list/2014-April/670987.html [2] https://mail.python.org/pipermail/python-list/2014-April/671002.html ---------- assignee: docs at python components: Documentation messages: 217054 nosy: docs at python, sschwarzer priority: normal severity: normal status: open title: Document recommended exception for objects that shouldn't be pickled type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 08:23:00 2014 From: report at bugs.python.org (Chris Rebert) Date: Wed, 23 Apr 2014 06:23:00 +0000 Subject: [issue19475] Add microsecond flag to datetime isoformat() In-Reply-To: <1383325521.57.0.024650274045.issue19475@psf.upfronthosting.co.za> Message-ID: <1398234180.72.0.339944858373.issue19475@psf.upfronthosting.co.za> Changes by Chris Rebert : ---------- nosy: +cvrebert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 08:24:00 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 23 Apr 2014 06:24:00 +0000 Subject: [issue6305] islice doesn't accept large stop values In-Reply-To: <1245309263.43.0.625809679675.issue6305@psf.upfronthosting.co.za> Message-ID: <1398234240.29.0.0971642907914.issue6305@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 08:37:02 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 23 Apr 2014 06:37:02 +0000 Subject: [issue21291] subprocess Popen objects are not thread safe w.r.t. wait() and returncode being set In-Reply-To: <1397771383.14.0.251860763766.issue21291@psf.upfronthosting.co.za> Message-ID: <1398235022.21.0.33048719391.issue21291@psf.upfronthosting.co.za> Changes by Gregory P. Smith : Added file: http://bugs.python.org/file35007/issue21291-patch-with-test-gps01.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 08:42:48 2014 From: report at bugs.python.org (Sworddragon) Date: Wed, 23 Apr 2014 06:42:48 +0000 Subject: [issue21331] Reversing an encoding with unicode-escape returns a different result In-Reply-To: <1398200303.74.0.876201125787.issue21331@psf.upfronthosting.co.za> Message-ID: <1398235368.19.0.430978418857.issue21331@psf.upfronthosting.co.za> Sworddragon added the comment: The documentation says that unicode_internal is deprecated since Python 3.3 but not unicode_escape. Also, isn't unicode_escape different from utf-8? For example my original intention was to convert 2 byte string characters to their control characters. For example the file test.txt contains the 17 byte utf-8 raw content "---a---\n---?---". Now I want to convert '\\n' to '\n': >>> file = open('test.txt', 'r') >>> content = file.read() >>> file.close() >>> content = content.encode('utf-8').decode('unicode-escape') >>> print(content) ---a--- ---??--- I'm getting now successfully 2 lines but I have noticed not getting the ? anymore. After that I have made a deeper look and opened this ticket. If unicode_escape gets really deprecated maybe I could simply replace the characters 0-31 and 127 to achieve practically the same behavior. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 09:30:39 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Wed, 23 Apr 2014 07:30:39 +0000 Subject: [issue21207] urandom persistent fd - not re-openned after fd close In-Reply-To: <1398205075.75.0.580241518009.issue21207@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > Updated patch using an anonymous struct. LGTM! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 09:38:32 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 23 Apr 2014 07:38:32 +0000 Subject: [issue21291] subprocess Popen objects are not thread safe w.r.t. wait() and returncode being set In-Reply-To: <1397771383.14.0.251860763766.issue21291@psf.upfronthosting.co.za> Message-ID: <3gDD5z44Ztz7LjX@mail.python.org> Roundup Robot added the comment: New changeset 5d745d97b7da by Gregory P. Smith in branch '3.4': subprocess's Popen.wait() is now thread safe so that multiple threads http://hg.python.org/cpython/rev/5d745d97b7da New changeset df45d0336dad by Gregory P. Smith in branch 'default': subprocess's Popen.wait() is now thread safe so that multiple threads http://hg.python.org/cpython/rev/df45d0336dad ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 09:44:46 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Wed, 23 Apr 2014 07:44:46 +0000 Subject: [issue17552] socket.sendfile() In-Reply-To: <1398188985.97.0.436309259821.issue17552@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: 1) I really don't like the use_fallback argument: as a user, I don't care if it's using sendfile/splice/whatever WIndows uses. I view this as a channel transfer (like Java's http://docs.oracle.com/javase/7/docs/api/java/nio/channels/FileChannel.html#transferFrom(java.nio.channels.ReadableByteChannel, long, long)), which moves bytes around from one FD to another. If the user want precise control, he can just go ahead and call the syscall itself. Apart from complicating the prototype, what do this bring? 2) Just returning the number of bytes sent is fine 3) I really don't like the blocksize argument. Just use a really large value internally to minimize the number of syscalls, that's all that matters. I've *never* seen code which explicitly uses a blocksize: in 99% of cases, it just uses stat to find out the file size, and call sendfile with it. Trying to be consistent with ftplib is IMO a bad idea, since the API is just completely broken (I mean, just sending/retrieving a file is complex). A useful parameter instead would be to support sending only part of the file, so adding a count argument. You can have a look at http://docs.oracle.com/javase/7/docs/api/java/nio/channels/FileChannel.html#transferFrom(java.nio.channels.ReadableByteChannel, long, long) for an example many people bash Java, but they've designed some great APIs :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 10:35:30 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 23 Apr 2014 08:35:30 +0000 Subject: [issue21291] subprocess Popen objects are not thread safe w.r.t. wait() and returncode being set In-Reply-To: <1397771383.14.0.251860763766.issue21291@psf.upfronthosting.co.za> Message-ID: <1398242130.74.0.518290381583.issue21291@psf.upfronthosting.co.za> Gregory P. Smith added the comment: This fix is also present in subprocess32 3.2.6 on PyPI for use on Python 2. ---------- resolution: -> fixed stage: -> commit review status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 11:42:41 2014 From: report at bugs.python.org (randomcoder1) Date: Wed, 23 Apr 2014 09:42:41 +0000 Subject: [issue21334] nntplib throws exceptions making sinntp unusable Message-ID: <1398246161.17.0.601121532503.issue21334@psf.upfronthosting.co.za> New submission from randomcoder1: Sinntp is a nntp client. It uses nntplib from Python as a nntp library to fetch messages from NNTP servers. I've tested this on two environments with the following package versions: 1) Ubuntu 12.04.4 , python-support 1.0.14ubuntu2, Python 2.7.3-0ubuntu2.2 , sinntp 1.4-1 , libpython2.7 2.7.3-0ubuntu3.4 2) Debian jessie , python-support 1.0.15, Python 2.7.5-5, sinntp 1.5-1 , libpython2.7 version 2.7.6-8 sinntp crashed on 2) and threw NNTP* exceptions which are described in more detail in the bugreport-data.tgz file that comes with this bugreport. I was also able to isolate one NNTP article that caused it to crash, that's also included. I've included above the libpython2.7 version because user at machine:/tmp$ sudo apt-file -x search 'nntplib.py$' [..] libpython2.7-stdlib: /usr/lib/python2.7/nntplib.py [..] Upon trying to replace the sinntp 1.5-1 on 2) with the one in 1) , the problem was still present, so I believe sinntp can be excluded. I think the bug is caused by the newer version of libpython2.7 in 2). ---------- components: Library (Lib) files: bureport-data.tgz messages: 217060 nosy: randomcoder1 priority: normal severity: normal status: open title: nntplib throws exceptions making sinntp unusable type: crash versions: Python 2.7 Added file: http://bugs.python.org/file35008/bureport-data.tgz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 11:46:09 2014 From: report at bugs.python.org (randomcoder1) Date: Wed, 23 Apr 2014 09:46:09 +0000 Subject: [issue21334] nntplib throws exceptions making sinntp unusable In-Reply-To: <1398246161.17.0.601121532503.issue21334@psf.upfronthosting.co.za> Message-ID: <1398246369.72.0.157793570488.issue21334@psf.upfronthosting.co.za> randomcoder1 added the comment: I'm cross-referencing this here too. https://code.google.com/p/sinntp/issues/detail?id=9 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 11:54:20 2014 From: report at bugs.python.org (randomcoder1) Date: Wed, 23 Apr 2014 09:54:20 +0000 Subject: [issue21334] nntplib throws exceptions making sinntp unusable In-Reply-To: <1398246161.17.0.601121532503.issue21334@psf.upfronthosting.co.za> Message-ID: <1398246860.71.0.619401810945.issue21334@psf.upfronthosting.co.za> randomcoder1 added the comment: I forgot to mention that in the environment 1) described above, everything worked fine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 12:52:48 2014 From: report at bugs.python.org (Jakub Wilk) Date: Wed, 23 Apr 2014 10:52:48 +0000 Subject: [issue21334] nntplib throws exceptions making sinntp unusable In-Reply-To: <1398246161.17.0.601121532503.issue21334@psf.upfronthosting.co.za> Message-ID: <1398250368.3.0.720208522797.issue21334@psf.upfronthosting.co.za> Jakub Wilk added the comment: For the reference, the exception is: Traceback (most recent call last): File "/home/user/sources/sinntp/sinntp", line 357, in connection.quit() File "/usr/lib/python2.7/nntplib.py", line 608, in quit resp = self.shortcmd('QUIT') File "/usr/lib/python2.7/nntplib.py", line 268, in shortcmd return self.getresp() File "/usr/lib/python2.7/nntplib.py", line 223, in getresp resp = self.getline() File "/usr/lib/python2.7/nntplib.py", line 212, in getline raise NNTPDataError('line too long') nntplib.NNTPDataError: line too long The change in the behavior is intentional. The maximum line length has been limited to 2048 to prevent denial of service. This is issue #16040 aka CVE-2013-1752. This is what relevant standards say: RFC 3977 ?3.1.1: ?This document does not place any limit on the length of a line in a multi-line block. However, the standards that define the format of articles may do so.? RFC 5322 ?2.1.1: ?Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF.? The message that sinntp tripped over had lines longer than RFC 5322 permits, so it shouldn't have been accepted by the server in the first place. I don't think there's much to be fixed on the Python side. What could be improved is error handling in sinntp; but let's discuss this in the sinntp bug tracker. :) ---------- nosy: +jwilk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 12:54:25 2014 From: report at bugs.python.org (Thorsten Weimann) Date: Wed, 23 Apr 2014 10:54:25 +0000 Subject: [issue20136] Logging: StreamHandler does not use OS line separator. In-Reply-To: <1388998969.13.0.29066681056.issue20136@psf.upfronthosting.co.za> Message-ID: <1398250465.92.0.246052613523.issue20136@psf.upfronthosting.co.za> Thorsten Weimann added the comment: Please re-open. The IO system only takes care of line separators, if no encoding is given. ---------- nosy: +Thorsten.W _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 13:26:09 2014 From: report at bugs.python.org (Martin Kolman) Date: Wed, 23 Apr 2014 11:26:09 +0000 Subject: [issue21251] Standard library trace module crashes with exception In-Reply-To: <1397652137.22.0.406999160837.issue21251@psf.upfronthosting.co.za> Message-ID: <1398252369.68.0.768823875229.issue21251@psf.upfronthosting.co.za> Martin Kolman added the comment: @ 1.: Reproducer attached to the comment - just build the C code and run trace_test.py It is maybe not as minimal as it could be but I'm afraid the context of what the module is doing would be lost if it was cut down too aggressively. @ 2.: I'm afraid this is not applicable in this case - pyblock just flat out does not support Python 3 and I haven't been able to find out even any third-party Python 3 port of it. I even tried to force run the current code with Python 3, just in case, but it just tracebacks during import due to Python 3 incompatible code, even before even importing the C extensions. ---------- Added file: http://bugs.python.org/file35009/pyblock.tar.xz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 13:39:33 2014 From: report at bugs.python.org (Jakub Wilk) Date: Wed, 23 Apr 2014 11:39:33 +0000 Subject: [issue21332] subprocess bufsize=1 docs are misleading In-Reply-To: <1398209745.28.0.851161689347.issue21332@psf.upfronthosting.co.za> Message-ID: <1398253173.99.0.461704485844.issue21332@psf.upfronthosting.co.za> Changes by Jakub Wilk : ---------- nosy: +jwilk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 13:40:03 2014 From: report at bugs.python.org (Jakub Wilk) Date: Wed, 23 Apr 2014 11:40:03 +0000 Subject: [issue9338] argparse optionals with nargs='?', '*' or '+' can't be followed by positionals In-Reply-To: <1279881989.28.0.725806934086.issue9338@psf.upfronthosting.co.za> Message-ID: <1398253203.69.0.501735114452.issue9338@psf.upfronthosting.co.za> Changes by Jakub Wilk : ---------- nosy: +jwilk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 14:01:22 2014 From: report at bugs.python.org (Jakub Wilk) Date: Wed, 23 Apr 2014 12:01:22 +0000 Subject: [issue21109] tarfile: Traversal attack vulnerability In-Reply-To: <1396253659.12.0.842636239516.issue21109@psf.upfronthosting.co.za> Message-ID: <1398254482.4.0.943176468997.issue21109@psf.upfronthosting.co.za> Changes by Jakub Wilk : ---------- nosy: +jwilk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 14:54:11 2014 From: report at bugs.python.org (Mark Kubacki) Date: Wed, 23 Apr 2014 12:54:11 +0000 Subject: [issue20995] Use Better Default Ciphers for the SSL Module In-Reply-To: <1395324676.75.0.303580402974.issue20995@psf.upfronthosting.co.za> Message-ID: <1398257651.22.0.498425276143.issue20995@psf.upfronthosting.co.za> Mark Kubacki added the comment: The cipher strings rely too much on AES for my taste. Imagine that ChaCha20Poly1305 or any other strong cipher suite is introduced to OpenSSL in the future. Enabling using general, and demoting using narrow terms, seems IMHO a better approach. For example: ECDH+HIGH:DH+HIGH:!aNULL:!MD5:!RC4:-3DES:HIGH ---------- nosy: +markk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 15:23:59 2014 From: report at bugs.python.org (Donald Stufft) Date: Wed, 23 Apr 2014 13:23:59 +0000 Subject: [issue20995] Use Better Default Ciphers for the SSL Module In-Reply-To: <1395324676.75.0.303580402974.issue20995@psf.upfronthosting.co.za> Message-ID: <1398259439.17.0.192512394523.issue20995@psf.upfronthosting.co.za> Donald Stufft added the comment: The cipher string includes HIGH, so if ChaCha20Poly1305 or another cipher suite is added to OpenSSL it'll get included in the cipher string by default. So the major difference of what you suggest would be no longer prioritizing ciphers. However I would argue that would be bad. The priority exists so that we get the best possible cipher is as many situations as we possibly can. It doesn't mean that we'll get the best possible cipher in *every* single situation, but generally we will. To this ends it prioritizes: * PFS with a secure cipher over everything else (Your string would do this as well) * After that prefer ECDHE over DHE * After that, prefer AES-GCM * After that, prefer AES-CBC * After that, any other HIGH cipher * After that, 3DES * After that, any use of RC4 including those with PFS So if OpenSSL added ChaCha20Poly1305 it would fit into the priority after AES-GCM and AES-CBC. For any device that has hardware support for AES (AES-NI) AES-GCM is hands down a better choice of cipher. It is secure, has no issues in the spec itself, and it is *fast*, like 900MB/s for AES-128-GCM on a Sandy Bridge Xeon w/ AES-NI (ChaCha20Poly1305 got 500MB/s on the same hardware, however it is a 256bit cipher will AES-128-GCM is a 128 bit cipher). Using ChaCha20 on those devices would be a worse choice than AES-GCM. However on lower powered devices, such as smart phones, especially those without hardware support for AES, ChaCha20 really shines. A Galaxy Nexus can do AES-256-GCM at 20MB/s whereas it can do ChaCha20Poly1305 at 92MB/s (same phone). So in an ideal world, assuming ChaCha20 was implemented in OpenSSL, we'd adjust the default cipher string based on the hardware they are running on. However since we don't have the ability to do that then preferring AES (which we know on some systems will be much faster) over an unknown future cipher (which we have no knowledge of if it will be faster or not) is a much more reasonable choice. If at some point in the future OpenSSL gains ChaCha20Poly1305 support then these strings should probably change to put ChaCha20Poly1305 in between AES-GCM and AES-CBC because on any given the system the likelyhood that you want AES-GCM is still higher than ChaCha20, but the likelyhood you want ChaCha20 over AES-CBC is greater. It's also important to note that the server in any TLS communication is the end that picks exactly which cipher we select. Ideally all servers will be configured to have the strongest cipher first, and to prefer their own cipher order. In that case for the *client* side of a TLS connection the order of the ciphers doesn't matter and thus your string vs the implemented string has no difference in behavior. However if the server doesn't enforce their own preference for ciphers, then the difference will be that an undefined cipher will be selected (could be AESGCM, AESCBC, ChaCha20, or Camellia). On the server side of this, if you're using Python to terminate your TLS on the server side, the likelyhood that a server is running on a low powered device where the benefits of ChaCha20Poly1305 are the highest are pretty low and preferring AES-GCM is an even safer idea. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 15:24:41 2014 From: report at bugs.python.org (Berker Peksag) Date: Wed, 23 Apr 2014 13:24:41 +0000 Subject: [issue21333] Document recommended exception for objects that shouldn't be pickled In-Reply-To: <1398232634.34.0.847410110548.issue21333@psf.upfronthosting.co.za> Message-ID: <1398259481.93.0.0931051260463.issue21333@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +alexandre.vassalotti, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 15:34:11 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 23 Apr 2014 13:34:11 +0000 Subject: [issue20995] Use Better Default Ciphers for the SSL Module In-Reply-To: <1398259439.17.0.192512394523.issue20995@psf.upfronthosting.co.za> Message-ID: <1398260048.2295.12.camel@fsol> Antoine Pitrou added the comment: > For any device that has hardware support for AES (AES-NI) AES-GCM is > hands down a better choice of cipher. It is secure, has no issues in > the spec itself, and it is *fast*, like 900MB/s for AES-128-GCM on a > Sandy Bridge Xeon w/ AES-NI (ChaCha20Poly1305 got 500MB/s on the same > hardware, however it is a 256bit cipher will AES-128-GCM is a 128 bit > cipher). Using ChaCha20 on those devices would be a worse choice than > AES-GCM. I think performance isn't really relevant, except perhaps on very busy servers. A smartphone acting as a *client* certainly shouldn't need to download 20 MB/s of encrypted data. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 15:44:10 2014 From: report at bugs.python.org (Donald Stufft) Date: Wed, 23 Apr 2014 13:44:10 +0000 Subject: [issue20995] Use Better Default Ciphers for the SSL Module In-Reply-To: <1395324676.75.0.303580402974.issue20995@psf.upfronthosting.co.za> Message-ID: <1398260650.97.0.129969618495.issue20995@psf.upfronthosting.co.za> Donald Stufft added the comment: > I think performance isn't really relevant, except perhaps on very busy > servers. A smartphone acting as a *client* certainly shouldn't need to > download 20 MB/s of encrypted data. Well, if you factor out performance then ChaCha20Poly1305 and AES-GCM are more or less equivalent in preference with AES-CBC still less than either of them because of problematic construction choices in the TLS spec. If you factor out performance completely there is maybe a slight preference for ChaCha20Poly1305 over AES-GCM simply because AES-GCM is hard to implement in a timing safe way in software. However that discussion is mostly academic as right now ChaCha20Poly1305 is not available in OpenSSL. In general I agree that the performance of all of these are "good enough" that the average user of this API won't be able to tell the difference, however there is no cost to selecting the generally more performant of the two so I think it still makes sense to consider it. Hopefully what I was trying to achieve was provide some more context for markk so he'd hopefully be able to better understand why the string cipher calls out AES specifically before falling back to HIGH. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 16:26:42 2014 From: report at bugs.python.org (Mark Kubacki) Date: Wed, 23 Apr 2014 14:26:42 +0000 Subject: [issue20995] Use Better Default Ciphers for the SSL Module In-Reply-To: <1395324676.75.0.303580402974.issue20995@psf.upfronthosting.co.za> Message-ID: <1398263202.09.0.711529704898.issue20995@psf.upfronthosting.co.za> Mark Kubacki added the comment: Thanks for the detailed insight, Donald! And I certainly love the progress these changes here bring. :-) Perhaps limiting the scope to ChaCha20Poly1305 (?CCP?) has been a wrong approach of mine to explain my concerns: We should not refer to any particular cipher in those lists, and by that avoid to revisit the defaults at any point in the future. 0. Properties of any cipher to come are known to the makers of OpenSSL first. 1. Python shouldn't duplicate the work of ordering ciphers, which is already done by OpenSSL. 2. ? especially because it is unknown which ciphers a user's OpenSSL does actually implement (Is EC present? CCP? HC-256 or HC-128? WIERZA? Rabbit? NTRU?) or will implement in the future. 3. Whether a cipher is regarded as more secure than another depends on its implementation, too. The implementors are better judges of that, and hence ordering should done by them and could vary between versions [e.g., of OpenSSL]. 4. Given our experiences with Python 2.7 I'd like to argue that there is reluctance to upgrading existing installations and its cipher suite strings. ;-) But we know from experience with already established ciphers if and when to demote them. That said I don't insist on any changes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 16:28:37 2014 From: report at bugs.python.org (Alex Gaynor) Date: Wed, 23 Apr 2014 14:28:37 +0000 Subject: [issue20995] Use Better Default Ciphers for the SSL Module In-Reply-To: <1395324676.75.0.303580402974.issue20995@psf.upfronthosting.co.za> Message-ID: <1398263317.02.0.01555362742.issue20995@psf.upfronthosting.co.za> Alex Gaynor added the comment: It would be great if we could rely on OpenSSL's ordering. It would be seriously fantastic. OpenSSL is best positioned to be able to do the right things, it's updated at the right times. It should be where we do this. Unfortunately the OpenSSL maintainers have utterly abdicated any responsibility for helping secure users, and has gone with poor defaults, obligating us to fill the hole. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 16:28:38 2014 From: report at bugs.python.org (randomcoder1) Date: Wed, 23 Apr 2014 14:28:38 +0000 Subject: [issue21334] nntplib throws exceptions making sinntp unusable In-Reply-To: <1398246161.17.0.601121532503.issue21334@psf.upfronthosting.co.za> Message-ID: <1398263318.49.0.905613733255.issue21334@psf.upfronthosting.co.za> randomcoder1 added the comment: @Jakub Sure, I've submitted a patch in the sinntp googlecode issue tracker. When you have some time, please have a look at it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 16:29:09 2014 From: report at bugs.python.org (randomcoder1) Date: Wed, 23 Apr 2014 14:29:09 +0000 Subject: [issue21334] nntplib throws exceptions making sinntp unusable In-Reply-To: <1398246161.17.0.601121532503.issue21334@psf.upfronthosting.co.za> Message-ID: <1398263349.7.0.501561486326.issue21334@psf.upfronthosting.co.za> Changes by randomcoder1 : ---------- resolution: -> third party status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 17:01:51 2014 From: report at bugs.python.org (Brett Cannon) Date: Wed, 23 Apr 2014 15:01:51 +0000 Subject: [issue21335] Update importlib.__init__ to reset _frozen_imnportlib's loader to SourceFileLoader Message-ID: <1398265311.8.0.131352279084.issue21335@psf.upfronthosting.co.za> New submission from Brett Cannon: When importlib.__init__ tries to mask the fact that _frozen_importlib is frozen it should also reset __loader__ to be an instance of SourceFileLoader. This will allow tracebacks to include source lines thanks to SourceFileLoader.get_source(). ---------- assignee: brett.cannon components: Library (Lib) messages: 217073 nosy: brett.cannon priority: low severity: normal stage: needs patch status: open title: Update importlib.__init__ to reset _frozen_imnportlib's loader to SourceFileLoader type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 17:07:38 2014 From: report at bugs.python.org (Zachary Ware) Date: Wed, 23 Apr 2014 15:07:38 +0000 Subject: [issue21335] Update importlib.__init__ to reset _frozen_importlib's loader to SourceFileLoader In-Reply-To: <1398265311.8.0.131352279084.issue21335@psf.upfronthosting.co.za> Message-ID: <1398265658.83.0.593858259006.issue21335@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- title: Update importlib.__init__ to reset _frozen_imnportlib's loader to SourceFileLoader -> Update importlib.__init__ to reset _frozen_importlib's loader to SourceFileLoader _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 17:18:07 2014 From: report at bugs.python.org (Vinay Sajip) Date: Wed, 23 Apr 2014 15:18:07 +0000 Subject: [issue20136] Logging: StreamHandler does not use OS line separator. In-Reply-To: <1388998969.13.0.29066681056.issue20136@psf.upfronthosting.co.za> Message-ID: <1398266287.82.0.140235330068.issue20136@psf.upfronthosting.co.za> Vinay Sajip added the comment: > Please re-open. This is configurable in Python 3.2 and later using the "terminator" attribute, but this can't be added to 2.7 as it would constitute a new feature. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 18:15:03 2014 From: report at bugs.python.org (ddvento@ucar.edu) Date: Wed, 23 Apr 2014 16:15:03 +0000 Subject: [issue17160] test_urllib2net fails In-Reply-To: <1398224541.42.0.981609448643.issue17160@psf.upfronthosting.co.za> Message-ID: <5357E709.7040009@ucar.edu> ddvento at ucar.edu added the comment: Well, ok, thanks :-) But I'm still wondering if it's not possible to use mocks for this test. or at least example.com (as in issue #20939) which is supposed to be more stable than python.org ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 18:32:03 2014 From: report at bugs.python.org (Zachary Ware) Date: Wed, 23 Apr 2014 16:32:03 +0000 Subject: [issue17386] Bring Doc/make.bat as close to Doc/Makefile as possible In-Reply-To: <1362781994.31.0.121984055749.issue17386@psf.upfronthosting.co.za> Message-ID: <1398270723.88.0.0669809239646.issue17386@psf.upfronthosting.co.za> Zachary Ware added the comment: Having looked at this again, the current patch is just far bigger than it needs to be and tries to do too much, not to mention being rather out of date now. So, here's a much less ambitious, much simpler patch with many fewer ways it can go wrong (but also not quite as close a match to using Makefile). Instead of only allowing specific targets, the script now only specifies non-Sphinx-builder targets (like clean, check, help, htmlview, and serve) and assumes that any first argument it doesn't recognize is supposed to be a Sphinx builder. "htmlhelp" is still special-cased in the "build" target. Not listing all the Sphinx builder targets explicitly means that builders like "dirhtml", "pickle", or "json", or any builders added in future Sphinx versions will just work without our having to do anything for them. ---------- assignee: docs at python -> zach.ware stage: commit review -> patch review versions: +Python 3.5 Added file: http://bugs.python.org/file35010/issue17386.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 18:57:20 2014 From: report at bugs.python.org (Ben Ma) Date: Wed, 23 Apr 2014 16:57:20 +0000 Subject: [issue21336] ntpath.splitdrive fails on None argument Message-ID: <1398272240.06.0.678669968331.issue21336@psf.upfronthosting.co.za> New submission from Ben Ma: >>> import ntpath >>> ntpath.splitdrive(None) Traceback (most recent call last): File "", line 1, in File "E:\python3\lib\ntpath.py", line 159, in splitdrive if p and len(p) > 1: TypeError: object of type 'NoneType' has no len() Solution: (that I've found) Lib/ntpath.py #in function splitdrive ... empty = _get_empty(p) +++ if p and len(p) > 1: --- if len(p) > 1: sep = _get_sep(p) ... return p[:2], p[2:] +++ else: +++ p = '' return empty, p ... ---------- components: Library (Lib) messages: 217077 nosy: runapp priority: normal severity: normal status: open title: ntpath.splitdrive fails on None argument type: crash versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 19:20:13 2014 From: report at bugs.python.org (Eric V. Smith) Date: Wed, 23 Apr 2014 17:20:13 +0000 Subject: [issue21336] ntpath.splitdrive fails on None argument In-Reply-To: <1398272240.06.0.678669968331.issue21336@psf.upfronthosting.co.za> Message-ID: <1398273613.59.0.591707875007.issue21336@psf.upfronthosting.co.za> Eric V. Smith added the comment: Why are you passing None, and what would you expect the result to be? The function is documented as taking a string. ---------- nosy: +eric.smith type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 19:24:18 2014 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 23 Apr 2014 17:24:18 +0000 Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za> Message-ID: <1398273858.3.0.37733343854.issue18967@psf.upfronthosting.co.za> Ezio Melotti added the comment: One of the Mercurial devs convinced me to pursue what I had initially proposed in msg197645 and write a merge script (attached). The script is still a proof of concept, it makes a few assumptions and doesn't handle all the cases, but I did a few tests and it seems to work for at least some cases. If people like it it can be improved. In short it parses Misc/NEWS, see what news entries have been added in the changeset(s) that it's being merged, and adds them at the top of the corresponding section. To enable it download the file, set it as executable (chmod +x newsmerge.py), and add the following to .hg/hgrc: [merge-tools] newsmerge.executable = /path/to/newsmerge.py newsmerge.priority = 100 newsmerge.premerge = True newsmerge.args = $base $local $other -o $output [merge-patterns] Misc/NEWS = newsmerge This will kick in only if the regular merge results in a conflict (so if you don't see any of the debug output from newsmerge it means that mercurial managed to merge Misc/NEWS on its own without conflicts). ---------- Added file: http://bugs.python.org/file35011/newsmerge.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 19:26:38 2014 From: report at bugs.python.org (Giampaolo Rodola') Date: Wed, 23 Apr 2014 17:26:38 +0000 Subject: [issue17552] socket.sendfile() In-Reply-To: <1364326073.47.0.699222209849.issue17552@psf.upfronthosting.co.za> Message-ID: <1398273998.89.0.0627946596294.issue17552@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: > 1) I really don't like the use_fallback argument > Apart from complicating the prototype, what do this bring? My initial thought was that the user might want to know *why* a file cannot be sent by using the fastest method and hence wants to see the original exception. Anyway, I have not strong opinions about this so I guess we can also drop it. > A useful parameter instead would be to support sending only part of the file, > so adding a count argument. Have you read my patch? This is already provided by the "offset" parameter. > I really don't like the blocksize argument. > I've *never* seen code which explicitly uses a blocksize Both sendfile() and TransmitFile provide a "blocksize" parameter for very good reasons therefore it seems natural that an API built on top of them exposes the same parameter as well. Some examples in the stdlib which comes to mind using a blocksize are asynchat.async_chat.ac_out_buffer_size and ftplib.FTP.storbinary and I'm sure if you grep for "blocksize" you'll find others. Providing a blocksize is also necessary to tell how many bytes to read from file in case send() is used, 'cause it's *crucial* that you don't read the whole file into memory. I will also give a real world example: if your app wants to limit the transfer speed you will want to explicitly transmit smaller chunks of data and then "sleep", and the only way to do that is by manipulating the blocksize. So yes: a blocksize parameter *is* necessary, so please stop beating that horse. As for using a bigger value: I made some benchmarks by using different sizes and I didn't notice any noticeable difference. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 19:53:08 2014 From: report at bugs.python.org (Giampaolo Rodola') Date: Wed, 23 Apr 2014 17:53:08 +0000 Subject: [issue17552] socket.sendfile() In-Reply-To: <1364326073.47.0.699222209849.issue17552@psf.upfronthosting.co.za> Message-ID: <1398275588.26.0.151814613364.issue17552@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: Note: my example about limiting the transfer speed does not really apply 'cause as this stands right now it cannot be used with non-blocking sockets. Other arguments do though and I hope it's clear that we need "blocksize". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 20:21:35 2014 From: report at bugs.python.org (akira) Date: Wed, 23 Apr 2014 18:21:35 +0000 Subject: [issue17552] socket.sendfile() In-Reply-To: <1364326073.47.0.699222209849.issue17552@psf.upfronthosting.co.za> Message-ID: <1398277295.69.0.188741789762.issue17552@psf.upfronthosting.co.za> akira added the comment: > I really don't like the use_fallback argument .. I initially also thought so. But I've suggested the parameter to replace `(was_os_sendfile_used, os_sendfile_error)` returned value as a *trade off* between a slight complexity in the interface vs. allowing to detect performance bugs easily e.g., when someone passed a file-like object incompatible with os.sendfile by accident (it is not enough to have a valid fileno. What mmap-like means?). > .. as a user, I don't care if it's using sendfile/splice/whatever WIndows uses. > .. what do this bring? The reason sendfile exists is performance. Otherwise socket.makefile and shutil.copyfileobj could be used instead. use_fallback parameter provides a way to assert that an ineffective fallback is not used by accident. It may be ignored by most users. An alternative is a new separate public method that doesn't use the fallback. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 21:36:59 2014 From: report at bugs.python.org (Justin Myers) Date: Wed, 23 Apr 2014 19:36:59 +0000 Subject: [issue20849] add exist_ok to shutil.copytree In-Reply-To: <1393908922.06.0.91052425832.issue20849@psf.upfronthosting.co.za> Message-ID: <1398281819.21.0.876157708445.issue20849@psf.upfronthosting.co.za> Changes by Justin Myers : ---------- nosy: +justin.myers _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 21:42:14 2014 From: report at bugs.python.org (akira) Date: Wed, 23 Apr 2014 19:42:14 +0000 Subject: [issue21332] subprocess bufsize=1 docs are misleading In-Reply-To: <1398209745.28.0.851161689347.issue21332@psf.upfronthosting.co.za> Message-ID: <1398282134.79.0.381017776357.issue21332@psf.upfronthosting.co.za> Changes by akira <4kir4.1i at gmail.com>: ---------- nosy: +akira _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 21:49:32 2014 From: report at bugs.python.org (Zachary Ware) Date: Wed, 23 Apr 2014 19:49:32 +0000 Subject: [issue9764] Tools/buildbot/external.bat should download and built tix In-Reply-To: <1283546660.96.0.0013695103683.issue9764@psf.upfronthosting.co.za> Message-ID: <1398282572.44.0.0806831009208.issue9764@psf.upfronthosting.co.za> Zachary Ware added the comment: This is fixed in 3.5, PCbuild/tix.vcxproj builds Tix in Debug and Release modes. ---------- nosy: +zach.ware resolution: -> fixed stage: needs patch -> resolved status: open -> closed versions: +Python 3.5 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 21:56:57 2014 From: report at bugs.python.org (Zachary Ware) Date: Wed, 23 Apr 2014 19:56:57 +0000 Subject: [issue9765] tcl-8 vs tcl8 In-Reply-To: <1283546777.07.0.320688875982.issue9765@psf.upfronthosting.co.za> Message-ID: <1398283017.15.0.293323101166.issue9765@psf.upfronthosting.co.za> Zachary Ware added the comment: PCbuild/tix.vcxproj explicitly sets TCL_DIR and TK_DIR in the command line used to build Tix, using the paths used by the rest of the solution and the Tools/buildbot scripts; would the attached patch now be acceptable (for 3.5 only)? ---------- nosy: +zach.ware stage: needs patch -> patch review versions: +Python 3.5 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 22:01:26 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 23 Apr 2014 20:01:26 +0000 Subject: [issue9765] tcl-8 vs tcl8 In-Reply-To: <1283546777.07.0.320688875982.issue9765@psf.upfronthosting.co.za> Message-ID: <1398283286.17.0.990014129786.issue9765@psf.upfronthosting.co.za> Martin v. L?wis added the comment: For 3.5, it's fine. ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 22:04:16 2014 From: report at bugs.python.org (ddvento@ucar.edu) Date: Wed, 23 Apr 2014 20:04:16 +0000 Subject: [issue21278] Running the test suite with -v makes the test_ctypes and the test_zipimport erroneously reported as failed In-Reply-To: <1398035445.28.0.0549224679642.issue21278@psf.upfronthosting.co.za> Message-ID: <53581CC1.8010705@ucar.edu> ddvento at ucar.edu added the comment: Ok, let me dig into it and see if I can figure it out On 04/20/2014 05:10 PM, Ezio Melotti wrote: > > Ezio Melotti added the comment: > > Do you want to propose a patch? > > ---------- > components: +Tests > nosy: +ezio.melotti > type: -> behavior > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 22:38:04 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 23 Apr 2014 20:38:04 +0000 Subject: [issue9765] tcl-8 vs tcl8 In-Reply-To: <1283546777.07.0.320688875982.issue9765@psf.upfronthosting.co.za> Message-ID: <3gDYPS0QM5zRZp@mail.python.org> Roundup Robot added the comment: New changeset 4ff37fbcd4e8 by Zachary Ware in branch 'default': Issue #9765: Adjust where Tools/msi/msi.py looks for Tcl/Tk license terms. http://hg.python.org/cpython/rev/4ff37fbcd4e8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 22:39:32 2014 From: report at bugs.python.org (Zachary Ware) Date: Wed, 23 Apr 2014 20:39:32 +0000 Subject: [issue9765] tcl-8 vs tcl8 In-Reply-To: <1283546777.07.0.320688875982.issue9765@psf.upfronthosting.co.za> Message-ID: <1398285572.03.0.069335071254.issue9765@psf.upfronthosting.co.za> Zachary Ware added the comment: Done, thanks! ---------- assignee: -> zach.ware resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 22:46:48 2014 From: report at bugs.python.org (Zachary Ware) Date: Wed, 23 Apr 2014 20:46:48 +0000 Subject: [issue21337] Add tests for Tix Message-ID: <1398286008.45.0.411979424173.issue21337@psf.upfronthosting.co.za> New submission from Zachary Ware: We should have some tests for Tix, which currently has none. The Windows buildbots will be able to run the tests, but Tix is not guaranteed to be available elsewhere. ---------- components: Tests, Tkinter keywords: easy messages: 217089 nosy: zach.ware priority: low severity: normal stage: needs patch status: open title: Add tests for Tix type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 23:44:13 2014 From: report at bugs.python.org (Giampaolo Rodola') Date: Wed, 23 Apr 2014 21:44:13 +0000 Subject: [issue17552] socket.sendfile() In-Reply-To: <1364326073.47.0.699222209849.issue17552@psf.upfronthosting.co.za> Message-ID: <1398289453.51.0.406178065396.issue17552@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: Considering the current indecision about certain design aspects I started a discussion on python-ideas: https://mail.python.org/pipermail/python-ideas/2014-April/027752.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 23:46:29 2014 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 23 Apr 2014 21:46:29 +0000 Subject: [issue17552] socket.sendfile() In-Reply-To: <1364326073.47.0.699222209849.issue17552@psf.upfronthosting.co.za> Message-ID: <1398289589.42.0.449737923222.issue17552@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 23 23:56:52 2014 From: report at bugs.python.org (Jim Jewett) Date: Wed, 23 Apr 2014 21:56:52 +0000 Subject: [issue19385] dbm.dumb should be consistent when the database is closed In-Reply-To: <1382683121.03.0.174486602388.issue19385@psf.upfronthosting.co.za> Message-ID: <1398290212.84.0.910704748722.issue19385@psf.upfronthosting.co.za> Jim Jewett added the comment: _check_closed sounds like you expect it to be closed, and might even assert that it is closed, except that you want the check run even in release mode and/or it might fail. Since being closed is actually the unexpectedly broken state, I would prefer that you rename it to something else, like _verify_open. ---------- nosy: +Jim.Jewett _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 00:00:47 2014 From: report at bugs.python.org (Derek Wilson) Date: Wed, 23 Apr 2014 22:00:47 +0000 Subject: [issue17305] IDNA2008 encoding missing In-Reply-To: <1361928766.42.0.728949411958.issue17305@psf.upfronthosting.co.za> Message-ID: <1398290447.66.0.504917780161.issue17305@psf.upfronthosting.co.za> Derek Wilson added the comment: It is worth noting that the do exist some domains that have been registered in the past that work with IDNA2003 but not IDNA2008. There definitely needs to be IDNA2008 support, for my use case I need to attempt IDNA2008 and then fall back to IDNA2003. When support for IDNA2008 is added, please retain support for IDNA2003. I would say that ideally there would be a codec that could handle both - attempt to use IDNA2008 and on error fallback to idna2003. I realize this isn't "official" but it would certainly be useful. ---------- nosy: +underrun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 00:01:17 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Wed, 23 Apr 2014 22:01:17 +0000 Subject: [issue19385] dbm.dumb should be consistent when the database is closed In-Reply-To: <1382683121.03.0.174486602388.issue19385@psf.upfronthosting.co.za> Message-ID: <1398290477.36.0.405696527861.issue19385@psf.upfronthosting.co.za> Claudiu.Popa added the comment: gzip uses the same name, _check_closed, but your suggestion sounds good. I'll update the patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 00:07:41 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 23 Apr 2014 22:07:41 +0000 Subject: [issue21331] Reversing an encoding with unicode-escape returns a different result In-Reply-To: <1398200303.74.0.876201125787.issue21331@psf.upfronthosting.co.za> Message-ID: <1398290861.82.0.291967315385.issue21331@psf.upfronthosting.co.za> R. David Murray added the comment: Using unicode_escape to decode non-ascii is simply wrong. It can't work. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 00:17:11 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 23 Apr 2014 22:17:11 +0000 Subject: [issue21331] Reversing an encoding with unicode-escape returns a different result In-Reply-To: <1398200303.74.0.876201125787.issue21331@psf.upfronthosting.co.za> Message-ID: <1398291431.63.0.582489831312.issue21331@psf.upfronthosting.co.za> R. David Murray added the comment: To understand why, understand that a byte string has no encoding inherent. So when you call b'utf8string'.decode('unicode_escape'), python has no way to know how to interpret the non-ascii characters in that bytestring. If you want the unicode_escape representation of something, you want to do 'string'.encode('unicode_escape'). If you then want that as a python string, you can do: 'mystring'.encode('unicode_escape').decode('ascii') In theory there ought to be a way to use the codecs module to go directly from unicode string to unicode-escaped string, but I don't know how to do it, since the proposal for the 'transform' method was rejected :) Just to bend your brain a bit further, note that this does work: >>> codecs.decode(codecs.encode('?', 'unicode-escape').decode('ascii'), 'unicode-escape') '?' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 00:19:16 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 23 Apr 2014 22:19:16 +0000 Subject: [issue21331] Reversing an encoding with unicode-escape returns a different result In-Reply-To: <1398200303.74.0.876201125787.issue21331@psf.upfronthosting.co.za> Message-ID: <1398291556.5.0.102947084817.issue21331@psf.upfronthosting.co.za> R. David Murray added the comment: Also, I'm not sure what this should do, but what it does do doesn't look right: >>> codecs.decode('?', 'unicode-escape') '??' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 00:38:07 2014 From: report at bugs.python.org (Jim Jewett) Date: Wed, 23 Apr 2014 22:38:07 +0000 Subject: [issue19385] dbm.dumb should be consistent when the database is closed In-Reply-To: <1382683121.03.0.174486602388.issue19385@psf.upfronthosting.co.za> Message-ID: <1398292687.67.0.277060879195.issue19385@psf.upfronthosting.co.za> Jim Jewett added the comment: I think the requested timing regression was for the non-broken case. When the database has NOT been closed, and keys() still works, will it be way slower than before? Note that I am not asking you to do that test (though the eventual committer might); the implementation of whichdb leaves me believing that almost anyone who is likely to care will have already followed the docunmentation's recommendation to install another *dbm ahead of dumb. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 00:38:31 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 23 Apr 2014 22:38:31 +0000 Subject: [issue2159] dbmmodule inquiry function is performance prohibitive In-Reply-To: <1203640875.82.0.736964888757.issue2159@psf.upfronthosting.co.za> Message-ID: <1398292711.28.0.24029909628.issue2159@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: First, Python 2.4 has been out of support for a really long time. Deleting. Eric, let me clarify the situation, because this report is old and I forgot the details. I think current situation is this, when doing something like "if db : DO_SOMETHING": a) If the database is closed, raise an exception. b) If database is empty, returns False. c) If database has any entry, returns True. Takes time proportional to database length, because it is going to go thru it. The patch you are proposing: a) If the database is closed, raise an exception. b) If database is empty, returns 0. c) If database has any entry, returns 1. Fast and simply checking if the database has at least a single record. Why 0/1 instead of True/False?. This is going to be a 3.5 patch, True/False are really there, they are not aliases. PS: When done, I will probably port this patch to current "pybsddb" work, although I am not sure that Berkeley DB has "firstkey" for all database types it support. Would you allow this porting, Eric? https://pypi.python.org/pypi/bsddb3/6.0.1 ---------- versions: -Python 2.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 00:47:28 2014 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 23 Apr 2014 22:47:28 +0000 Subject: [issue17552] socket.sendfile() In-Reply-To: <1364326073.47.0.699222209849.issue17552@psf.upfronthosting.co.za> Message-ID: <1398293248.2.0.28704365333.issue17552@psf.upfronthosting.co.za> Guido van Rossum added the comment: Can you also think about how this would be wrapped in asyncio? ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 01:01:34 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 23 Apr 2014 23:01:34 +0000 Subject: [issue16104] Compileall script: add option to use multiple cores In-Reply-To: <1349124414.14.0.0730954283721.issue16104@psf.upfronthosting.co.za> Message-ID: <1398294094.9.0.854710250624.issue16104@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- title: Use multiprocessing in compileall script -> Compileall script: add option to use multiple cores _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 01:29:32 2014 From: report at bugs.python.org (Thomas Kluyver) Date: Wed, 23 Apr 2014 23:29:32 +0000 Subject: [issue21338] Silent mode for compileall Message-ID: <1398295772.24.0.550494832702.issue21338@psf.upfronthosting.co.za> New submission from Thomas Kluyver: The compileall module's command line interface has a -q (quiet) flag which suppresses most of the output, but it still prints error messages. I'd like an entirely silent mode with no output. My use case is byte-compiling Python files as part of a graphical installer. I do this by running: py -${PY_QUALIFIER} -m compileall -q "$INSTDIR\pkgs" I'd like to be able to use pyw so a terminal doesn't pop up, but if I do that, it exits early. I think this is due to the issue with stdout/stderr buffers filling up on pythonw. ---------- components: Library (Lib) messages: 217100 nosy: takluyver priority: normal severity: normal status: open title: Silent mode for compileall _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 01:32:59 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 23 Apr 2014 23:32:59 +0000 Subject: [issue21324] dbhash leaks random memory fragments to a database In-Reply-To: <1398110084.7.0.0365348726476.issue21324@psf.upfronthosting.co.za> Message-ID: <1398295979.8.0.569587868471.issue21324@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: I could be wrong, but I think this is an Oracle Berkeley DB bug. I contacted Oracle yesterday about this. Stand by. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 01:33:33 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 23 Apr 2014 23:33:33 +0000 Subject: [issue21324] dbhash/bsddb leaks random memory fragments to a database In-Reply-To: <1398110084.7.0.0365348726476.issue21324@psf.upfronthosting.co.za> Message-ID: <1398296013.12.0.612119861592.issue21324@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- title: dbhash leaks random memory fragments to a database -> dbhash/bsddb leaks random memory fragments to a database _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 01:36:44 2014 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 23 Apr 2014 23:36:44 +0000 Subject: [issue21338] Silent mode for compileall In-Reply-To: <1398295772.24.0.550494832702.issue21338@psf.upfronthosting.co.za> Message-ID: <1398296204.29.0.377292083039.issue21338@psf.upfronthosting.co.za> Ezio Melotti added the comment: This seems a reasonable request. Do you want to propose a patch? ---------- keywords: +easy nosy: +ezio.melotti stage: -> needs patch type: -> enhancement versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 01:45:12 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 23 Apr 2014 23:45:12 +0000 Subject: [issue17442] code.InteractiveInterpreter doesn't display the exception cause In-Reply-To: <1363468664.92.0.794606977989.issue17442@psf.upfronthosting.co.za> Message-ID: <1398296712.6.0.388894652558.issue17442@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I am on the fence as to whether this should be treated as a bug fix or enhancement. Claudiu's pydev post gives this as the current InteractiveInterpreter behavior. ------------------------------ >>> try: ... 1 / 0 ... except ZeroDivisionError as exc: ... raise IOError from exc ... Traceback (most recent call last): File "", line 4, in OSError ----------------------------------- This certainly is not an exact emulation (given below), but is it severe enough to be a bug, and moreover, would fixing it break code? Again from Claudiu's post: with the patch. --------------------------------- >>> try: ... 1 / 0 ... except ZeroDivisionError as exc: ... raise IOError from exc ... Traceback (most recent call last): File "", line 2, in ZeroDivisionError: division by zero The above exception was the direct cause of the following exception: Traceback (most recent call last): File "", line 4, in OSError --------------------------------- I verified that this is exactly what 3.4.0 prints for interactive input, But... the Idle Shell also prints the above, plus it adds (or received from the user process) the offending code lines just as when the code is read from a file. ... File "", line 2, in 1 / 0 ZeroDivisionError: division by zero ... File "", line 4, in raise IOError from exc OSError Is there a reason the console interpreter cannot do the same? (Changing this would be a different issue, but one this would depend on.) ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 01:48:49 2014 From: report at bugs.python.org (Giampaolo Rodola') Date: Wed, 23 Apr 2014 23:48:49 +0000 Subject: [issue17552] socket.sendfile() In-Reply-To: <1364326073.47.0.699222209849.issue17552@psf.upfronthosting.co.za> Message-ID: <1398296929.22.0.467585544666.issue17552@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: I think asyncio would be better off using os.sendfile() / TransmitFile directly, in fact the current patch explicitly does not support non-blocking sockets (I couldn't see any sane approach to do that). Here's an example of how os.sendfile() should be used in an async manner: https://code.google.com/p/pyftpdlib/source/browse/tags/release-0.7.0/pyftpdlib/ftpserver.py#1035 asyncio should be doing something very similar to that and do the necessary stuff so that you can "yield from transport.sendfile(file)". Actually I can see what I can do in that regard after I'm finished with this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 02:45:14 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 24 Apr 2014 00:45:14 +0000 Subject: [issue21339] IDLE crash on OS X 1.9 upon shut-down with many windows open Message-ID: <1398300314.38.0.176461050226.issue21339@psf.upfronthosting.co.za> New submission from Raymond Hettinger: *** Internal Error: rpc.py:SocketIO.localcall() Object: gui_adapter Method: > Args: ('bug.py:1: ()', 4350545536, None) Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/rpc.py", line 188, in localcall ret = method(*args, **kwargs) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/RemoteDebugger.py", line 284, in interaction self.gui.interaction(message, frame, modified_info) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/Debugger.py", line 198, in interaction b.configure(state="disabled") File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk/Tkinter.py", line 1262, in configure return self._configure('configure', cnf, kw) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk/Tkinter.py", line 1253, in _configure self.tk.call(_flatten((self._w, cmd)) + self._options(cnf)) TclError: invalid command name ".4846984656.4846982712.4846983792" ---------- components: IDLE messages: 217105 nosy: rhettinger priority: normal severity: normal status: open title: IDLE crash on OS X 1.9 upon shut-down with many windows open versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 03:14:22 2014 From: report at bugs.python.org (Thomas Kluyver) Date: Thu, 24 Apr 2014 01:14:22 +0000 Subject: [issue21338] Silent mode for compileall In-Reply-To: <1398295772.24.0.550494832702.issue21338@psf.upfronthosting.co.za> Message-ID: <1398302062.79.0.34919268087.issue21338@psf.upfronthosting.co.za> Thomas Kluyver added the comment: Patch attached. This works by making the -q flag countable, so you pass -qq to suppress all output. In the Python API, the quiet parameter has become an integer, so passing 2 is equivalent to -qq. This should be fully backwards compatible with passing True and False, which are equivalent to 1 and 0. ---------- keywords: +patch type: enhancement -> Added file: http://bugs.python.org/file35012/compileall_silent.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 03:15:26 2014 From: report at bugs.python.org (Thomas Kluyver) Date: Thu, 24 Apr 2014 01:15:26 +0000 Subject: [issue21338] Silent mode for compileall In-Reply-To: <1398295772.24.0.550494832702.issue21338@psf.upfronthosting.co.za> Message-ID: <1398302126.26.0.525799498025.issue21338@psf.upfronthosting.co.za> Changes by Thomas Kluyver : Removed file: http://bugs.python.org/file35012/compileall_silent.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 03:15:38 2014 From: report at bugs.python.org (Steven D'Aprano) Date: Thu, 24 Apr 2014 01:15:38 +0000 Subject: [issue21338] Silent mode for compileall In-Reply-To: <1398295772.24.0.550494832702.issue21338@psf.upfronthosting.co.za> Message-ID: <1398302138.74.0.579754240751.issue21338@psf.upfronthosting.co.za> Steven D'Aprano added the comment: Can't you just re-direct stdout or stderr? I'm sure that works even on Windows. E.g. py -${PY_QUALIFIER} -m compileall -q "$INSTDIR\pkgs" 2> null Is there a reason you cannot do this? I think that adding functionality to compileall to duplicate what your OS already provides should be a last resort. I also don't understand what you mean by "it exits early". What exits early? Surely python doesn't exit until compileall finishes running. If it does, that's a bug. ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 03:26:54 2014 From: report at bugs.python.org (Thomas Kluyver) Date: Thu, 24 Apr 2014 01:26:54 +0000 Subject: [issue21338] Silent mode for compileall In-Reply-To: <1398295772.24.0.550494832702.issue21338@psf.upfronthosting.co.za> Message-ID: <1398302814.57.0.825596576778.issue21338@psf.upfronthosting.co.za> Thomas Kluyver added the comment: Sorry, I somehow attached an old version of the patch. This one should be correct. Steven: Redirection relies on a shell - the native 'run a process' interface that the installer uses can't do that. There are ways to work around this, but I think this approach makes sense. It exits early because stdout and stderr don't go anywhere, so once either of them has filled up a fairly small buffer, attempts to write to it throw an error. I'd love to see that fixed, but it's been known about for years (see issue 706263), and it seems unlikely to change any time soon. ---------- Added file: http://bugs.python.org/file35013/compileall_silent.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 03:28:27 2014 From: report at bugs.python.org (Thomas Kluyver) Date: Thu, 24 Apr 2014 01:28:27 +0000 Subject: [issue21338] Silent mode for compileall In-Reply-To: <1398295772.24.0.550494832702.issue21338@psf.upfronthosting.co.za> Message-ID: <1398302907.92.0.721949592247.issue21338@psf.upfronthosting.co.za> Changes by Thomas Kluyver : Removed file: http://bugs.python.org/file35013/compileall_silent.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 03:28:48 2014 From: report at bugs.python.org (Thomas Kluyver) Date: Thu, 24 Apr 2014 01:28:48 +0000 Subject: [issue21338] Silent mode for compileall In-Reply-To: <1398295772.24.0.550494832702.issue21338@psf.upfronthosting.co.za> Message-ID: <1398302928.02.0.219489416333.issue21338@psf.upfronthosting.co.za> Thomas Kluyver added the comment: Gah, still wrong. Trying again. ---------- Added file: http://bugs.python.org/file35014/compileall_silent.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 03:59:48 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 24 Apr 2014 01:59:48 +0000 Subject: [issue12489] email.errors.HeaderParseError if base64url is used In-Reply-To: <1309790300.23.0.111625308862.issue12489@psf.upfronthosting.co.za> Message-ID: <1398304788.54.0.832152672397.issue12489@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- components: +email nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 03:59:50 2014 From: report at bugs.python.org (Jim Jewett) Date: Thu, 24 Apr 2014 01:59:50 +0000 Subject: [issue19714] Add tests for importlib.machinery.WindowsRegistryFinder In-Reply-To: <1385139731.13.0.379714643713.issue19714@psf.upfronthosting.co.za> Message-ID: <1398304790.78.0.639743444938.issue19714@psf.upfronthosting.co.za> Jim Jewett added the comment: Pinging Martin ... earlier comments seem to have been completed. ---------- nosy: +Jim.Jewett _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 04:12:45 2014 From: report at bugs.python.org (Thomas Kluyver) Date: Thu, 24 Apr 2014 02:12:45 +0000 Subject: [issue21338] Silent mode for compileall In-Reply-To: <1398295772.24.0.550494832702.issue21338@psf.upfronthosting.co.za> Message-ID: <1398305565.79.0.188792013433.issue21338@psf.upfronthosting.co.za> Thomas Kluyver added the comment: In fact, I will probably end up working around this anyway, because I'll have to support versions of Python without this fix for some time. So I don't feel strongly that it needs to go in, but I will do any revisions or changes requested if people think it would be useful. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 04:13:42 2014 From: report at bugs.python.org (Jack Murray) Date: Thu, 24 Apr 2014 02:13:42 +0000 Subject: [issue21340] Possible bug in asyncio Message-ID: <1398305622.34.0.507325141901.issue21340@psf.upfronthosting.co.za> New submission from Jack Murray: AttributeError in /usr/lib/python3.4/asyncio/tasks.py feels like it might be a concurrency issue. I can't reproduce it, and my python isn't good enough to know how to simulate raising the exception at a random time during the execution of the program. Here's the PoC: import asyncio import sys from asyncio import async import time import random asyncio.tasks._DEBUG = True loop = asyncio.get_event_loop() def read_something(): print(input()) @asyncio.coroutine def func(arg): while True: sys.stdout.write("\rtest"+str(arg)) yield from asyncio.sleep(0) loop.add_reader(sys.stdin, read_something) loop.call_soon(async, func(1)) loop.call_soon(async, func(2)) loop.call_soon(async, func(3)) loop.call_soon(async, func(4)) time.sleep(1) try: loop.run_forever() except KeyboardInterrupt: print("handled\n") pass finally: pass and here is the stack trace: ktn:~/ $ python asynctest.py [11:55:03] test3^Chandled Future/Task exception was never retrieved future: Task() Traceback (most recent call last): File "asynctest.py", line 29, in loop.run_forever() File "/usr/lib/python3.4/asyncio/base_events.py", line 184, in run_forever self._run_once() File "/usr/lib/python3.4/asyncio/base_events.py", line 800, in _run_once handle._run() File "/usr/lib/python3.4/asyncio/events.py", line 39, in _run self._callback(*self._args) File "/usr/lib/python3.4/asyncio/tasks.py", line 337, in _wakeup self._step(value, None) File "/usr/lib/python3.4/asyncio/tasks.py", line 283, in _step result = next(coro) File "/usr/lib/python3.4/asyncio/tasks.py", line 50, in __next__ return next(self.gen) File "asynctest.py", line 18, in func yield from asyncio.sleep(0) File "/usr/lib/python3.4/asyncio/tasks.py", line 94, in wrapper w = CoroWrapper(coro(*args, **kwds), func) File "/usr/lib/python3.4/asyncio/tasks.py", line 42, in __init__ assert inspect.isgenerator(gen), gen KeyboardInterrupt Exception ignored in: > Traceback (most recent call last): File "/usr/lib/python3.4/asyncio/tasks.py", line 62, in __del__ frame = self.gen.gi_frame AttributeError: gen ---------- messages: 217112 nosy: Jack.Murray priority: normal severity: normal status: open title: Possible bug in asyncio versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 04:15:14 2014 From: report at bugs.python.org (Jack Murray) Date: Thu, 24 Apr 2014 02:15:14 +0000 Subject: [issue21340] Possible concurrency bug in asyncio, AttributeError in tasks.py In-Reply-To: <1398305622.34.0.507325141901.issue21340@psf.upfronthosting.co.za> Message-ID: <1398305714.31.0.382765829434.issue21340@psf.upfronthosting.co.za> Changes by Jack Murray : ---------- title: Possible bug in asyncio -> Possible concurrency bug in asyncio, AttributeError in tasks.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 05:38:55 2014 From: report at bugs.python.org (James Brewer) Date: Thu, 24 Apr 2014 03:38:55 +0000 Subject: [issue16827] Remove the relatively advanced content from section 2 in tutorial In-Reply-To: <1356964896.19.0.673901752517.issue16827@psf.upfronthosting.co.za> Message-ID: <1398310735.63.0.346967311527.issue16827@psf.upfronthosting.co.za> James Brewer added the comment: It seems like this issue lost traction, so I decided to go ahead and apply Eric's feedback. I've attached the relevant patch. With that said, I agree with Senthil that sections 2.2.4 and 2.2.5 would be better off between sections 13.1 and 13.2 ---------- nosy: +brwr Added file: http://bugs.python.org/file35015/tutorial-docs-update.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 06:12:12 2014 From: report at bugs.python.org (Barron) Date: Thu, 24 Apr 2014 04:12:12 +0000 Subject: [issue21341] Configuring 'font' with ttk.Style for 'TEntry' does not change displayed font Message-ID: <1398312732.28.0.174880904692.issue21341@psf.upfronthosting.co.za> New submission from Barron: After using the configure() method of a ttk.Style object to configure the font of TEntry, Entry widgets will still have the original default font. The following 6 lines will demonstrate this in IDLE: >>> from tkinter import ttk >>> s = ttk.Style() >>> s.configure('TButton', font = ('Courier', 24)) >>> s.configure('TEntry', font = ('Courier', 24)) >>> ttk.Button(text = 'Button').pack() >>> ttk.Entry().pack() The Button will be displayed using the newly configured font, but the Entry widget will retain the default font. Calling the lookup() method after the above code reveals the following: >>> s.lookup('TEntry', 'font') 'Courier 24' This shows that the font property for TEntry is getting set properly, but it is not being displayed. Configuring the font property directly on individual Entry widgets does display correctly. ---------- components: Tkinter messages: 217114 nosy: barron priority: normal severity: normal status: open title: Configuring 'font' with ttk.Style for 'TEntry' does not change displayed font type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 06:58:41 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Thu, 24 Apr 2014 04:58:41 +0000 Subject: [issue17442] code.InteractiveInterpreter doesn't display the exception cause In-Reply-To: <1363468664.92.0.794606977989.issue17442@psf.upfronthosting.co.za> Message-ID: <1398315521.72.0.176307325224.issue17442@psf.upfronthosting.co.za> Claudiu.Popa added the comment: Python's interactive interpreter doesn't show the offending code lines too. And given the fact that code.InteractiveInterpreter tries to be an emulation of the default interpreter, first the change should be addressed directly there, I think. But I agree that it could be useful. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 07:11:39 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Thu, 24 Apr 2014 05:11:39 +0000 Subject: [issue19385] dbm.dumb should be consistent when the database is closed In-Reply-To: <1382683121.03.0.174486602388.issue19385@psf.upfronthosting.co.za> Message-ID: <1398316299.3.0.709140559581.issue19385@psf.upfronthosting.co.za> Claudiu.Popa added the comment: On my machine I get the following results for the unclosed-database case. With patch: # ./python -S -m timeit -n 100000 -s "import dbm.dumb as dbm; d=dbm.open('x.dat', 'c');len(d)" 100000 loops, best of 3: 0.0638 usec per loop Without patch: # ./python -S -m timeit -n 100000 -s "import dbm.dumb as dbm; d=dbm.open('x.dat', 'c');len(d)" 100000 loops, best of 3: 0.0634 usec per loop ---------- Added file: http://bugs.python.org/file35016/issue19385_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 07:49:02 2014 From: report at bugs.python.org (Phil Connell) Date: Thu, 24 Apr 2014 05:49:02 +0000 Subject: [issue7757] sys.path is incorrect when prefix is "" In-Reply-To: <1264178776.01.0.552667161926.issue7757@psf.upfronthosting.co.za> Message-ID: <1398318542.04.0.973707049738.issue7757@psf.upfronthosting.co.za> Changes by Phil Connell : ---------- nosy: +pconnell _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 07:52:19 2014 From: report at bugs.python.org (Phil Connell) Date: Thu, 24 Apr 2014 05:52:19 +0000 Subject: [issue19533] Unloading docstrings from memory if -OO is given In-Reply-To: <1383980059.61.0.697157457336.issue19533@psf.upfronthosting.co.za> Message-ID: <1398318739.29.0.103981905056.issue19533@psf.upfronthosting.co.za> Changes by Phil Connell : ---------- nosy: +pconnell _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 07:53:41 2014 From: report at bugs.python.org (Phil Connell) Date: Thu, 24 Apr 2014 05:53:41 +0000 Subject: [issue17277] incorrect line numbers in backtrace after removing a trace function In-Reply-To: <1361551369.14.0.772985934528.issue17277@psf.upfronthosting.co.za> Message-ID: <1398318821.21.0.378917029753.issue17277@psf.upfronthosting.co.za> Changes by Phil Connell : ---------- nosy: +pconnell _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 07:57:03 2014 From: report at bugs.python.org (Phil Connell) Date: Thu, 24 Apr 2014 05:57:03 +0000 Subject: [issue12154] PyDoc Partial Functions In-Reply-To: <1306142131.82.0.401706336814.issue12154@psf.upfronthosting.co.za> Message-ID: <1398319023.19.0.332752068964.issue12154@psf.upfronthosting.co.za> Changes by Phil Connell : ---------- nosy: +pconnell _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 08:00:51 2014 From: report at bugs.python.org (Steinn Steinsen) Date: Thu, 24 Apr 2014 06:00:51 +0000 Subject: [issue21342] multiprocessing RLock and Lock raise incorrect exceptions when releasing an unlocked lock. Message-ID: <1398319251.34.0.871128764935.issue21342@psf.upfronthosting.co.za> New submission from Steinn Steinsen: In the documentation of multiprocessing the locks, RLock and Lock, are said to be clones of their respective threading synchronization primitives. There is an inconsistency in what exceptions are raised when an unlocked lock is released. According to the threading documentation a RuntimeError should be raised. Lock.release raises ValueError RLock.release raises AssertionError Tested this in python 2.7, 3.2, 3.4, 3.5 and broken in all those versions. The attached patch fixes this for 3.5 ---------- components: Library (Lib) files: release_exceptions.patch keywords: patch messages: 217117 nosy: steinn priority: normal severity: normal status: open title: multiprocessing RLock and Lock raise incorrect exceptions when releasing an unlocked lock. type: behavior versions: Python 2.7, Python 3.2, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file35017/release_exceptions.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 08:20:06 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Thu, 24 Apr 2014 06:20:06 +0000 Subject: [issue16104] Compileall script: add option to use multiple cores In-Reply-To: <1349124414.14.0.0730954283721.issue16104@psf.upfronthosting.co.za> Message-ID: <1398320406.08.0.204508959816.issue16104@psf.upfronthosting.co.za> Claudiu.Popa added the comment: Added a new version of the patch which incorporates suggestions made by Jim. Thanks for the review! ---------- Added file: http://bugs.python.org/file35018/issue16104_8.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 08:40:22 2014 From: report at bugs.python.org (Matt Bachmann) Date: Thu, 24 Apr 2014 06:40:22 +0000 Subject: [issue21343] os.path.relpath returns inconsistent types Message-ID: <1398321622.3.0.761606734891.issue21343@psf.upfronthosting.co.za> New submission from Matt Bachmann: I noticed an issue passing in unicode to os.path.relpath. Specifically that in some cases when passing in unicode I would get back unicode and others I would get back a string. Below I demonstrate the issue. I also attached a patch. Is this an issue or am I misunderstanding something. Is the patch reasonable? Totally willing to improve and i'll admit I cannot test the ntpath version. Python 2.7.6 (default, Apr 9 2014, 11:48:52) [GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.38)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.path.relpath(u'.', u'.') '.' >>> os.path.relpath(u'.', u'../') u'bachmann' ---------- components: Library (Lib) files: reldir.patch keywords: patch messages: 217119 nosy: Matt.Bachmann priority: normal severity: normal status: open title: os.path.relpath returns inconsistent types type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file35019/reldir.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 09:02:02 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 24 Apr 2014 07:02:02 +0000 Subject: [issue17552] socket.sendfile() In-Reply-To: <1398273998.89.0.0627946596294.issue17552@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: >> A useful parameter instead would be to support sending only part of the file, >> so adding a count argument. > > Have you read my patch? This is already provided by the "offset" parameter. Of course I read your patch ;-) I mean I'd like a parameter for the offset, and another one for the number of bytes to send, like in Java's version (and sendfile(), see below). >> I really don't like the blocksize argument. >> I've *never* seen code which explicitly uses a blocksize > > Both sendfile() and TransmitFile provide a "blocksize" parameter for very good reasons therefore it seems natural that an API built on top of them exposes the same parameter as well. No, they expose a *count* parameter: http://linux.die.net/man/2/sendfile """ ssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count); count is the number of bytes to copy between the file descriptors. """ You're mixing up blocksize, which is the maximum number of bytes to transfer in one syscall and only makes sense in the context of repeated syscalls, and count, which is the total amount of data you want the function to transfer. No sensible sendfile-like API exposes a maximum "blocksize" to send at once, since the goal is to limit copies and system calls: you just pass a source and destination FD, a starting offset, and a number of bytes to transfer, and the syscall takes care of the rest. Here, you basically implement sendall() on top of sendfile() (in pseudo-code, using a buffer instead of a file and not taking into account short writes but the idea if the same): while : socket.sendfile(data[offset:offset+chunksize) The way it's supposed to be used is simply: socket.sendfile(data[offset:offset+count]) That's how everyone one uses sendfile(), that's how Java exposes it, and that's IMO how it should be exposed. To sum up, I think there's a fundamental confusion between blocksize and count in this API: that's what I've been saying since the beginning of this thread: if you disagree, that's OK, I just want to make sure we're talking about the same thing ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 13:05:12 2014 From: report at bugs.python.org (akira) Date: Thu, 24 Apr 2014 11:05:12 +0000 Subject: [issue17552] socket.sendfile() In-Reply-To: <1364326073.47.0.699222209849.issue17552@psf.upfronthosting.co.za> Message-ID: <1398337512.93.0.0576959624036.issue17552@psf.upfronthosting.co.za> akira added the comment: use_fallback parameter is mostly a debugging tool. If it helps to avoid the indecision; I would side with neologix' remarks and also suggest to drop the use_fallback parameter. It seems the patch assumes *offset == nbytes_sent* that is false in general e.g., if offset > 0 at the start of the function. :: _SEND_BLOCKSIZE = 262144 # ??? def sendfile(self, file, offset=None, nbytes=None, *, nbytes_per_send=_SEND_BLOCKSIZE) -> nbytes_sent: """ Send *nbytes* bytes from regular *file* starting at *offset* position. Return the number of bytes sent. If *offset* is ``None``; start at the current file position. If *nbytes* is ``None``; send file until EOF is reached. The socket should be connection-oriented e.g., SOCK_STREAM *nbytes_per_send* is used by a *send()*-based fallback code. *os.sendfile()* ignores it. - if socket is blocking (timeout is None) then it may keep trying to send data until an error occurs. Even on success it may return less than *nbytes* if there is not enough data available in *file*. - if socket is non-blocking and timeout == 0 then fail if even a single byte can't be sent immediately - if socket has timeout > 0 then raise the timeout error if more than *timeout* seconds pass since the call is started and nothing is sent i.e., use a single deadline for all system calls (like *socket.send()*). If timeout is not None then *socket.sendfile()* may send less bytes than specified. *file* position after the call is unspecified. """ # pseudo-code total = 0 if offset is None offset = file.tell() if nbytes is None: nbytes = os.path.getsize(file.name) interval = self.timeout if interval is not None: deadline = now() + interval while select([], [self], [], interval)[1]: # writable try: sent = os.sendfile(self, file, offset, nbytes) except BlockingIOError as e: assert getattr(e, 'characters_written', 0) == 0 if interval is not None: # update interval interval = deadline - now() if interval < 0: break continue # ignore else: if sent == 0: return total total += sent offset += sent nbytes -= sent if nbytes == 0: return total if interval is not None: # update interval interval = deadline - now() if interval < 0: break # timeout if total == 0: raise TimeoutError else: return total ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 14:13:30 2014 From: report at bugs.python.org (Milan Oberkirch) Date: Thu, 24 Apr 2014 12:13:30 +0000 Subject: [issue20098] email policy needs a mangle_from setting In-Reply-To: <1388446517.27.0.863185292033.issue20098@psf.upfronthosting.co.za> Message-ID: <1398341610.53.0.666745169698.issue20098@psf.upfronthosting.co.za> Milan Oberkirch added the comment: Updated the last patch according to the review comments at https://bugs.python.org/review/20098/. ---------- Added file: http://bugs.python.org/file35020/mangle_from_20140424.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 14:24:14 2014 From: report at bugs.python.org (Milan Oberkirch) Date: Thu, 24 Apr 2014 12:24:14 +0000 Subject: [issue20098] email policy needs a mangle_from setting In-Reply-To: <1388446517.27.0.863185292033.issue20098@psf.upfronthosting.co.za> Message-ID: <1398342254.21.0.0383140780823.issue20098@psf.upfronthosting.co.za> Changes by Milan Oberkirch : Added file: http://bugs.python.org/file35021/mangle_from_20140424.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 14:24:26 2014 From: report at bugs.python.org (Milan Oberkirch) Date: Thu, 24 Apr 2014 12:24:26 +0000 Subject: [issue20098] email policy needs a mangle_from setting In-Reply-To: <1388446517.27.0.863185292033.issue20098@psf.upfronthosting.co.za> Message-ID: <1398342266.98.0.996577107667.issue20098@psf.upfronthosting.co.za> Changes by Milan Oberkirch : Removed file: http://bugs.python.org/file35020/mangle_from_20140424.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 16:42:12 2014 From: report at bugs.python.org (Russell Ballestrini) Date: Thu, 24 Apr 2014 14:42:12 +0000 Subject: [issue21344] save scores or ratios in difflib get_close_matches Message-ID: <1398350530.77.0.0668395281532.issue21344@psf.upfronthosting.co.za> New submission from Russell Ballestrini: The current implementation of difflib's get_close_matches() function computes computationally complex scores (ratios) but then tosses them out without giving the end-user the chance to have at them. This patch adds an optional "scores" boolean argument that may be passed to alter the return output from a list of words, to a list of (score, word) tuples. ---------- components: Library (Lib) files: difflib.py messages: 217123 nosy: russellballestrini priority: normal severity: normal status: open title: save scores or ratios in difflib get_close_matches type: enhancement versions: Python 2.7, Python 3.5 Added file: http://bugs.python.org/file35022/difflib.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 16:52:53 2014 From: report at bugs.python.org (Russell Ballestrini) Date: Thu, 24 Apr 2014 14:52:53 +0000 Subject: [issue21344] save scores or ratios in difflib get_close_matches In-Reply-To: <1398350530.77.0.0668395281532.issue21344@psf.upfronthosting.co.za> Message-ID: <1398351173.29.0.949305134606.issue21344@psf.upfronthosting.co.za> Changes by Russell Ballestrini : Removed file: http://bugs.python.org/file35022/difflib.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 16:53:57 2014 From: report at bugs.python.org (Russell Ballestrini) Date: Thu, 24 Apr 2014 14:53:57 +0000 Subject: [issue21344] save scores or ratios in difflib get_close_matches In-Reply-To: <1398350530.77.0.0668395281532.issue21344@psf.upfronthosting.co.za> Message-ID: <1398351237.4.0.801843742713.issue21344@psf.upfronthosting.co.za> Changes by Russell Ballestrini : ---------- keywords: +patch Added file: http://bugs.python.org/file35023/difflib-patch-to-save-scores-in-get-close-matches.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 16:58:45 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Thu, 24 Apr 2014 14:58:45 +0000 Subject: [issue21344] save scores or ratios in difflib get_close_matches In-Reply-To: <1398350530.77.0.0668395281532.issue21344@psf.upfronthosting.co.za> Message-ID: <1398351525.06.0.599164834915.issue21344@psf.upfronthosting.co.za> Claudiu.Popa added the comment: It would be easier to review your patch if you'll upload it as a proper patch. Usually for these cases (modifying the return by passing a specific argument) it's best to provide a new function with this functionality, by having get_close_matches and get_scored_close_matches (for instance), which returns the modified result. ---------- nosy: +Claudiu.Popa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 16:59:59 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Thu, 24 Apr 2014 14:59:59 +0000 Subject: [issue21344] save scores or ratios in difflib get_close_matches In-Reply-To: <1398350530.77.0.0668395281532.issue21344@psf.upfronthosting.co.za> Message-ID: <1398351599.67.0.955904454673.issue21344@psf.upfronthosting.co.za> Claudiu.Popa added the comment: Ah, nevermind my first comment. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 17:08:08 2014 From: report at bugs.python.org (Russell Ballestrini) Date: Thu, 24 Apr 2014 15:08:08 +0000 Subject: [issue21344] save scores or ratios in difflib get_close_matches In-Reply-To: <1398350530.77.0.0668395281532.issue21344@psf.upfronthosting.co.za> Message-ID: <1398352088.87.0.549498782884.issue21344@psf.upfronthosting.co.za> Russell Ballestrini added the comment: Claudiu.Popa, Yes, that was my first idea on how to tackle this issue. I will create another proper patch that prepares two separate functions: * get_close_matches * get_scored_close_matches Where each are basically wrapper / API functions around a private function that holds the algorithm: * _get_scored_close_matches ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 17:53:00 2014 From: report at bugs.python.org (Russell Ballestrini) Date: Thu, 24 Apr 2014 15:53:00 +0000 Subject: [issue21344] save scores or ratios in difflib get_close_matches In-Reply-To: <1398350530.77.0.0668395281532.issue21344@psf.upfronthosting.co.za> Message-ID: <1398354780.97.0.209054029843.issue21344@psf.upfronthosting.co.za> Russell Ballestrini added the comment: New function in difflib: get_scored_matches() This function acts just like the existing get_close_matches() function however instead of returning a list of words, it returns a list of tuples (score, word) pairs. This gives the end-user the ability to access the computationally expensive scores/ratios produced as a by-product. The new usage does _not_ impact backward compatibility:: >>> import difflib >>> import keyword as _keyword >>> difflib.get_scored_matches("wheel", _keyword.kwlist) [(0.6, 'while')] >>> difflib.get_close_matches("wheel", _keyword.kwlist) ['while'] HG: Enter commit message. Lines beginning with 'HG:' are removed. HG: Leave message empty to abort commit. HG: -- HG: user: RussellBallestrini HG: branch 'default' changed Lib/difflib.py ---------- Added file: http://bugs.python.org/file35024/difflib-patch-to-save-scores-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 17:56:50 2014 From: report at bugs.python.org (Giampaolo Rodola') Date: Thu, 24 Apr 2014 15:56:50 +0000 Subject: [issue17552] socket.sendfile() In-Reply-To: <1364326073.47.0.699222209849.issue17552@psf.upfronthosting.co.za> Message-ID: <1398355010.3.0.612729909059.issue17552@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: > [...] I'd like a parameter for the offset, and another one for the > number of bytes to send. > To sum up, I think there's a fundamental confusion between blocksize > and count in this API. Ah OK, I see what you mean now. If seems we didn't understand each other. =) And yes, I suppose you're right: if possible we should pass a high value and let sendfile() do its thing. Note that we still have to implement an internal loop ourselves though because if the socket has a timeout sendfile() will return before EOF (I've checked this just now). As for what to do, here's what I propose: - we provide a blocksize argument defaulting to None - in case of send() and blocksize == None we set it to 262144 - in case of sendfile() we set it to a very high value (4M or something) - using os.path.getsize(file.name) looks risky to me as the user might have changed CWD in the meantime or something I'm -1 about adding "count" *and* "blocksize" parameters. "blocksize" alone is good enough IMO and considering what I've just described it is a better name than "count". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 18:02:44 2014 From: report at bugs.python.org (Johannes Baiter) Date: Thu, 24 Apr 2014 16:02:44 +0000 Subject: [issue21345] multiprocessing.Pool._handle_workers sleeps too long Message-ID: <1398355364.53.0.447682013962.issue21345@psf.upfronthosting.co.za> New submission from Johannes Baiter: While testing a module that uses multiprocessing.Pool to distribute load across multiple processes, I noticed that my test suite was copmleting very quickly (~0.15s) on Python 2.6, while Python 2.7 and above took around 10x as long (~1.6s). Upon debugging this, I pinned the slowdown down to the 'Pool.join()' method. Removing it removed the slowdown almost completely. I then checked the version history of the 'multiprocessing.pool' module between 2.6 and 2.7 and noticed that when the 'maxtasksperchild' parameter was introduced, a thread to handle the workers was introduced, which was 'join()'ed when the pool was joined. This is the function that is executed in the thread (from latest CPython checkout): @staticmethod def _handle_workers(pool): thread = threading.current_thread() # Keep maintaining workers until the cache gets drained, unless the pool # is terminated. while thread._state == RUN or (pool._cache and thread._state != TERMINATE): pool._maintain_pool() time.sleep(0.1) # <-- Cause of slow 'join()' after 2.6 # send sentinel to stop workers pool._taskqueue.put(None) util.debug('worker handler exiting') I highlighted the portion that makes 'join()' take a rather long time with short-lived processes in Python 2.7 and greater. Replacing it with 'time.sleep(0)' (as is done in '_help_stuff_finish()' later in the module) makes joining go as fast as in 2.6. Is there a specific reason why this sleep period was chosen? ---------- components: Library (Lib) messages: 217129 nosy: Johannes.Baiter priority: normal severity: normal status: open title: multiprocessing.Pool._handle_workers sleeps too long type: performance versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 18:04:03 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Thu, 24 Apr 2014 16:04:03 +0000 Subject: [issue21344] save scores or ratios in difflib get_close_matches In-Reply-To: <1398350530.77.0.0668395281532.issue21344@psf.upfronthosting.co.za> Message-ID: <1398355443.81.0.257627452045.issue21344@psf.upfronthosting.co.za> Claudiu.Popa added the comment: Your patch needs tests and documentation update. For examples, you could look in test_difflib.py and see how get_close_matches is tested. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 18:12:43 2014 From: report at bugs.python.org (Zachary Ware) Date: Thu, 24 Apr 2014 16:12:43 +0000 Subject: [issue21344] save scores or ratios in difflib get_close_matches In-Reply-To: <1398350530.77.0.0668395281532.issue21344@psf.upfronthosting.co.za> Message-ID: <1398355963.92.0.846824222872.issue21344@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- stage: -> patch review versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 18:14:04 2014 From: report at bugs.python.org (Russell Ballestrini) Date: Thu, 24 Apr 2014 16:14:04 +0000 Subject: [issue21344] save scores or ratios in difflib get_close_matches In-Reply-To: <1398350530.77.0.0668395281532.issue21344@psf.upfronthosting.co.za> Message-ID: <1398356044.37.0.94496085361.issue21344@psf.upfronthosting.co.za> Russell Ballestrini added the comment: get_close_matches() doesn't seem to have any tests... I suppose I should write them considering I'm changing the functionality a bit. TODO: write tests for * difflib.get_close_matches() * difflib.get_scored_matches() Determine if docstrings are enough to document the new function. (I thought it would be) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 19:13:38 2014 From: report at bugs.python.org (Zachary Ware) Date: Thu, 24 Apr 2014 17:13:38 +0000 Subject: [issue21344] save scores or ratios in difflib get_close_matches In-Reply-To: <1398350530.77.0.0668395281532.issue21344@psf.upfronthosting.co.za> Message-ID: <1398359618.15.0.921065452107.issue21344@psf.upfronthosting.co.za> Zachary Ware added the comment: Russell Ballestrini wrote: > Determine if docstrings are enough to document the new function. No, Doc/library/difflib.rst will need an update. (Btw, I removed 2.7 from versions because 2.7 is not open to new features, bugs and security-critical enhancements only.) ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 19:15:23 2014 From: report at bugs.python.org (Berker Peksag) Date: Thu, 24 Apr 2014 17:15:23 +0000 Subject: [issue21340] Possible concurrency bug in asyncio, AttributeError in tasks.py In-Reply-To: <1398305622.34.0.507325141901.issue21340@psf.upfronthosting.co.za> Message-ID: <1398359723.32.0.208580802961.issue21340@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +giampaolo.rodola, gvanrossum, haypo, pitrou, yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 19:31:25 2014 From: report at bugs.python.org (Brian Kearns) Date: Thu, 24 Apr 2014 17:31:25 +0000 Subject: [issue21346] typos in test_itertools.py Message-ID: <1398360685.46.0.636868722693.issue21346@psf.upfronthosting.co.za> Changes by Brian Kearns : ---------- files: test_itertools_typos-py27.patch keywords: patch nosy: bdkearns priority: normal severity: normal status: open title: typos in test_itertools.py type: enhancement versions: Python 2.7 Added file: http://bugs.python.org/file35025/test_itertools_typos-py27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 19:32:43 2014 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 24 Apr 2014 17:32:43 +0000 Subject: [issue21340] Possible concurrency bug in asyncio, AttributeError in tasks.py In-Reply-To: <1398305622.34.0.507325141901.issue21340@psf.upfronthosting.co.za> Message-ID: <1398360763.62.0.640406598891.issue21340@psf.upfronthosting.co.za> Guido van Rossum added the comment: Looks like there is a bug in CoroWrapper -- when the assert in __init__ fails, __del__ gets called imediately after and that triggers this traceback. However I'm not sure what causes the assert to fail -- it looks like this is coming from sleep(), which does not make sense to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 20:09:58 2014 From: report at bugs.python.org (Ned Deily) Date: Thu, 24 Apr 2014 18:09:58 +0000 Subject: [issue21342] multiprocessing RLock and Lock raise incorrect exceptions when releasing an unlocked lock. In-Reply-To: <1398319251.34.0.871128764935.issue21342@psf.upfronthosting.co.za> Message-ID: <1398362998.89.0.469897497722.issue21342@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 20:12:09 2014 From: report at bugs.python.org (Ned Deily) Date: Thu, 24 Apr 2014 18:12:09 +0000 Subject: [issue21345] multiprocessing.Pool._handle_workers sleeps too long In-Reply-To: <1398355364.53.0.447682013962.issue21345@psf.upfronthosting.co.za> Message-ID: <1398363129.98.0.0306514544027.issue21345@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 20:27:29 2014 From: report at bugs.python.org (Zachary Ware) Date: Thu, 24 Apr 2014 18:27:29 +0000 Subject: [issue21346] typos in test_itertools.py Message-ID: <1398364049.61.0.854948324492.issue21346@psf.upfronthosting.co.za> New submission from Zachary Ware: Fixed, thanks for the patch! changeset 90450:1beb3e0507fa 2.7 Issue #21346: Fix typos in test_itertools. Patch by Brian Kearns. changeset 90451:901b9afc918e 3.4 Issue #21346: Fix typo, make message consistent in test_itertools. Pointed out by Brian Kearns. changeset 90452:21012515c249 default Closes #21346: Merge with 3.4 ---------- nosy: +zach.ware resolution: -> fixed stage: -> resolved status: open -> closed versions: +Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 20:44:59 2014 From: report at bugs.python.org (Sreepriya Chalakkal) Date: Thu, 24 Apr 2014 18:44:59 +0000 Subject: [issue19662] smtpd.py should not decode utf-8 In-Reply-To: <1384944703.82.0.967643613195.issue19662@psf.upfronthosting.co.za> Message-ID: <1398365099.32.0.89334379512.issue19662@psf.upfronthosting.co.za> Sreepriya Chalakkal added the comment: Hi Maciej, I am travelling now and it might take some delay for me to work on this! I got to know that you are working on RFC 6532. You might take this up and fix it as this is related to your work and I don't want to create delays. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 21:08:42 2014 From: report at bugs.python.org (akira) Date: Thu, 24 Apr 2014 19:08:42 +0000 Subject: [issue21347] Don't use a list argument together with shell=True in subprocess' docs Message-ID: <1398366522.65.0.954174735085.issue21347@psf.upfronthosting.co.za> New submission from akira: *Popen(["something"], shell=True)* works but it is similar to *Popen(["something", "arg"], shell=True)* that passes "arg" to /bin/sh on POSIX systems instead of "something". It is best to always use a string if `shell=True` is necessary. It is a common confusion #20344, msg98732, #7839 http://stackoverflow.com/questions/21029154/understanding-python-subprocess-check-outputs-first-argument-and-shell-true http://stackoverflow.com/questions/20787712/start-openoffice-process-with-python-to-use-with-pyuno-using-subprocess http://stackoverflow.com/questions/17880847/python-subprocess-error-in-using-cp http://stackoverflow.com/questions/17226912/why-does-simple-echo-in-subprocess-not-working http://stackoverflow.com/questions/15109665/subprocess-call-using-string-vs-using-list http://stackoverflow.com/questions/20128114/pythons-subprocess-does-not-interpret-as-expected-on-cygwin http://stackoverflow.com/questions/16840427/python-on-linux-subprocess-popen-works-weird-with-shell-true ... ---------- assignee: docs at python components: Documentation files: docs-subprocess-dont_use_list_with_shell_true.patch keywords: patch messages: 217136 nosy: akira, docs at python priority: normal severity: normal status: open title: Don't use a list argument together with shell=True in subprocess' docs type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file35026/docs-subprocess-dont_use_list_with_shell_true.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 21:48:08 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 24 Apr 2014 19:48:08 +0000 Subject: [issue21344] save scores or ratios in difflib get_close_matches In-Reply-To: <1398350530.77.0.0668395281532.issue21344@psf.upfronthosting.co.za> Message-ID: <1398368888.63.0.397796780702.issue21344@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- nosy: +tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 22:07:48 2014 From: report at bugs.python.org (stoyanov) Date: Thu, 24 Apr 2014 20:07:48 +0000 Subject: [issue9291] mimetypes initialization fails on Windows because of non-Latin characters in registry In-Reply-To: <1279454095.41.0.733053669611.issue9291@psf.upfronthosting.co.za> Message-ID: <1398370068.34.0.392625275821.issue9291@psf.upfronthosting.co.za> stoyanov added the comment: Alternative temporary solution def enum_types(mimedb): .... try: ctype = ctype.encode(default_encoding) # omit in 3.x! except UnicodeEncodeError: pass except Exception: #<-- pass #<-- else: yield ctype ---------- nosy: +quick.es _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 22:54:05 2014 From: report at bugs.python.org (Russell Ballestrini) Date: Thu, 24 Apr 2014 20:54:05 +0000 Subject: [issue21344] save scores or ratios in difflib get_close_matches In-Reply-To: <1398350530.77.0.0668395281532.issue21344@psf.upfronthosting.co.za> Message-ID: <1398372845.28.0.815525912289.issue21344@psf.upfronthosting.co.za> Changes by Russell Ballestrini : Removed file: http://bugs.python.org/file35023/difflib-patch-to-save-scores-in-get-close-matches.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 23:37:55 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Thu, 24 Apr 2014 21:37:55 +0000 Subject: [issue9731] Add ABCMeta.has_methods and tests that use it In-Reply-To: <1283346153.7.0.611629242062.issue9731@psf.upfronthosting.co.za> Message-ID: <1398375475.78.0.266485427848.issue9731@psf.upfronthosting.co.za> Claudiu.Popa added the comment: I have updated the previous patch, by documenting the new class method. ---------- versions: +Python 3.5 -Python 3.4 Added file: http://bugs.python.org/file35027/issue9731.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 24 23:48:00 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 24 Apr 2014 21:48:00 +0000 Subject: [issue8297] AttributeError message text should include module name In-Reply-To: <1270272607.93.0.943961280816.issue8297@psf.upfronthosting.co.za> Message-ID: <3gFBvg3fKNz7Ljh@mail.python.org> Roundup Robot added the comment: New changeset d84a69b7ba72 by Ethan Furman in branch 'default': Issue8297: module attribute lookup failures now include module name in error message. http://hg.python.org/cpython/rev/d84a69b7ba72 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 25 00:12:12 2014 From: report at bugs.python.org (paul j3) Date: Thu, 24 Apr 2014 22:12:12 +0000 Subject: [issue11874] argparse assertion failure with brackets in metavars In-Reply-To: <1303201252.58.0.236363581255.issue11874@psf.upfronthosting.co.za> Message-ID: <1398377532.14.0.596757558858.issue11874@psf.upfronthosting.co.za> Changes by paul j3 : Added file: http://bugs.python.org/file35028/format_usage.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 25 00:12:27 2014 From: report at bugs.python.org (paul j3) Date: Thu, 24 Apr 2014 22:12:27 +0000 Subject: [issue11874] argparse assertion failure with brackets in metavars In-Reply-To: <1303201252.58.0.236363581255.issue11874@psf.upfronthosting.co.za> Message-ID: <1398377547.85.0.0983252297746.issue11874@psf.upfronthosting.co.za> Changes by paul j3 : Removed file: http://bugs.python.org/file30941/format_usage.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 25 01:42:29 2014 From: report at bugs.python.org (Cris) Date: Thu, 24 Apr 2014 23:42:29 +0000 Subject: [issue21348] File "C:\Python27\lib\distutils\msvc9compiler.py", line 295, in query_vcvarsal l raise ValueError(str(list(result.keys()))) ValueError: [u'path'] Message-ID: <1398382949.19.0.0972223942804.issue21348@psf.upfronthosting.co.za> New submission from Cris: I have Windows 8 64bit and Python 64bit (installed from here: https://www.python.org/ftp/python/2.7/python-2.7.amd64.msi) I also installed pywin32-214.win-amd64-py2.7 (from here http://downloads.sourceforge.net/project/pywin32/pywin32/Build%20214/pywin32-214.win-amd64-py2.7.exe?r=http%3A%2F%2Fsourceforge.net%2Fprojects%2Fpywin32%2Ffiles%2Fpywin32%2FBuild%2520214%2F&ts=1398376919&use_mirror=kent) When I try to install Scrapy it gives me this error: File "twisted\runner\topfiles\setup.py", line 14, in File ".\twisted\python\dist.py", line 413, in _check_header File ".\twisted\python\dist.py", line 399, in _compile_helper File "C:\Python27\lib\distutils\msvc9compiler.py", line 469, in compile self.initialize() File "C:\Python27\lib\distutils\msvc9compiler.py", line 379, in initialize vc_env = query_vcvarsall(VERSION, plat_spec) File "C:\Python27\lib\distutils\msvc9compiler.py", line 295, in query_vcvarsal l raise ValueError(str(list(result.keys()))) ValueError: [u'path'] How can I fix it? ---------- messages: 217140 nosy: Cris priority: normal severity: normal status: open title: File "C:\Python27\lib\distutils\msvc9compiler.py", line 295, in query_vcvarsal l raise ValueError(str(list(result.keys()))) ValueError: [u'path'] type: compile error versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 25 01:48:55 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 24 Apr 2014 23:48:55 +0000 Subject: [issue8297] AttributeError message text should include module name In-Reply-To: <1270272607.93.0.943961280816.issue8297@psf.upfronthosting.co.za> Message-ID: <1398383335.92.0.767322597484.issue8297@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 25 01:53:22 2014 From: report at bugs.python.org (=?utf-8?q?William_Tis=C3=A4ter?=) Date: Thu, 24 Apr 2014 23:53:22 +0000 Subject: [issue20962] Rather modest chunk size in gzip.GzipFile In-Reply-To: <1395082726.87.0.730756156096.issue20962@psf.upfronthosting.co.za> Message-ID: <1398383602.58.0.527558081815.issue20962@psf.upfronthosting.co.za> William Tis?ter added the comment: I played around with different file and chunk sizes using attached benchmark script. After several test runs I think 1024 * 16 would be the biggest win without losing too many ?s on small seeks. You can find my benchmark output here: https://gist.github.com/tiwilliam/11273483 My test data was generated with following commands: dd if=/dev/random of=10K bs=1024 count=10 dd if=/dev/random of=1M bs=1024 count=1000 dd if=/dev/random of=5M bs=1024 count=5000 dd if=/dev/random of=100M bs=1024 count=100000 dd if=/dev/random of=1000M bs=1024 count=1000000 gzip 10K 1M 5M 100M 1000M ---------- nosy: +tiwilliam Added file: http://bugs.python.org/file35029/benchmark_20962.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 25 02:14:09 2014 From: report at bugs.python.org (Ethan Furman) Date: Fri, 25 Apr 2014 00:14:09 +0000 Subject: [issue8297] AttributeError message text should include module name In-Reply-To: <1270272607.93.0.943961280816.issue8297@psf.upfronthosting.co.za> Message-ID: <1398384849.67.0.170305570885.issue8297@psf.upfronthosting.co.za> Ethan Furman added the comment: Yay, 'resolved' ! ---------- stage: patch review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 25 02:15:17 2014 From: report at bugs.python.org (Brian Kearns) Date: Fri, 25 Apr 2014 00:15:17 +0000 Subject: [issue21349] crash in winreg SetValueEx with memoryview Message-ID: <1398384916.2.0.500531469924.issue21349@psf.upfronthosting.co.za> Changes by Brian Kearns : ---------- files: fix_winreg_setvalueex-py27.patch keywords: patch nosy: bdkearns priority: normal severity: normal status: open title: crash in winreg SetValueEx with memoryview type: crash versions: Python 2.7 Added file: http://bugs.python.org/file35030/fix_winreg_setvalueex-py27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 25 02:16:12 2014 From: report at bugs.python.org (Brian Kearns) Date: Fri, 25 Apr 2014 00:16:12 +0000 Subject: [issue21349] crash in winreg SetValueEx with memoryview Message-ID: <1398384972.21.0.977216843335.issue21349@psf.upfronthosting.co.za> Changes by Brian Kearns : Removed file: http://bugs.python.org/file35030/fix_winreg_setvalueex-py27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 25 02:16:22 2014 From: report at bugs.python.org (Brian Kearns) Date: Fri, 25 Apr 2014 00:16:22 +0000 Subject: [issue21349] crash in winreg SetValueEx with memoryview Message-ID: <1398384982.19.0.98633768809.issue21349@psf.upfronthosting.co.za> Changes by Brian Kearns : Added file: http://bugs.python.org/file35031/fix_winreg_setvalueex-py27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 25 02:39:32 2014 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 25 Apr 2014 00:39:32 +0000 Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za> Message-ID: <1398386372.46.0.60777711432.issue18967@psf.upfronthosting.co.za> Changes by Ezio Melotti : Added file: http://bugs.python.org/file35032/newsmerge.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 25 02:39:43 2014 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 25 Apr 2014 00:39:43 +0000 Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za> Message-ID: <1398386383.72.0.0329078013804.issue18967@psf.upfronthosting.co.za> Changes by Ezio Melotti : Removed file: http://bugs.python.org/file35011/newsmerge.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 25 02:59:10 2014 From: report at bugs.python.org (akira) Date: Fri, 25 Apr 2014 00:59:10 +0000 Subject: [issue17552] socket.sendfile() In-Reply-To: <1364326073.47.0.699222209849.issue17552@psf.upfronthosting.co.za> Message-ID: <1398387550.76.0.34925915882.issue17552@psf.upfronthosting.co.za> akira added the comment: count and blocksize are completely different. *count* specifies how many bytes at most socket.sendfile should sent overall. It may change the result i.e., it may not be necessary that the file is read until EOF. It has the same meaning as *nbytes* parameter for os.sendfile or *nbytes* in msg217121 *blocksize* doesn't change how many bytes is read in the end by socket.sendfile. At most it may affect time performance. It is *nbytes_per_send* in msg217121 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 25 03:10:54 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 25 Apr 2014 01:10:54 +0000 Subject: [issue17552] socket.sendfile() In-Reply-To: <1364326073.47.0.699222209849.issue17552@psf.upfronthosting.co.za> Message-ID: <1398388254.29.0.630511539765.issue17552@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > I'm -1 about adding "count" *and* "blocksize" parameters. "blocksize" > alone is good enough IMO and considering what I've just described it > is a better name than "count". I'm confused. Why is "blocksize" necessary at all? > using os.path.getsize(file.name) looks risky to me Why not fstat(fd) ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 25 03:47:32 2014 From: report at bugs.python.org (Russell Ballestrini) Date: Fri, 25 Apr 2014 01:47:32 +0000 Subject: [issue21344] save scores or ratios in difflib get_close_matches In-Reply-To: <1398350530.77.0.0668395281532.issue21344@psf.upfronthosting.co.za> Message-ID: <1398390452.69.0.692608362863.issue21344@psf.upfronthosting.co.za> Changes by Russell Ballestrini : Removed file: http://bugs.python.org/file35024/difflib-patch-to-save-scores.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 25 03:49:39 2014 From: report at bugs.python.org (Russell Ballestrini) Date: Fri, 25 Apr 2014 01:49:39 +0000 Subject: [issue21344] save scores or ratios in difflib get_close_matches In-Reply-To: <1398350530.77.0.0668395281532.issue21344@psf.upfronthosting.co.za> Message-ID: <1398390579.81.0.157132702795.issue21344@psf.upfronthosting.co.za> Russell Ballestrini added the comment: Ok, this patch is ready for review. ---------- Added file: http://bugs.python.org/file35033/diff-lib-get-scored-matches-tests-and-docs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 25 05:04:14 2014 From: report at bugs.python.org (Tim Peters) Date: Fri, 25 Apr 2014 03:04:14 +0000 Subject: [issue21344] save scores or ratios in difflib get_close_matches In-Reply-To: <1398350530.77.0.0668395281532.issue21344@psf.upfronthosting.co.za> Message-ID: <1398395054.96.0.854639279161.issue21344@psf.upfronthosting.co.za> Tim Peters added the comment: I wonder whether this new function would attract any users, given that the user already has control over the smallest ratio that will be accepted, and over the maximum number of close matches returned. That's always been sufficient for me. What useful thing(s) can the user do with the scores? If there are compelling uses, in _those_ contexts are the `n` and `cutoff` arguments useful too? Or would it, for example, be more useful to generate all (score, word) pairs and let the user filter them as they wish? Without a concrete use case, there's no clear answer. About existing tests for `get_close_matches()`, those are in the function's docstring. doctest checks them. About the new tests in the patch, note that comparing lists for equality "should be" done via AssertListEqual, not via AssertEqual. Don't ask me why, but someone will eventually yell about it ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 25 05:26:58 2014 From: report at bugs.python.org (Steve) Date: Fri, 25 Apr 2014 03:26:58 +0000 Subject: [issue21292] C API in debug fails In-Reply-To: <1397771478.75.0.526004579779.issue21292@psf.upfronthosting.co.za> Message-ID: <1398396418.9.0.778825554215.issue21292@psf.upfronthosting.co.za> Steve added the comment: Indeed, but not defining _DEBUG for debug compiling is not realistic. Too many dependencies. I am not even sure it would work, because if we bind with the debug libraries, but build with the "release" headers, it might break. In any case it is not an option we have on the table at this moment. As for the linking part, I am not sure I am following you. Your runtime libraries and DLLs should not need to be linked to anything. They may be dependent on the release msvcrt, and that is fine (like I said, we can live with the Python parts in release). We have many other such libraries that are only in release mode (even when we build in debug). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 25 05:38:59 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 25 Apr 2014 03:38:59 +0000 Subject: [issue14218] include rendered output in addition to markup In-Reply-To: <1331111194.08.0.943407781198.issue14218@psf.upfronthosting.co.za> Message-ID: <1398397139.34.0.399068993626.issue14218@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The link in the first message does not work. This should: https://docs.python.org/devguide/documenting.html The section under discussion, which pydev controls, as opposed to the full .rst doc at http://docutils.sourceforge.net/rst.html, is https://docs.python.org/devguide/documenting.html#restructuredtext-primer https://docs.python.org/devguide/documenting.html#additional-markup-constructs I still agree in general with the request. What I tried to say before is that showing results somehow reinforces learning. Why does the tutorial start with >>> 2 + 2 4 ? Everyone *knows* that 2 + 2 is 4. Yet is helps to show that Python actually does the right thing. Tshepang is asking for something similar. I agree that one or more tables are needed. The example given could have a third column. One thing good about the table is that is gives the goal first, and then the means. Contrast that with one asterisk: *text* for emphasis (italics), This sentence might be ok for a reading guide (if I see one asterisk, what does it mean), but not for choosing what to write. Here is a sentence that would be really clearer with the result: "it must be separated from surrounding text by non-word characters. Use a backslash escaped space to work around that: thisis\ *one*\ word." It took me several seconds to really get that the result would be "thisisONEword", where the capitals indicate italics. This sentence I do not understand. "Every explicit markup block which isn?t a valid markup construct (like the footnotes above) is regarded as a comment." It seems to say that the footnote markup given is not valid. And what does 'regarded as a comment' mean? Is the invalid markup block deleted? specially displayed? or displayed normally? As for style differences: the guide could start with "The exact way markup is rendered depends on the theme. The examples below are rendered with the 'devguide' theme used for the rest of the devguide." I am probably the best person nosy here to write at least a draft of a patch since I believe it is needed, have some sense of doc style, but still know .rst poorly enough to have difficulties with the current version. It would be a good way to finally learn the markup. It is somewhat confusing that many of the same topics are covered twice, first for standard .rst, and then for python extensions. Ezio's example table seems to combine both. If this is done (and I think it helpful), there should be a column indicating which is which. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 25 05:58:19 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 25 Apr 2014 03:58:19 +0000 Subject: [issue15569] Doc doc: incorrect description of some roles as format-only In-Reply-To: <1344302647.18.0.307450045197.issue15569@psf.upfronthosting.co.za> Message-ID: <1398398299.97.0.283120658862.issue15569@psf.upfronthosting.co.za> Terry J. Reedy added the comment: There are no versions for the devguide. There is another misplaced role: : option A command-line option of Python. The leading hyphen(s) must be included. If a matching cmdoption directive exists, it is linked to. For options of other programs or scripts, use simple ``code`` markup. I think "The following role does possibly create a cross-reference, but does not refer to objects:" should be changed to something like "The following roles do not refer to module objects, but possibly create cross-references or internal links:". Move the three misplaced roles here, along with token and term. ---------- nosy: +terry.reedy versions: -Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 25 06:05:34 2014 From: report at bugs.python.org (Russell Ballestrini) Date: Fri, 25 Apr 2014 04:05:34 +0000 Subject: [issue21344] save scores or ratios in difflib get_close_matches In-Reply-To: <1398350530.77.0.0668395281532.issue21344@psf.upfronthosting.co.za> Message-ID: <1398398734.48.0.359682595116.issue21344@psf.upfronthosting.co.za> Russell Ballestrini added the comment: At some point I plan to write a web API that accepts a word, 'doge' and returns a list of possible suggestions and scores. Later a "did you mean dog" style suggestion could be implemented on top. We compute the scores, and it is computationally taxing, we shouldn't always throw this data away. Most users will continue to use get_close_matches, some users might want to build indexes on the scores. Other users may want to cache (memonize) common queries for super fast look ups. Additionally the new function will give end-users the opportunity to inspect the scoring algos output. I prefer to use the same arg spec because it is already widely understood and documented. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 25 06:16:56 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 25 Apr 2014 04:16:56 +0000 Subject: [issue16574] clarify policy on updates to final peps In-Reply-To: <1354150615.68.0.531483999972.issue16574@psf.upfronthosting.co.za> Message-ID: <1398399416.69.0.492010423581.issue16574@psf.upfronthosting.co.za> Terry J. Reedy added the comment: With respect to editing final peps, I think this issue should be closed. The current PEP 1 statement accurately describes what we do, which is that in general we do not edit final peps. Moreover, Chris has not submitted a patch and I doubt anyone else knows what he thought he might add or where, The only related question I have is in relation to Martin's point 3. https://docs.python.org/devguide/documenting.html#id3 has the following: pep A reference to a Python Enhancement Proposal. This generates appropriate index entries. The text ?PEP number? is generated; in the HTML output, this text is a hyperlink to an online copy of the specified PEP. Should we add something like "Such links should not be a substitute for properly documenting the language in the manuals." ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 25 06:29:23 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 25 Apr 2014 04:29:23 +0000 Subject: [issue17227] devguide: buggy heading numbers In-Reply-To: <1361217002.34.0.936078305401.issue17227@psf.upfronthosting.co.za> Message-ID: <1398400163.63.0.19843381994.issue17227@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The only change is that '25' is now '28'. A possible solution, without changing Sphinx, is to reduce the headers to a couple of words and put the question under the header, possibly in italics. *Q. How do I do this difficult thing?* A. Do 2 pushups, sleep 3 hours, drink water, and do it. I am not sure how this would affect the linked index at the top that appears before 28.1 Communications. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 25 07:22:18 2014 From: report at bugs.python.org (paul j3) Date: Fri, 25 Apr 2014 05:22:18 +0000 Subject: [issue11708] argparse: suggestion for formatting optional positional args In-Reply-To: <1301372470.63.0.394832292121.issue11708@psf.upfronthosting.co.za> Message-ID: <1398403338.02.0.241397442203.issue11708@psf.upfronthosting.co.za> paul j3 added the comment: This patch adds a ReGroupHelpFormatter class, which regroups positional arguments in the usage line as discussed before. It builds on the reworked usage formatter in bugs/python.org/issue11874 (which keeps usage as a list longer). For a complicate parser, usage may look like: usage: regp [-h] foo [arg1 [arg2 [arg3 [arg3 ...] [arg4]]]] ---------- keywords: +patch Added file: http://bugs.python.org/file35034/regroup.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 25 07:25:45 2014 From: report at bugs.python.org (paul j3) Date: Fri, 25 Apr 2014 05:25:45 +0000 Subject: [issue11708] argparse: suggestion for formatting optional positional args In-Reply-To: <1301372470.63.0.394832292121.issue11708@psf.upfronthosting.co.za> Message-ID: <1398403545.8.0.159474474649.issue11708@psf.upfronthosting.co.za> paul j3 added the comment: This is a testing script for this patch. It is not a unit test. Example: p = argparse.ArgumentParser() p.formatter_class = argparse.ReGroupHelpFormatter p.add_argument('foo') p.add_argument('arg1',nargs='?') p.add_argument('arg2',nargs='?') a = p.add_argument('arg3',nargs='*') b = p.add_argument('arg4', nargs='?') # usage: regp [-h] foo [arg1 [arg2 [arg3 [arg3 ...] [arg4]]]] ---------- Added file: http://bugs.python.org/file35035/test_regroup.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 25 08:45:16 2014 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 25 Apr 2014 06:45:16 +0000 Subject: [issue21340] Possible concurrency bug in asyncio, AttributeError in tasks.py In-Reply-To: <1398305622.34.0.507325141901.issue21340@psf.upfronthosting.co.za> Message-ID: <1398408316.52.0.79628619584.issue21340@psf.upfronthosting.co.za> Guido van Rossum added the comment: Oh wait, it looks like the assert failed because KeyboardInterrupt hit right at that point. I ran the program a few times and when I hit ^C I get a traceback at a different point in the code each time. This is as expected. You must have hit the rare case where it hit right at the assert -- then the behavior I described can happen. Anyway, I think this would fix it: --- a/asyncio/tasks.py Fri Apr 18 09:51:35 2014 -0700 +++ b/asyncio/tasks.py Thu Apr 24 23:44:57 2014 -0700 @@ -76,7 +76,8 @@ return self.gen.gi_code def __del__(self): - frame = self.gen.gi_frame + gen = getattr(self, 'gen', None) + frame = getattr(gen, 'gi_frame', None) if frame is not None and frame.f_lasti == -1: func = self.func code = func.__code__ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 25 10:40:55 2014 From: report at bugs.python.org (akira) Date: Fri, 25 Apr 2014 08:40:55 +0000 Subject: [issue17552] socket.sendfile() In-Reply-To: <1364326073.47.0.699222209849.issue17552@psf.upfronthosting.co.za> Message-ID: <1398415255.88.0.974194439789.issue17552@psf.upfronthosting.co.za> akira added the comment: > I'm confused. Why is "blocksize" necessary at all? My guess, it may be used to implement socket.send()-based fallback. Its meaning could be the same as *length* parameter in shutil.copyfileobj The fallback is useful if os.sendfile doesn't exists or it doesn't accept given parameters e.g., if *file* is not mmap-like enough for os.sendfile. > > using os.path.getsize(file.name) looks risky to me > Why not fstat(fd) ? os.path.getsize(file.name) in msg217121 is a pseudo-code (as said in the comment) that expresses the intent that if *nbytes* parameter is not specified (None) then socket.sendfile should send bytes from the file until EOF is reached. In real code, if *nbytes is None*; I would just call os.sendfile repeatedly with a large constant *nbytes* parameter until os.sendfile returns 0 (meaning EOF) without asking the file size explicitly It assumes socket.sendfile doesn't specify its behaviour if the file size changes between the calls. The pseudo-code in msg217121 is my opinion about the public interface for socket.sendfile -- It is different from the one in the current socket-sendfile5.patch ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 25 11:37:13 2014 From: report at bugs.python.org (Stefan Krah) Date: Fri, 25 Apr 2014 09:37:13 +0000 Subject: [issue21348] File "C:\Python27\lib\distutils\msvc9compiler.py", line 295, in query_vcvarsal l raise ValueError(str(list(result.keys()))) ValueError: [u'path'] In-Reply-To: <1398382949.19.0.0972223942804.issue21348@psf.upfronthosting.co.za> Message-ID: <1398418633.05.0.956180716488.issue21348@psf.upfronthosting.co.za> Stefan Krah added the comment: This looks like a duplicate of #7511. ---------- nosy: +skrah resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> msvc9compiler.py: ValueError when trying to compile with VC Express _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 25 11:53:59 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 25 Apr 2014 09:53:59 +0000 Subject: [issue20434] Fix error handler of _PyString_Resize() on allocation failure In-Reply-To: <1390984600.38.0.476358983499.issue20434@psf.upfronthosting.co.za> Message-ID: <3gFW1L38QDz7LjN@mail.python.org> Roundup Robot added the comment: New changeset 4f79c3827adc by Kristj?n Valur J?nsson in branch '2.7': Issue #20434 Correct error handlin of _PyString_Resize and _PyBytes_Resize http://hg.python.org/cpython/rev/4f79c3827adc ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 25 14:22:06 2014 From: report at bugs.python.org (Berker Peksag) Date: Fri, 25 Apr 2014 12:22:06 +0000 Subject: [issue21349] crash in winreg SetValueEx with memoryview Message-ID: <1398428526.99.0.9214690263.issue21349@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 25 15:29:45 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 25 Apr 2014 13:29:45 +0000 Subject: [issue21225] io.py: Improve docstrings for classes In-Reply-To: <1397508646.21.0.210626779275.issue21225@psf.upfronthosting.co.za> Message-ID: <3gFbpJ60N6z7LjY@mail.python.org> Roundup Robot added the comment: New changeset e33a036fd784 by Andrew Kuchling in branch '3.4': #21225: copy docstrings from base classes http://hg.python.org/cpython/rev/e33a036fd784 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 25 16:27:14 2014 From: report at bugs.python.org (Eric V. Smith) Date: Fri, 25 Apr 2014 14:27:14 +0000 Subject: [issue21336] ntpath.splitdrive fails on None argument In-Reply-To: <1398272240.06.0.678669968331.issue21336@psf.upfronthosting.co.za> Message-ID: <1398436034.62.0.437721711281.issue21336@psf.upfronthosting.co.za> Eric V. Smith added the comment: I'm going to close this as "not a bug". Feel free to reopen it if there's use case for passing in None. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 25 16:56:14 2014 From: report at bugs.python.org (yaccz) Date: Fri, 25 Apr 2014 14:56:14 +0000 Subject: [issue1465646] test_grp & test_pwd fail Message-ID: <1398437774.17.0.673975016067.issue1465646@psf.upfronthosting.co.za> yaccz added the comment: Also fails on group + which is afaik a thing for ldap. tested with python 2.6.9 on suse linux enterprise ---------- nosy: +yaccz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 25 18:40:21 2014 From: report at bugs.python.org (Brian Kearns) Date: Fri, 25 Apr 2014 16:40:21 +0000 Subject: [issue21350] bug in file.writelines accepting buffers Message-ID: <1398444021.42.0.983935463224.issue21350@psf.upfronthosting.co.za> New submission from Brian Kearns: In file.writelines, the conditions in this if statement are bogus. If f->f_binary and AsReadBuffer succeeds (returns 0), AsCharBuf is still tried. So, for example, passing an array('c') to a file('wb').writelines fails, when it seems the intention of the code/comments was to have it succeed. ---------- files: fix_file_writelines-py27.patch keywords: patch messages: 217162 nosy: bdkearns priority: normal severity: normal status: open title: bug in file.writelines accepting buffers type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file35036/fix_file_writelines-py27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 25 18:44:44 2014 From: report at bugs.python.org (Brian Kearns) Date: Fri, 25 Apr 2014 16:44:44 +0000 Subject: [issue21350] bug in file.writelines accepting buffers In-Reply-To: <1398444021.42.0.983935463224.issue21350@psf.upfronthosting.co.za> Message-ID: <1398444284.08.0.898639233977.issue21350@psf.upfronthosting.co.za> Changes by Brian Kearns : Removed file: http://bugs.python.org/file35036/fix_file_writelines-py27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 25 18:44:50 2014 From: report at bugs.python.org (Brian Kearns) Date: Fri, 25 Apr 2014 16:44:50 +0000 Subject: [issue21350] bug in file.writelines accepting buffers In-Reply-To: <1398444021.42.0.983935463224.issue21350@psf.upfronthosting.co.za> Message-ID: <1398444290.27.0.853562606028.issue21350@psf.upfronthosting.co.za> Changes by Brian Kearns : Added file: http://bugs.python.org/file35037/fix_file_writelines-py27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 25 18:56:56 2014 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Fri, 25 Apr 2014 16:56:56 +0000 Subject: [issue21305] PEP 466: update os.urandom In-Reply-To: <1397868674.52.0.918643592406.issue21305@psf.upfronthosting.co.za> Message-ID: <1398445016.27.0.25429454238.issue21305@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- nosy: +tshepang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 25 19:21:22 2014 From: report at bugs.python.org (Zachary Ware) Date: Fri, 25 Apr 2014 17:21:22 +0000 Subject: [issue21349] crash in winreg SetValueEx with memoryview Message-ID: <1398446482.48.0.369974839933.issue21349@psf.upfronthosting.co.za> New submission from Zachary Ware: The new test fails with the patch applied: ====================================================================== ERROR: test_setvalueex_with_memoryview (__main__.LocalWinregTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "P:\ath\to\2.7\cpython\lib\test\test_winreg.py", line 336, in test_setvalueex_with_memoryview SetValueEx(ck, "test_name", None, REG_BINARY, memoryview('val')) TypeError: Objects of type 'memoryview' can not be used as binary registry values ---------------------------------------------------------------------- ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 25 19:38:00 2014 From: report at bugs.python.org (Brian Kearns) Date: Fri, 25 Apr 2014 17:38:00 +0000 Subject: [issue21349] crash in winreg SetValueEx with memoryview In-Reply-To: <1398446482.48.0.369974839933.issue21349@psf.upfronthosting.co.za> Message-ID: <1398447480.1.0.760895308921.issue21349@psf.upfronthosting.co.za> Brian Kearns added the comment: Oops, updated test. ---------- Added file: http://bugs.python.org/file35038/fix_winreg_setvalueex-py27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 25 19:38:23 2014 From: report at bugs.python.org (Brian Kearns) Date: Fri, 25 Apr 2014 17:38:23 +0000 Subject: [issue21349] crash in winreg SetValueEx with memoryview In-Reply-To: <1398446482.48.0.369974839933.issue21349@psf.upfronthosting.co.za> Message-ID: <1398447503.31.0.986706768913.issue21349@psf.upfronthosting.co.za> Changes by Brian Kearns : Removed file: http://bugs.python.org/file35031/fix_winreg_setvalueex-py27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 25 19:45:56 2014 From: report at bugs.python.org (Giampaolo Rodola') Date: Fri, 25 Apr 2014 17:45:56 +0000 Subject: [issue17552] socket.sendfile() In-Reply-To: <1364326073.47.0.699222209849.issue17552@psf.upfronthosting.co.za> Message-ID: <1398447956.82.0.734382332627.issue17552@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: Given the opinions expressed so far I: - got rid of the "blocksize" parameter - got rid of the "use_fallback" parameter - added a "count" parameter - used os.fstat() to figure out the total file size and passed it directly to sendfile() I'm attaching socket-sendfile6.patch which includes docs and many new tests. Hopefully this should be the final one (yet to review though). ---------- Added file: http://bugs.python.org/file35039/socket-sendfile6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 25 19:54:14 2014 From: report at bugs.python.org (Russell Ballestrini) Date: Fri, 25 Apr 2014 17:54:14 +0000 Subject: [issue21344] save scores or ratios in difflib get_close_matches In-Reply-To: <1398350530.77.0.0668395281532.issue21344@psf.upfronthosting.co.za> Message-ID: <1398448454.02.0.0378729522486.issue21344@psf.upfronthosting.co.za> Russell Ballestrini added the comment: Adding patch to update tests to use Tim Peters suggestion of assertListEqual over assertEqual for list compares. ---------- Added file: http://bugs.python.org/file35040/diff-lib-tim-peters-assert-list-equals.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 25 21:22:50 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 25 Apr 2014 19:22:50 +0000 Subject: [issue21347] Don't use a list argument together with shell=True in subprocess' docs In-Reply-To: <1398366522.65.0.954174735085.issue21347@psf.upfronthosting.co.za> Message-ID: <1398453770.28.0.961923787804.issue21347@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo versions: +Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 25 21:26:39 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 25 Apr 2014 19:26:39 +0000 Subject: [issue21338] Silent mode for compileall In-Reply-To: <1398295772.24.0.550494832702.issue21338@psf.upfronthosting.co.za> Message-ID: <1398453999.12.0.508129948047.issue21338@psf.upfronthosting.co.za> ?ric Araujo added the comment: Patch looks to me comprehensive and backward-compatible. Thanks Thomas! ---------- nosy: +eric.araujo stage: needs patch -> commit review type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 25 21:39:07 2014 From: report at bugs.python.org (Min RK) Date: Fri, 25 Apr 2014 19:39:07 +0000 Subject: [issue21351] refcounts not respected at process exit Message-ID: <1398454746.98.0.985879059912.issue21351@psf.upfronthosting.co.za> New submission from Min RK: Reference counts appear to be ignored at process cleanup, which allows inter-dependent `__del__` methods to hang on exit. The problem does not seem to occur for garbage collection of any other context (functions, etc.). I have a case where one object must be cleaned up after some descendent objects. Those descendents hold a reference on the parent and not vice versa, which should guarantee that they are cleaned up before the parent. This guarantee is satisfied by Python 3.3 and below, but not 3.4. The attached test script hangs at exit on most (not all) runs on 3.4, but exits cleanly on earlier versions. ---------- components: Interpreter Core files: tstgc.py messages: 217168 nosy: minrk priority: normal severity: normal status: open title: refcounts not respected at process exit versions: Python 3.4 Added file: http://bugs.python.org/file35041/tstgc.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 25 21:49:10 2014 From: report at bugs.python.org (Nathan Stocks) Date: Fri, 25 Apr 2014 19:49:10 +0000 Subject: [issue21351] refcounts not respected at process exit In-Reply-To: <1398454746.98.0.985879059912.issue21351@psf.upfronthosting.co.za> Message-ID: <1398455350.76.0.642634794332.issue21351@psf.upfronthosting.co.za> Nathan Stocks added the comment: This affects me as well. I have to manually clean up objects in the correct order in script I am working on under 3.4.0. I have this problem under both OS X 10.9.2 Mavericks and under CentOS 6.5 ---------- nosy: +nathan.stocks _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 25 22:27:41 2014 From: report at bugs.python.org (bob gailer) Date: Fri, 25 Apr 2014 20:27:41 +0000 Subject: [issue21352] improve indexing Message-ID: <1398457661.12.0.679738685491.issue21352@psf.upfronthosting.co.za> New submission from bob gailer: Inconsistencies / confusion with documentation Index Tab. Example (line numbers added for comments that follow): 1 max 2 built-in function 3 max (datetime.date attribute) 4 (datetime.datetime attribute) 5 (datetime.time attribute) 6 max() built-in function 7 (decimal.Context method) 8 (decimal.Decimal method) 9 (in module audioloop) The following all lead to confusion and frustration: Having 3 rows (1, 3, 6)that begin with max. Having an entry (1) that does nothing when double-clicked. double-clicking (2) takes us to a reference rather than a definition. RECOMMENDATION: change to: max() built-in function (sequence operation) (decimal.Context method) (decimal.Decimal method) max (datetime.date attribute) (datetime.datetime attribute) (datetime.time attribute) where double-clicking the first line goes to the max() definition in 2. Built-in Functions These comments apply, with a number of variations, to most built-in functions index entries. ---------- assignee: docs at python components: Documentation messages: 217170 nosy: bgailer, docs at python priority: normal severity: normal status: open title: improve indexing type: enhancement versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 25 22:34:48 2014 From: report at bugs.python.org (Zachary Ware) Date: Fri, 25 Apr 2014 20:34:48 +0000 Subject: [issue21352] improve indexing In-Reply-To: <1398457661.12.0.679738685491.issue21352@psf.upfronthosting.co.za> Message-ID: <1398458088.9.0.36525863031.issue21352@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- versions: -Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 25 23:04:50 2014 From: report at bugs.python.org (Tim Peters) Date: Fri, 25 Apr 2014 21:04:50 +0000 Subject: [issue21344] save scores or ratios in difflib get_close_matches In-Reply-To: <1398350530.77.0.0668395281532.issue21344@psf.upfronthosting.co.za> Message-ID: <1398459890.9.0.988894315061.issue21344@psf.upfronthosting.co.za> Tim Peters added the comment: Russell, I'm still looking for a sufficiently compelling "use case" here: something tangible and useful that can be done with the new function that can't be easily done now. "I plan to write a web API that accepts a word, 'doge' and returns a list of possible suggestions and scores" is not a use case for scores. It's merely tautological that if you want to return scores then you need a function that does return scores. A "use case" would more address _why_ the scores are useful. What would the user of your web API _do_ with the scores? What's the point? "users may want to cache (memonize) common queries for super fast look ups" isn't a use case for scores either. If they wanted to, they could already cache the results of calling `get_close_matches()` - the results of any function can be cached; exposing scores has nothing to do with whether results can be cached. "the new function will give end-users the opportunity to inspect the scoring algos output" is also more tautological than a use case. _Why_ would a user want to stare at the scores? What useful things(s) could they do with them? I was added to this issue because I wrote these functions to begin with. At the time, I thought - and asked - about exposing the scores, but nobody (including me) had a _use_ for doing so that justified the added bother of writing & maintaining the additional code and tests and docs. I'm stilling looking for a use here more substantial than, essentially, just saying "well, without showing the scores we can't show the scores". To me the scores just aren't interesting beyond which words' scores exceed a cutoff, and the ordering of words based on their similarity scores - but `get_close_matches()` already captures those uses. What other use(s) _do_ you have for the scores? I'm afraid "just to display them" isn't compelling enough - you're the only one ever to ask for that, and you already know how to do it yourself ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 25 23:19:03 2014 From: report at bugs.python.org (Tim Peters) Date: Fri, 25 Apr 2014 21:19:03 +0000 Subject: [issue21351] refcounts not respected at process exit In-Reply-To: <1398454746.98.0.985879059912.issue21351@psf.upfronthosting.co.za> Message-ID: <1398460743.49.0.84042099234.issue21351@psf.upfronthosting.co.za> Tim Peters added the comment: Just noting that, for me, the problem goes away if del c, c2 is added as the last line of the test. This suggests the problem is due to changes in end-of-life module cleanup. Without that line, I see 3 kinds of output: 1. del child del child del parent parent deleted 2. del parent parent still has 2 children parent still has 2 children ... repeated forever ... 3. del child del parent parent still has 1 children parent still has 1 children ... repeated forever ... ---------- nosy: +tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 25 23:43:54 2014 From: report at bugs.python.org (Jim Jewett) Date: Fri, 25 Apr 2014 21:43:54 +0000 Subject: [issue16104] Compileall script: add option to use multiple cores In-Reply-To: <1349124414.14.0.0730954283721.issue16104@psf.upfronthosting.co.za> Message-ID: <1398462234.25.0.676841417712.issue16104@psf.upfronthosting.co.za> Jim Jewett added the comment: ProcessPoolExecutor already defaults to using cpu_count if max_workers is None. Consistency with that might be useful too. (and a default of 1 to mean nothing in parallel is sensible...) ---------- nosy: +Jim.Jewett _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 00:07:49 2014 From: report at bugs.python.org (Tim Peters) Date: Fri, 25 Apr 2014 22:07:49 +0000 Subject: [issue21351] refcounts not respected at process exit In-Reply-To: <1398454746.98.0.985879059912.issue21351@psf.upfronthosting.co.za> Message-ID: <1398463669.18.0.976216687906.issue21351@psf.upfronthosting.co.za> Changes by Tim Peters : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 00:18:28 2014 From: report at bugs.python.org (Russell Ballestrini) Date: Fri, 25 Apr 2014 22:18:28 +0000 Subject: [issue21344] save scores or ratios in difflib get_close_matches In-Reply-To: <1398350530.77.0.0668395281532.issue21344@psf.upfronthosting.co.za> Message-ID: <1398464308.06.0.880618693694.issue21344@psf.upfronthosting.co.za> Russell Ballestrini added the comment: Tim, You bring up some great points and insight I was missing. "To me the scores just aren't interesting beyond which words' scores exceed a cutoff, and the ordering of words based on their similarity scores - but `get_close_matches()` already captures those uses." For a *word*, and a corpus of *possibilities*, how does one choose a satisfactory *cutoff* without inspecting the output of the scoring algorithm? Personally, I don't want to inpect scores for inspection sake, I want to inspect scores so I can make an informed decision for the *n* and *cutoff* input arguments. Its true that after reading and digesting the source code for `get_close_matches()` I could (and did) implement a version that returns scores. My goal was to share this code and what better way then to "fix" the problem upstream. I understand the desire to keep the standard library lean and useful to reduce the amount of burden the code is to maintain. I will understand if we decide not to include these patches, I can always maintain a fork and share on pypi. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 00:22:28 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 25 Apr 2014 22:22:28 +0000 Subject: [issue21314] Document '/' in signatures In-Reply-To: <1397988439.5.0.703056699862.issue21314@psf.upfronthosting.co.za> Message-ID: <1398464548.61.0.170266233971.issue21314@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- status: open -> title: Bizarre help -> Document '/' in signatures _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 00:22:37 2014 From: report at bugs.python.org (=?utf-8?q?William_Tis=C3=A4ter?=) Date: Fri, 25 Apr 2014 22:22:37 +0000 Subject: [issue20050] distutils should check PyPI certs when connecting to it In-Reply-To: <1387673525.81.0.630232623355.issue20050@psf.upfronthosting.co.za> Message-ID: <1398464557.63.0.410010100277.issue20050@psf.upfronthosting.co.za> Changes by William Tis?ter : ---------- nosy: +tiwilliam _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 00:25:51 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 25 Apr 2014 22:25:51 +0000 Subject: [issue21321] itertools.islice() doesn't release reference to the source iterator when the slice is exhausted In-Reply-To: <1398082430.51.0.59207810702.issue21321@psf.upfronthosting.co.za> Message-ID: <1398464751.1.0.813371336294.issue21321@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- versions: +Python 3.5 -Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 00:47:04 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 25 Apr 2014 22:47:04 +0000 Subject: [issue21325] Missing Generic EXIF library for images in the standard library In-Reply-To: <1398132273.77.0.903866563155.issue21325@psf.upfronthosting.co.za> Message-ID: <1398466024.71.0.139880766911.issue21325@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Generic ideas like this, without specific patch or patch prospect, should be first posted on python-ideas. You can reopen this if there is a concrete proposal with some support. However, I agree with Brett about an Exif module. We do not even have an image library in the stdlib. And according to https://en.wikipedia.org/wiki/Exchangeable_image_file_format the 'standard' is in practice a bit of a mess with constantly added extensions. There are multiple Exif modules on PyPi and that is where they belong, along with 1000s of other niche modules. https://pypi.python.org/pypi?%3Aaction=search&term=Exif&submit=search ---------- nosy: +terry.reedy resolution: -> rejected stage: -> resolved status: open -> closed versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 00:53:08 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 25 Apr 2014 22:53:08 +0000 Subject: [issue21337] Add tests for Tix In-Reply-To: <1398286008.45.0.411979424173.issue21337@psf.upfronthosting.co.za> Message-ID: <1398466388.87.0.821956191418.issue21337@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 02:00:57 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 26 Apr 2014 00:00:57 +0000 Subject: [issue21341] Configuring 'font' with ttk.Style for 'TEntry' does not change displayed font In-Reply-To: <1398312732.28.0.174880904692.issue21341@psf.upfronthosting.co.za> Message-ID: <1398470457.89.0.061968151837.issue21341@psf.upfronthosting.co.za> Terry J. Reedy added the comment: This appears to be a tcl/tk(ttk) issue. You rediscovered what is documented here: http://infohost.nmt.edu/tcc/help/pubs/tkinter/web/ttk-Entry.html Table 40. ttk.Entry options font Use this option to specify the font of the text that will appear in the widget; see Section 5.4, ?Type fonts?. For reasons that are unclear to the author, this option cannot be specified with a style. ---------- nosy: +terry.reedy resolution: -> third party stage: -> resolved status: open -> closed versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 02:09:43 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 26 Apr 2014 00:09:43 +0000 Subject: [issue8387] use universal newline mode in csv module examples In-Reply-To: <1271193086.18.0.201846291594.issue8387@psf.upfronthosting.co.za> Message-ID: <1398470983.96.0.655548229846.issue8387@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- versions: -Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 02:43:59 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 26 Apr 2014 00:43:59 +0000 Subject: [issue21351] refcounts not respected at process exit In-Reply-To: <1398454746.98.0.985879059912.issue21351@psf.upfronthosting.co.za> Message-ID: <1398473039.36.0.755719362625.issue21351@psf.upfronthosting.co.za> Antoine Pitrou added the comment: (the 3 kinds of output are probably due to hash randomization) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 03:00:41 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 26 Apr 2014 01:00:41 +0000 Subject: [issue21351] refcounts not respected at process exit In-Reply-To: <1398454746.98.0.985879059912.issue21351@psf.upfronthosting.co.za> Message-ID: <1398474041.81.0.0253992995767.issue21351@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Looking into it, it's normal for refcounts to be "ignored": those objects belong to reference cycles: tstgc.__dict__ -> p (or c, or c2) -> p.__class__ (i.e. Parent, or Child respectivel)) -> Parent.__dict__ -> Parent.__del__ (or Parent.__init__, or Parent.child) -> Parent.__del__.__globals__ (which is tstgc.__dict__) Since p, c, c2 belong to reference cycles, they get collected in an undefined order. Obviously, Parent.__del__ is buggy (it runs into an infinite loop when self.children != 0). Before Python 3.4, the module globals would have been set to None at shutdown, which would have broken those cycles, but caused other well-known problems. It's probably impossible to find a scheme that satisfies all constraints, so we'll see in the future if the new scheme brings more drawbacks than advantages (right now, my own evaluation is obviously that it's a step forward). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 03:35:27 2014 From: report at bugs.python.org (Tim Peters) Date: Sat, 26 Apr 2014 01:35:27 +0000 Subject: [issue21351] refcounts not respected at process exit In-Reply-To: <1398454746.98.0.985879059912.issue21351@psf.upfronthosting.co.za> Message-ID: <1398476127.37.0.269045582804.issue21351@psf.upfronthosting.co.za> Tim Peters added the comment: I think Antoine is right on all counts. The most surprising bit may be that p, c, and c2 are in reference cycles, but - surprising or not - that's always been true. The reason "it worked" before 3.4 is that CPython happened to break the cycles via the nasty hack of binding each module global to None at shutdown. minrk, note that gc in CPython does not (for example) run in a separate thread. That's why, when it triggers, the infinite loop in your Parent.__del__ will in fact run forever. gc runs in the same thread (the main thread) as Parent.__del__, so spinning in the Parent.__del__ loop prevents anything else (including more gc) from ever being done. Take out the infinite loop, and all three objects (p, c, c2) are collected. But the order in which they're collected isn't defined (because they're all in cyclic trash), and even changes from run to run because hash randomization changes the order in which they appear when traversing testgc.__dict__. An interesting question remaining is how you _could_ force a finalization order in this case, in a way that doesn't rely on implementation accidents. A clean way doesn't spring to my mind immediately. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 03:55:17 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 26 Apr 2014 01:55:17 +0000 Subject: [issue21321] itertools.islice() doesn't release reference to the source iterator when the slice is exhausted In-Reply-To: <1398082430.51.0.59207810702.issue21321@psf.upfronthosting.co.za> Message-ID: <1398477317.42.0.0792693085444.issue21321@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Haven't reviewed the patch, but you should definitely add a unit test for the bugfix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 03:57:33 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 26 Apr 2014 01:57:33 +0000 Subject: [issue21349] crash in winreg SetValueEx with memoryview In-Reply-To: <1398446482.48.0.369974839933.issue21349@psf.upfronthosting.co.za> Message-ID: <1398477453.15.0.502395838648.issue21349@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Brian, it's not obvious (to me) what the original issue is ("crash"?) and why the new test expects a TypeError. Also, is it a 2.7-only issue or does it also affect Python 3? ---------- nosy: +pitrou, stutzbach _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 04:24:10 2014 From: report at bugs.python.org (Brian Kearns) Date: Sat, 26 Apr 2014 02:24:10 +0000 Subject: [issue21349] crash in winreg SetValueEx with memoryview In-Reply-To: <1398446482.48.0.369974839933.issue21349@psf.upfronthosting.co.za> Message-ID: <1398479050.42.0.656819371332.issue21349@psf.upfronthosting.co.za> Brian Kearns added the comment: Are you aware of the old/new buffer interfaces and their usages? Did you actually try the code? "crash" would be obvious. Objects that support only the new buffer interface define tp_as_buffer with fields representing the old buffer interface as null. So, everywhere that uses the old buffer interface usually checks both tp_as_buffer != NULL and tp_as_buffer->bf_getreadbuffer != NULL. That second check is missing here before calling bf_getreadbuffer. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 05:02:53 2014 From: report at bugs.python.org (akira) Date: Sat, 26 Apr 2014 03:02:53 +0000 Subject: [issue21353] document Popen.args attribute Message-ID: <1398481373.88.0.978177813548.issue21353@psf.upfronthosting.co.za> New submission from akira: It is convenient to have Popen.args available. Especially when dealing with multiple processes e.g., to log failures mentioning the command that was used to spawn the child process. subprocess module itself uses it while raising CalledProcessError or TimeoutExpired exceptions. The documentation patch is attached. ---------- assignee: docs at python components: Documentation files: docs-subprocess-document_Popen_args_attribute.patch keywords: patch messages: 217183 nosy: akira, docs at python priority: normal severity: normal status: open title: document Popen.args attribute type: enhancement versions: Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file35042/docs-subprocess-document_Popen_args_attribute.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 08:35:03 2014 From: report at bugs.python.org (paul j3) Date: Sat, 26 Apr 2014 06:35:03 +0000 Subject: [issue14074] argparse allows nargs>1 for positional arguments but doesn't allow metavar to be a tuple In-Reply-To: <1329845918.75.0.31962840333.issue14074@psf.upfronthosting.co.za> Message-ID: <1398494103.34.0.408450967435.issue14074@psf.upfronthosting.co.za> paul j3 added the comment: oops - to fix the error message that OP complained about, I need to patch '_get_action_name' as well: def _get_action_name(argument): ... elif argument.metavar not in (None, SUPPRESS): metavar = argument.metavar if isinstance(metavar, tuple): metavar = '|'.join(metavar) return metavar ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 10:00:55 2014 From: report at bugs.python.org (Mark Hammond) Date: Sat, 26 Apr 2014 08:00:55 +0000 Subject: [issue21354] PyCFunction_New no longer exposed by python DLL breaking bdist_wininst installers Message-ID: <1398499255.25.0.881446688113.issue21354@psf.upfronthosting.co.za> New submission from Mark Hammond: Python 3.3 and earlier have in methodobject.c: /* PyCFunction_New() is now just a macro that calls PyCFunction_NewEx(), but it's part of the API so we need to keep a function around that existing C extensions can call. */ #undef PyCFunction_New PyAPI_FUNC(PyObject *) PyCFunction_New(PyMethodDef *, PyObject *); which means PyCFunction_New is exported from the DLL. Python 3.4 does not have this (which seems a bug in its own right given the comment in 3.3 and earlier) but PC/bdist_wininst/install.c has code that attempts to dynamically load this function from the DLL and fails, causing 3rd party installers to fail. Assuming the removal of this API was intentional so the problem is that install.c needs to be updated, the following patch fixes the issue. ---------- components: Windows files: t.patch keywords: patch messages: 217185 nosy: mhammond priority: normal severity: normal status: open title: PyCFunction_New no longer exposed by python DLL breaking bdist_wininst installers type: behavior Added file: http://bugs.python.org/file35043/t.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 10:42:20 2014 From: report at bugs.python.org (Tim Golden) Date: Sat, 26 Apr 2014 08:42:20 +0000 Subject: [issue21349] crash in winreg SetValueEx with memoryview In-Reply-To: <1398446482.48.0.369974839933.issue21349@psf.upfronthosting.co.za> Message-ID: <1398501740.9.0.487853557629.issue21349@psf.upfronthosting.co.za> Tim Golden added the comment: I can confirm that the problem (which really is a hard crash) only applies to 2.7 and that the patch tests and fixes it. I'm happy to apply. Any objections? ---------- assignee: -> tim.golden nosy: +tim.golden _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 13:32:42 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 26 Apr 2014 11:32:42 +0000 Subject: [issue21349] crash in winreg SetValueEx with memoryview In-Reply-To: <1398479050.42.0.656819371332.issue21349@psf.upfronthosting.co.za> Message-ID: <1398511959.2296.2.camel@fsol> Antoine Pitrou added the comment: > Are you aware of the old/new buffer interfaces and their usages? Did > you actually try the code? "crash" would be obvious. I cannot try the code as I'm under Linux :-) I was asking merely because many people report plain exception tracebacks as "crashes". Yes, by reading the patch it came to me that it was probably related to the coexistence of old and new buffer API, but I prefer it to be confirmed by the reporter, rather than trust my own intuition. (I also wonder why the code did that manually instead of calling e.g. PyObject_AsReadBuffer) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 13:34:06 2014 From: report at bugs.python.org (Eduardo Robles Elvira) Date: Sat, 26 Apr 2014 11:34:06 +0000 Subject: [issue21109] tarfile: Traversal attack vulnerability In-Reply-To: <1396253659.12.0.842636239516.issue21109@psf.upfronthosting.co.za> Message-ID: <1398512046.55.0.0193339886815.issue21109@psf.upfronthosting.co.za> Eduardo Robles Elvira added the comment: Do we have any final decision on what's the best approach to solve this? I see some possibilities: a) leave the issue to the library user. I think that's a not good solution security-wise as many will be unaware of the problem and this promotes code duplication for the fix. On the other hand, this does not change default behavior. b) fix the problem as proposed in the patch sent by Daniel. This makes the tarfile secure against this kind of attacks. It does change the behavior and doesn't allow to extract in arbitrary paths, though. c) fix the problem so that by default extracting in arbitrary paths is not allowed, but allow somehow to do that optionally. This way we change the default behavior but provide an easy fix for those that depend on that functionality. d) do not change the default, but provide a well documented and easy way to activate the safety checks that fix this kind of attacks. The advantage is that it doesn't change the default behavior, the disadvantage is that many people will have to modify their code to be secure, and that the default is not very secure. For what is worth, I believe either b or c should be chosen to fix this issue. ---------- nosy: +edulix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 13:51:36 2014 From: report at bugs.python.org (Eduardo Robles Elvira) Date: Sat, 26 Apr 2014 11:51:36 +0000 Subject: [issue21109] tarfile: Traversal attack vulnerability In-Reply-To: <1396253659.12.0.842636239516.issue21109@psf.upfronthosting.co.za> Message-ID: <1398513096.45.0.646470352301.issue21109@psf.upfronthosting.co.za> Eduardo Robles Elvira added the comment: Also, I guess this patch solves and is closely related to #1044 which was, at the time (2007), considered "not a bug". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 14:36:08 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 26 Apr 2014 12:36:08 +0000 Subject: [issue21207] urandom persistent fd - not re-openned after fd close In-Reply-To: <1397316819.31.0.463593532744.issue21207@psf.upfronthosting.co.za> Message-ID: <3gGBYz0Wgnz7Lk6@mail.python.org> Roundup Robot added the comment: New changeset a66524ce9551 by Antoine Pitrou in branch '3.4': Issue #21207: Detect when the os.urandom cached fd has been closed or replaced, and open it anew. http://hg.python.org/cpython/rev/a66524ce9551 New changeset d3e8db93dc18 by Antoine Pitrou in branch 'default': Issue #21207: Detect when the os.urandom cached fd has been closed or replaced, and open it anew. http://hg.python.org/cpython/rev/d3e8db93dc18 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 14:40:01 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 26 Apr 2014 12:40:01 +0000 Subject: [issue21207] urandom persistent fd - not re-openned after fd close In-Reply-To: <1397316819.31.0.463593532744.issue21207@psf.upfronthosting.co.za> Message-ID: <1398516001.17.0.40642689452.issue21207@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok, I've committed the patch. Hopefully this will also fix any similar issues. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 14:46:33 2014 From: report at bugs.python.org (Diana Clarke) Date: Sat, 26 Apr 2014 12:46:33 +0000 Subject: [issue21355] shallow defaults to true, not 1 [filecmp.cmp] Message-ID: <1398516393.36.0.153160280579.issue21355@psf.upfronthosting.co.za> New submission from Diana Clarke: A minor correction to the filecmp.cmp doc string. 'defaults to 1' -> 'defaults to True' While shallow used to default to 1 years ago, it now defaults to True. def cmp(f1, f2, shallow=True): PS. I know this diff is annoyingly trivial, but I'm using it to learn the process. Thanks, --diana ---------- components: Library (Lib) files: shallow_defaults_to_true_not_1.patch keywords: patch messages: 217192 nosy: diana priority: normal severity: normal status: open title: shallow defaults to true, not 1 [filecmp.cmp] type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file35044/shallow_defaults_to_true_not_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 14:47:39 2014 From: report at bugs.python.org (diana) Date: Sat, 26 Apr 2014 12:47:39 +0000 Subject: [issue21355] Shallow defaults to True, not 1 [filecmp.cmp] In-Reply-To: <1398516393.36.0.153160280579.issue21355@psf.upfronthosting.co.za> Message-ID: <1398516459.65.0.216588576503.issue21355@psf.upfronthosting.co.za> Changes by diana : ---------- title: shallow defaults to true, not 1 [filecmp.cmp] -> Shallow defaults to True, not 1 [filecmp.cmp] _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 15:00:47 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 26 Apr 2014 13:00:47 +0000 Subject: [issue15422] Get rid of PyCFunction_New macro In-Reply-To: <1342967583.47.0.436061975286.issue15422@psf.upfronthosting.co.za> Message-ID: <1398517247.79.0.98970361341.issue15422@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Regression in issue #21354. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 15:01:35 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 26 Apr 2014 13:01:35 +0000 Subject: [issue21354] PyCFunction_New no longer exposed by python DLL breaking bdist_wininst installers In-Reply-To: <1398499255.25.0.881446688113.issue21354@psf.upfronthosting.co.za> Message-ID: <1398517295.24.0.266945546464.issue21354@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This is apparently because mismanagement of issue #15422. Andrew, you did the commits, can you restore the PyAPI_FUNC declaration? ---------- assignee: -> asvetlov nosy: +asvetlov, larry, pitrou priority: normal -> release blocker stage: -> needs patch versions: +Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 15:05:21 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 26 Apr 2014 13:05:21 +0000 Subject: [issue21354] PyCFunction_New no longer exposed by python DLL breaking bdist_wininst installers In-Reply-To: <1398499255.25.0.881446688113.issue21354@psf.upfronthosting.co.za> Message-ID: <1398517521.88.0.220471689161.issue21354@psf.upfronthosting.co.za> Antoine Pitrou added the comment: (while none of PyCFunction_New and PyCFunction_NewEx are documented, they are part of the stable ABI - the python3.def file -, so removing the API is presumably a bug, not a feature) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 15:08:17 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 26 Apr 2014 13:08:17 +0000 Subject: [issue21352] improve documentation indexing In-Reply-To: <1398457661.12.0.679738685491.issue21352@psf.upfronthosting.co.za> Message-ID: <1398517697.44.0.599860310343.issue21352@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- title: improve indexing -> improve documentation indexing _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 15:22:31 2014 From: report at bugs.python.org (Berker Peksag) Date: Sat, 26 Apr 2014 13:22:31 +0000 Subject: [issue18185] Error in test_set.TestVariousIteratorArgs.test_inline_methods In-Reply-To: <1370916368.79.0.653461926178.issue18185@psf.upfronthosting.co.za> Message-ID: <1398518551.84.0.448774229048.issue18185@psf.upfronthosting.co.za> Berker Peksag added the comment: This was fixed in b6059bac8a9c. (see also issue 18944) ---------- resolution: -> out of date stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 15:27:45 2014 From: report at bugs.python.org (Berker Peksag) Date: Sat, 26 Apr 2014 13:27:45 +0000 Subject: [issue18944] Minor mistake in test_set.py In-Reply-To: <1378458771.78.0.221134021979.issue18944@psf.upfronthosting.co.za> Message-ID: <1398518865.43.0.14058390372.issue18944@psf.upfronthosting.co.za> Berker Peksag added the comment: The same typo also needs to be fixed in the 2.7 branch: http://hg.python.org/cpython/file/2.7/Lib/test/test_set.py#l1618 ---------- nosy: +berker.peksag resolution: fixed -> stage: resolved -> needs patch status: closed -> open versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 16:21:36 2014 From: report at bugs.python.org (Edd Barrett) Date: Sat, 26 Apr 2014 14:21:36 +0000 Subject: [issue21356] LibreSSL/RAND_egd fix needed. Message-ID: <1398522096.15.0.100207892067.issue21356@psf.upfronthosting.co.za> New submission from Edd Barrett: Hi, I'm sure you have heard about OpenBSD's LibreSSL fork of OpenSSL. There has been a lot of code reorganisation and removal. One function which was removed `RAND_egd()` breaks the CPython build. CPython no longer builds on OpenBSD. I have submitted a patch against PyPy already. The application library part of the change can probably be re-used since PyPy borrows CPython's application-level standard library (including the `ssl` and `socket` module). However, for the interpreter level change, the build system will probably have to be hacked. We need to check for the existence of `RAND_egd()` at configure time and only build in support if the function is found. The PyPy patch (and some discussion) is here: https://bitbucket.org/pypy/pypy/pull-request/233/fix-translation-for-libressl-and-fix-ssl/diff#comment-1744605 I may have a go at doing this myself (for Python-2.7 at least) if no-one steps up in the meantime; for now just making the CPython devs aware. Thanks ---------- components: Build messages: 217198 nosy: Edd.Barrett priority: normal severity: normal status: open title: LibreSSL/RAND_egd fix needed. versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 16:48:21 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 26 Apr 2014 14:48:21 +0000 Subject: [issue21356] LibreSSL/RAND_egd fix needed. In-Reply-To: <1398522096.15.0.100207892067.issue21356@psf.upfronthosting.co.za> Message-ID: <1398523701.86.0.529277240278.issue21356@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This should wait until the LibreSSL API stabilizes. Regardless, I think we should consider deprecating RAND_egd(). The Entropy Gathering Daemon doesn't seem to have seen a release for more than 10 years... (http://sourceforge.net/projects/egd/files/) ---------- nosy: +christian.heimes, dstufft, giampaolo.rodola, haypo, janssen, pitrou versions: -Python 2.7, Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 16:48:35 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 26 Apr 2014 14:48:35 +0000 Subject: [issue21356] LibreSSL/RAND_egd fix needed. In-Reply-To: <1398522096.15.0.100207892067.issue21356@psf.upfronthosting.co.za> Message-ID: <1398523715.44.0.539746597443.issue21356@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 16:49:00 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 26 Apr 2014 14:49:00 +0000 Subject: [issue21349] crash in winreg SetValueEx with memoryview In-Reply-To: <1398446482.48.0.369974839933.issue21349@psf.upfronthosting.co.za> Message-ID: <3gGFWH5PJgz7LjW@mail.python.org> Roundup Robot added the comment: New changeset 061db174baad by Tim Golden in branch '2.7': Issue21349 Passing a memoryview to _winreg.SetValueEx now correctly raises a TypeError where it previously crashed the interpreter. Patch by Brian Kearns http://hg.python.org/cpython/rev/061db174baad ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 16:50:05 2014 From: report at bugs.python.org (diana) Date: Sat, 26 Apr 2014 14:50:05 +0000 Subject: [issue21357] Increase filecmp test coverage from 63% to 76% Message-ID: <1398523805.84.0.496450374391.issue21357@psf.upfronthosting.co.za> New submission from diana: - Increase filecmp test coverage from 63% to 76% - I left the testing style as-is, though it could probably be modernized. - I did not attempt to add coverage for 'funny_files', 'subdirs', etc, next pass perhaps. - Before: diana$ ./python.exe ../coveragepy report --show-missing Name Stmts Miss Cover Missing ------------------------------------------- Lib/filecmp 163 61 63% 64, 80, 126, 130, 159-161, 164-166, 172, 174, 178-180, 190-194, 197-199, 203-224, 227-230, 233-236, 246, 293-302, 305 - After: diana$ ./python.exe ../coveragepy report --show-missing Name Stmts Miss Cover Missing ------------------------------------------- Lib/filecmp 163 39 76% 64, 80, 126, 130, 159-161, 164-166, 172, 174, 178-180, 192-194, 197-199, 217-218, 220-221, 223-224, 229-230, 235-236, 246, 293-302, 305 Thoughts? Thanks! ---------- components: Library (Lib) files: increase_filecmp_test_coverage.patch keywords: patch messages: 217201 nosy: diana priority: normal severity: normal status: open title: Increase filecmp test coverage from 63% to 76% type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file35045/increase_filecmp_test_coverage.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 17:02:27 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 26 Apr 2014 15:02:27 +0000 Subject: [issue21349] crash in winreg SetValueEx with memoryview In-Reply-To: <1398446482.48.0.369974839933.issue21349@psf.upfronthosting.co.za> Message-ID: <3gGFpp6fsdz7LjP@mail.python.org> Roundup Robot added the comment: New changeset 9c38cfc7bed7 by Tim Golden in branch '2.7': Add NEWS entry for issue21349 http://hg.python.org/cpython/rev/9c38cfc7bed7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 17:07:40 2014 From: report at bugs.python.org (Lukas Lueg) Date: Sat, 26 Apr 2014 15:07:40 +0000 Subject: [issue21213] Memory bomb by incorrect custom serializer to json.dumps In-Reply-To: <1397472980.58.0.747239124099.issue21213@psf.upfronthosting.co.za> Message-ID: <1398524860.23.0.108068192793.issue21213@psf.upfronthosting.co.za> Lukas Lueg added the comment: The behavior is triggered in Modules/_json.c:encoder_listencode_obj(). It actually has nothing to do with the TypeError itself, any object that produces a new string representation of itself will do. The function encoder_listencode_obj() calls the user-supplied function with the instance to get a string, float, integer or whatever it knows to how convert to json by itself. As the function keeps returning new instances of TypeError, the recursion builds up. The MemoryError is ultimately triggered by the fact that repr() keeps escaping all single quotes from the previous repr(), generating a huge string. Also see "repr(repr(repr("'")))" Testing with 2gb of ram and no swap (disable to to prevent starvation instead of immediate crash!), cpython dies within 34 recursion levels. The obj-parameter for encoder_listencode_obj() looks like "Foo(obj='\\\\\\\\\\\\\\\'>">\\\\\\\'>\\\'>\'>')". My two cents: This is expected behavior. The json-module has no way to tell in advance if the encoding-function never returns. The fact that repr() causes this blowup here can't be fixed. ---------- nosy: +ebfe _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 17:13:05 2014 From: report at bugs.python.org (Remi Pointel) Date: Sat, 26 Apr 2014 15:13:05 +0000 Subject: [issue21356] LibreSSL/RAND_egd fix needed. In-Reply-To: <1398522096.15.0.100207892067.issue21356@psf.upfronthosting.co.za> Message-ID: <1398525185.66.0.137942849657.issue21356@psf.upfronthosting.co.za> Changes by Remi Pointel : ---------- nosy: +rpointel _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 17:41:06 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 26 Apr 2014 15:41:06 +0000 Subject: [issue21357] Increase filecmp test coverage from 63% to 76% In-Reply-To: <1398523805.84.0.496450374391.issue21357@psf.upfronthosting.co.za> Message-ID: <1398526866.55.0.847899211629.issue21357@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 18:28:42 2014 From: report at bugs.python.org (saaj) Date: Sat, 26 Apr 2014 16:28:42 +0000 Subject: [issue21213] Memory bomb by incorrect custom serializer to json.dumps In-Reply-To: <1397472980.58.0.747239124099.issue21213@psf.upfronthosting.co.za> Message-ID: <1398529722.09.0.78008701975.issue21213@psf.upfronthosting.co.za> saaj added the comment: Well, as far as I see the question here is whether it makes sense to allow the default function to return JSON-incompatible objects. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 19:36:42 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 26 Apr 2014 17:36:42 +0000 Subject: [issue21355] Shallow defaults to True, not 1 [filecmp.cmp] In-Reply-To: <1398516393.36.0.153160280579.issue21355@psf.upfronthosting.co.za> Message-ID: <3gGKDn6yytz7Ljf@mail.python.org> Roundup Robot added the comment: New changeset b7fd640fb159 by Benjamin Peterson in branch '3.4': shallow defaults to 'True' not '1' (closes #21355) http://hg.python.org/cpython/rev/b7fd640fb159 New changeset 9ab6d13553ef by Benjamin Peterson in branch 'default': merge 3.4 (#21355) http://hg.python.org/cpython/rev/9ab6d13553ef ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 19:51:43 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 26 Apr 2014 17:51:43 +0000 Subject: [issue18944] Minor mistake in test_set.py In-Reply-To: <1378458771.78.0.221134021979.issue18944@psf.upfronthosting.co.za> Message-ID: <1398534703.68.0.741506077244.issue18944@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- assignee: tim.peters -> terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 19:56:48 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 26 Apr 2014 17:56:48 +0000 Subject: [issue18944] Minor mistake in test_set.py In-Reply-To: <1378458771.78.0.221134021979.issue18944@psf.upfronthosting.co.za> Message-ID: <3gGKgz1T8pz7Ljf@mail.python.org> Roundup Robot added the comment: New changeset de6047ea33e6 by Terry Jan Reedy in branch '2.7': Issue #18944: backport typo fix http://hg.python.org/cpython/rev/de6047ea33e6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 19:57:27 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 26 Apr 2014 17:57:27 +0000 Subject: [issue18944] Minor mistake in test_set.py In-Reply-To: <1378458771.78.0.221134021979.issue18944@psf.upfronthosting.co.za> Message-ID: <1398535047.06.0.63381601882.issue18944@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 20:08:47 2014 From: report at bugs.python.org (Lukas Lueg) Date: Sat, 26 Apr 2014 18:08:47 +0000 Subject: [issue21213] Memory bomb by incorrect custom serializer to json.dumps In-Reply-To: <1397472980.58.0.747239124099.issue21213@psf.upfronthosting.co.za> Message-ID: <1398535727.96.0.23530719206.issue21213@psf.upfronthosting.co.za> Lukas Lueg added the comment: It's perfectly fine for the function to return an object that can't be put directly into a json string. The function may not convert the object directly but in multiple steps; the encoder will call the function again with the new object until everything boils down to a str, an integer etc.. If one keeps returning objects that never converge to one of those basic types, the interpreter faces death by infinite recursion. The situation described here adds the oom condition caused by repr() blowing up. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 20:41:07 2014 From: report at bugs.python.org (saaj) Date: Sat, 26 Apr 2014 18:41:07 +0000 Subject: [issue21213] Memory bomb by incorrect custom serializer to json.dumps In-Reply-To: <1397472980.58.0.747239124099.issue21213@psf.upfronthosting.co.za> Message-ID: <1398537667.48.0.479994599464.issue21213@psf.upfronthosting.co.za> saaj added the comment: I'll try to be more specific at my point. There're two cases: 1. Scalar: NoneType, int, bool, float, str. Ended immediately. 2. Non-scalar: list/tuple, dict. Recursively traversed, which may result in subsequent calls to the custom function. If the return value is restricted to given types (what the encoder is capable on its own), it is harder to shoot oneself in the foot. In other words what's the point of returning arbitrary Python object from the function? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 20:51:06 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sat, 26 Apr 2014 18:51:06 +0000 Subject: [issue21357] Increase filecmp test coverage from 63% to 76% In-Reply-To: <1398523805.84.0.496450374391.issue21357@psf.upfronthosting.co.za> Message-ID: <1398538266.26.0.234709155773.issue21357@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 21:55:20 2014 From: report at bugs.python.org (Roman Inflianskas) Date: Sat, 26 Apr 2014 19:55:20 +0000 Subject: [issue19776] Provide expanduser() on Path objects In-Reply-To: <1385409778.55.0.842571848249.issue19776@psf.upfronthosting.co.za> Message-ID: <1398542120.23.0.351342436237.issue19776@psf.upfronthosting.co.za> Roman Inflianskas added the comment: I think that `absolute` method should call `expanduser` and `expandvars` (do you plan to include it?) automatically. This should be optional (via default arguments: `expanduser=True, expandvars=True`. ---------- nosy: +rominf _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 22:04:19 2014 From: report at bugs.python.org (Christopher Arndt) Date: Sat, 26 Apr 2014 20:04:19 +0000 Subject: [issue17679] sysconfig generation uses some env variables multiple times In-Reply-To: <1365515508.55.0.936246153534.issue17679@psf.upfronthosting.co.za> Message-ID: <1398542659.05.0.842162324129.issue17679@psf.upfronthosting.co.za> Christopher Arndt added the comment: Another solution may be to make the test more relaxed and regard the value returned by sysconfig.get_config_var() as a _set_ of shell tokens, whose elements may occur more than once, e.g. def test_sysconfig_module(self): import sysconfig as global_sysconfig from shlex import split self.assertEqual( set(split(global_sysconfig.get_config_var('CFLAGS'))), set(split(sysconfig.get_config_var('CFLAGS')))) self.assertEqual( set(split(global_sysconfig.get_config_var('LDFLAGS'))), set(split(sysconfig.get_config_var('LDFLAGS')))) ---------- nosy: +strogon14 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 22:38:16 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 26 Apr 2014 20:38:16 +0000 Subject: [issue21357] Increase filecmp test coverage from 63% to 76% In-Reply-To: <1398523805.84.0.496450374391.issue21357@psf.upfronthosting.co.za> Message-ID: <1398544696.34.0.376627642614.issue21357@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Thanks for the patch. I think you could use the support.catpured_stdout() context-manager in _assert_report. You should also sign the contributor agreement. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 22:38:59 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 26 Apr 2014 20:38:59 +0000 Subject: [issue21358] Augmented assignment doc: clarify 'only evaluated once' Message-ID: <1398544739.49.0.840910165962.issue21358@psf.upfronthosting.co.za> New submission from Terry J. Reedy: https://docs.python.org/3/reference/simple_stmts.html#augmented-assignment-statements "An augmented assignment expression like x += 1 can be rewritten as x = x + 1 to achieve a similar, but not exactly equal effect. In the augmented version, x is only evaluated once." As discussed and demonstrated as part of #21101 (see msg 215560) and following, this is not exactly true in current CPython. If the expression 'x' is 'y[k]', then the subscription is performed twice, once to get and once to set. Both y and k are still evaluated just once. def ob(): print('ob fetched') return d def key(): print('key called') return 0 d = [[]] ob()[key()] += [1] print(d) # prints ob fetched key called [[1]] I suggest changing "x is only evaluated once." to something like "x is usually only evaluated once. However, if x has the form y[k], y and k are evaluated once but the subscription may be done twice, once to get and once to set." I intentionally said 'subscription may be' rather than 'subscription is' because implementations should remain free to do the subscription (and the whole expression x) just once -- by directly replacing the reference to the old value in the internals of the mapping structure with a reference to the new value. #16701 discusses possible ambiguity in the next sentence, about 'in place'. ---------- assignee: docs at python components: Documentation messages: 217212 nosy: docs at python, terry.reedy priority: normal severity: normal stage: needs patch status: open title: Augmented assignment doc: clarify 'only evaluated once' type: enhancement versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 22:41:43 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 26 Apr 2014 20:41:43 +0000 Subject: [issue16701] Docs missing the behavior of += (in-place add) for lists. In-Reply-To: <1355690474.0.0.76209480062.issue16701@psf.upfronthosting.co.za> Message-ID: <1398544903.25.0.123542153626.issue16701@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Augmented assignment confuses enough people that I think we can improve the doc. In #21358 I suggest an augmented version of the previous claim, about evaluation just once. I think something here is needed perhaps even more. I have not decided what just yet. ---------- nosy: +terry.reedy versions: +Python 3.5 -Python 2.6, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 22:51:08 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 26 Apr 2014 20:51:08 +0000 Subject: [issue17145] memoryview(array.array) In-Reply-To: <1360170754.31.0.614797074916.issue17145@psf.upfronthosting.co.za> Message-ID: <3gGPY74lRsz7Ljn@mail.python.org> Roundup Robot added the comment: New changeset 0a2ac61729d2 by Stefan Krah in branch '2.7': Issue #17145: Document array.array buffer interface limitations. http://hg.python.org/cpython/rev/0a2ac61729d2 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 22:53:53 2014 From: report at bugs.python.org (Stefan Krah) Date: Sat, 26 Apr 2014 20:53:53 +0000 Subject: [issue17145] memoryview(array.array) In-Reply-To: <1360170754.31.0.614797074916.issue17145@psf.upfronthosting.co.za> Message-ID: <1398545633.02.0.170849703937.issue17145@psf.upfronthosting.co.za> Stefan Krah added the comment: I pushed a minimal patch that focuses on the array.array issue. For broader changes, I suggest to use #14198 (though it is unlikely tha anyone will work on it). ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 22:57:20 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 26 Apr 2014 20:57:20 +0000 Subject: [issue19385] dbm.dumb should be consistent when the database is closed In-Reply-To: <1382683121.03.0.174486602388.issue19385@psf.upfronthosting.co.za> Message-ID: <3gGPhH0lphz7LjM@mail.python.org> Roundup Robot added the comment: New changeset e8343cb98cc3 by Benjamin Peterson in branch '3.4': make operations on closed dumb databases raise a consistent exception (closes #19385) http://hg.python.org/cpython/rev/e8343cb98cc3 New changeset dbceba88b96e by Benjamin Peterson in branch 'default': merge 3.4 (#19385) http://hg.python.org/cpython/rev/dbceba88b96e ---------- nosy: +python-dev resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 23:01:50 2014 From: report at bugs.python.org (Stefan Krah) Date: Sat, 26 Apr 2014 21:01:50 +0000 Subject: [issue14198] Backport parts of the new memoryview documentation In-Reply-To: <1330939816.35.0.731110214123.issue14198@psf.upfronthosting.co.za> Message-ID: <1398546110.43.0.947039161478.issue14198@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- assignee: skrah -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 23:03:57 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 26 Apr 2014 21:03:57 +0000 Subject: [issue21358] Augmented assignment doc: clarify 'only evaluated once' In-Reply-To: <1398544739.49.0.840910165962.issue21358@psf.upfronthosting.co.za> Message-ID: <1398546237.47.0.497573586139.issue21358@psf.upfronthosting.co.za> Martin v. L?wis added the comment: This is not limited to dictionaries. Augmented assignment *always* involves a read operation and a write operation. So Antoine's remark in msg215573 is more general; a.x += 1 has a get and a set, and even x += 1 has a get and a set. I still agree that the original statement is confusing. It (implicitly) claims that x = x + 1 evaluates x twice, which it does not. Instead, x is only *evaluated* once, and then written to. Only if x has subexpressions, they get evaluated only once ("evaluation" being the thing that produces a "value"). ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 23:20:43 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 26 Apr 2014 21:20:43 +0000 Subject: [issue17305] IDNA2008 encoding missing In-Reply-To: <1361928766.42.0.728949411958.issue17305@psf.upfronthosting.co.za> Message-ID: <1398547243.69.0.862706637015.issue17305@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I would propose this approach: 1. Python should implement both IDNA2008 and UTS#46, and keep IDNA2003 2. "idna" should become an alias for "idna2003". 3. The socket module and all other place that use the "idna" encoding should use "uts46" instead. 4. Pre-existing implementations of IDNA 2008 should be used as inspirations at best; Python will need a new implementation from scratch, one that puts all relevant tables into the unicodedata module if they aren't there already. This is in particular where the idna 0.1 library fails. The implementation should refer to the relevant parts of the specification, to be easily reviewable for correctness. Contributions are welcome. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 23:52:44 2014 From: report at bugs.python.org (Ned Deily) Date: Sat, 26 Apr 2014 21:52:44 +0000 Subject: [issue21359] IDLE Redo command accelerator acts as Undo with current OS X Cocoa Tk 8.5.15 Message-ID: <1398549164.45.0.802525173407.issue21359@psf.upfronthosting.co.za> New submission from Ned Deily: With the current Cocoa Tk 8.5 (ActiveState 8.5.15), it appears that the IDLE Redo accelerator, Cmd-Shift-Z, has the same effect as the Undo accelerator, Cmd-Z. This is probably related to the behavior and changes in Cocoa Tk noted in Issue11055. With the older Apple-supplied Tk 8.5.9 on OS X 10.9, the Cmd-Shift-Z causes two Redos. Cmd-Shift-Z works correctly with Carbon Tk 8.4.20 (as linked with the 32-bit-only python.org installers) and selecting the Redo menu item, rather than using a keyboard shortcut, appears to work correctly with all versions. ---------- assignee: ned.deily messages: 217219 nosy: ned.deily priority: normal severity: normal status: open title: IDLE Redo command accelerator acts as Undo with current OS X Cocoa Tk 8.5.15 versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 26 23:57:06 2014 From: report at bugs.python.org (Ned Deily) Date: Sat, 26 Apr 2014 21:57:06 +0000 Subject: [issue21359] IDLE Redo command accelerator acts as Undo with current OS X Cocoa Tk 8.5.15 In-Reply-To: <1398549164.45.0.802525173407.issue21359@psf.upfronthosting.co.za> Message-ID: <1398549426.1.0.318569612054.issue21359@psf.upfronthosting.co.za> Ned Deily added the comment: Instigated by http://stackoverflow.com/questions/23316425/idle-redo-shortcut-vanished/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 00:06:43 2014 From: report at bugs.python.org (Lars Wirzenius) Date: Sat, 26 Apr 2014 22:06:43 +0000 Subject: [issue21360] mailbox.Maildir should ignore files named with a leading dot Message-ID: <1398550003.67.0.360972625113.issue21360@psf.upfronthosting.co.za> New submission from Lars Wirzenius: The maildir format specification (see http://cr.yp.to/proto/maildir.html) is clear that files named with leading dots should be ignore: Unless you're writing messages to a maildir, the format of a unique name is none of your business. A unique name can be anything that doesn't contain a colon (or slash) and doesn't start with a dot. Do not try to extract information from unique names. Test case: liw at havelock$ find Maildir -ls 8921206 4 drwxrwxr-x 5 liw liw 4096 Apr 26 23:03 Maildir 8921207 4 drwxrwxr-x 2 liw liw 4096 Apr 26 23:03 Maildir/cur 8921209 4 drwxrwxr-x 2 liw liw 4096 Apr 26 23:03 Maildir/tmp 8921208 4 drwxrwxr-x 2 liw liw 4096 Apr 26 23:03 Maildir/new 8913523 0 -rw-rw-r-- 1 liw liw 0 Apr 26 23:03 Maildir/new/.foo liw at havelock$ python -c 'import mailbox maildir = mailbox.Maildir("Maildir") print maildir.keys() ' ['.foo'] liw at havelock$ The correct output would be the empty list. "mutt -f Maildir" correctly shows now messages in that folder. ---------- components: Library (Lib) messages: 217221 nosy: liw priority: normal severity: normal status: open title: mailbox.Maildir should ignore files named with a leading dot type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 00:41:26 2014 From: report at bugs.python.org (diana) Date: Sat, 26 Apr 2014 22:41:26 +0000 Subject: [issue21357] Increase filecmp test coverage from 63% to 76% In-Reply-To: <1398523805.84.0.496450374391.issue21357@psf.upfronthosting.co.za> Message-ID: <1398552086.05.0.554397615261.issue21357@psf.upfronthosting.co.za> Changes by diana : Added file: http://bugs.python.org/file35046/increase_filecmp_test_coverage_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 00:43:40 2014 From: report at bugs.python.org (diana) Date: Sat, 26 Apr 2014 22:43:40 +0000 Subject: [issue21357] Increase filecmp test coverage from 63% to 76% In-Reply-To: <1398523805.84.0.496450374391.issue21357@psf.upfronthosting.co.za> Message-ID: <1398552220.33.0.532440622149.issue21357@psf.upfronthosting.co.za> Changes by diana : Removed file: http://bugs.python.org/file35046/increase_filecmp_test_coverage_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 00:50:11 2014 From: report at bugs.python.org (diana) Date: Sat, 26 Apr 2014 22:50:11 +0000 Subject: [issue21357] Increase filecmp test coverage from 63% to 76% In-Reply-To: <1398523805.84.0.496450374391.issue21357@psf.upfronthosting.co.za> Message-ID: <1398552611.77.0.578497351497.issue21357@psf.upfronthosting.co.za> diana added the comment: Nice, the support.catpured_stdout() context manager is much better. I've added a new patch with that change: increase_filecmp_test_coverage__updated_to_use_context_manager.patch Thanks for reviewing this, Benjamin! PS. I signed the contributor agreement. ---------- Added file: http://bugs.python.org/file35047/increase_filecmp_test_coverage__updated_to_use_context_manager.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 01:05:28 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 26 Apr 2014 23:05:28 +0000 Subject: [issue18243] mktime_tz documentation out-of-date In-Reply-To: <1371482642.16.0.49381484414.issue18243@psf.upfronthosting.co.za> Message-ID: <3gGSX71tctz7LjS@mail.python.org> Roundup Robot added the comment: New changeset d24f1fb256a3 by R David Murray in branch '3.4': #18243: Remove obsolete cautionary note from email mktime_tz docs. http://hg.python.org/cpython/rev/d24f1fb256a3 New changeset 462470859e57 by R David Murray in branch 'default': Merge: #18243: Remove obsolete cautionary note from email mktime_tz docs. http://hg.python.org/cpython/rev/462470859e57 New changeset d1a641ecbe33 by R David Murray in branch '2.7': #18243: Remove obsolete cautionary note from email mktime_tz docs. http://hg.python.org/cpython/rev/d1a641ecbe33 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 01:06:45 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 26 Apr 2014 23:06:45 +0000 Subject: [issue18243] mktime_tz documentation out-of-date In-Reply-To: <1371482642.16.0.49381484414.issue18243@psf.upfronthosting.co.za> Message-ID: <1398553605.38.0.0100066878947.issue18243@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, Akira. ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 01:38:52 2014 From: report at bugs.python.org (STINNER Victor) Date: Sat, 26 Apr 2014 23:38:52 +0000 Subject: [issue21302] time.sleep (floatsleep()) should use clock_nanosleep() on Linux In-Reply-To: <1397851923.06.0.0550198760464.issue21302@psf.upfronthosting.co.za> Message-ID: <1398555532.46.0.261091653857.issue21302@psf.upfronthosting.co.za> STINNER Victor added the comment: > I know that an earlier request to use nanosleep() has been rejected as "wontfix" It was the issue #13981. I created this issue while I worked on the PEP 410 (nanosecond timestamp). I closed the issue myself, it doesn't mean that Python must not use the function, just that I didn't want to work on it anymore at this time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 01:45:47 2014 From: report at bugs.python.org (STINNER Victor) Date: Sat, 26 Apr 2014 23:45:47 +0000 Subject: [issue21302] time.sleep (floatsleep()) should use clock_nanosleep() on Linux In-Reply-To: <1397851923.06.0.0550198760464.issue21302@psf.upfronthosting.co.za> Message-ID: <1398555947.17.0.804992135316.issue21302@psf.upfronthosting.co.za> STINNER Victor added the comment: "I'm working on a patch, but I noticed a similar issue in Condition.wait(), which also keeps re-evaluating the "remaining sleep time" based on the current kernel clock, with similar effects." I see that Lock.acquire(timeout) uses the C function gettimeofday() to recompute the timeout if acquiring the lock was interrupted (C error "EINTR"). It would be better to use a monotonic clock here, but please open a new issue because it's unrelated to nanosleep(). Or did you another bug? By the way, you didn't mention the Python version. Are you working on Python 2.7 or 3.5? See also the PEP 418. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 01:59:46 2014 From: report at bugs.python.org (STINNER Victor) Date: Sat, 26 Apr 2014 23:59:46 +0000 Subject: [issue21302] time.sleep (floatsleep()) should use clock_nanosleep() on Linux In-Reply-To: <1397851923.06.0.0550198760464.issue21302@psf.upfronthosting.co.za> Message-ID: <1398556786.4.0.0243407245973.issue21302@psf.upfronthosting.co.za> STINNER Victor added the comment: If you want to modify time.sleep(), you must be careful of the portability: Windows, Linux, but also Mac OS X, FreeBSD, Solaris, etc. Try to describe the behaviour of each underlying C function on each platform to be able to describe the "portable behaviour" on all platforms, especially the expected behaviour when the system clock is changed (is time.sleep impacted or not? always?) and the expected behaviour when the system is suspended. For example, it looks like nanosleep() uses a different clock depending on OS (Linux uses CLOCK_MONOTONIC, other UNIX platforms use CLOCK_REALTIME). http://lists.gnu.org/archive/html/bug-coreutils/2012-08/msg00087.html I know that you suggest to use clock_nanosleep(), but this function is not available on all platforms. For example, I would not use it on Windows. Another example (on Fedora?): "sleep() ignores time spent with a suspended system" http://mjg59.dreamwidth.org/7846.html You should also decide how to handle interrupted sleep (C error "EINTR"). Currently, the sleep is interrupted, no error is raised. I began to describe all these functions in the PEP 418, even if I didn't change the implementation with the PEP: http://legacy.python.org/dev/peps/pep-0418/#sleep ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 02:05:50 2014 From: report at bugs.python.org (STINNER Victor) Date: Sun, 27 Apr 2014 00:05:50 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1398557150.79.0.531385722906.issue21233@psf.upfronthosting.co.za> STINNER Victor added the comment: I read again some remarks about alignement, it was suggested to provide allocators providing an address aligned to a requested alignement. This topic was already discussed in #18835. If Python doesn't provide such memory allocators, it was suggested to provide a "trace" function which can be called on the result of a successful allocator to "trace" an allocation (and a similar function for free). But this is very different from the design of the PEP 445 (new malloc API). Basically, it requires to rewrite the PEP 445. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 02:11:24 2014 From: report at bugs.python.org (STINNER Victor) Date: Sun, 27 Apr 2014 00:11:24 +0000 Subject: [issue18835] Add aligned memory variants to the suite of PyMem functions/macros In-Reply-To: <1377484371.18.0.399621580043.issue18835@psf.upfronthosting.co.za> Message-ID: <1398557484.56.0.453604083699.issue18835@psf.upfronthosting.co.za> STINNER Victor added the comment: It looks like a memory allocator with a given alignment would help numpy, for SIMD instructions: https://mail.python.org/pipermail/python-dev/2014-April/134092.html (but "Numpy does not currently use aligned allocation, and it's not clear how important it is") See also this old discussion on python-dev: https://mail.python.org/pipermail/python-dev/2010-September/103911.html Related to this website: http://mallocv2.wordpress.com/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 02:22:27 2014 From: report at bugs.python.org (STINNER Victor) Date: Sun, 27 Apr 2014 00:22:27 +0000 Subject: [issue21220] Enhance obmalloc allocation strategy In-Reply-To: <1397499786.06.0.606856949694.issue21220@psf.upfronthosting.co.za> Message-ID: <1398558147.47.0.214927235948.issue21220@psf.upfronthosting.co.za> STINNER Victor added the comment: I spend some nights to try to understand the memory usage of the following Python script: https://bitbucket.org/haypo/misc/src/31bf03ace91db3998981ee56caf80f09c29991f5/memory/python_memleak.py?at=default It looks like the weird memory usage (aka "memory fragmentation"?) was fixed in Python 3.3. > This significantly helps fragmentation in programs with dynamic memory usage, e.g. long running programs. On which programs? The fragmentation of the memory depends a lot on how the program allocates memory. For example, if a program has no "temporary memory peak", it should not be a victim of the memory fragmentation. To measure the improvment of such memory allocator, more benchmarks (speed and fragmentation) should be run than a single test (memcruch.py included in the test) written to benchmark the allocator. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 02:23:54 2014 From: report at bugs.python.org (STINNER Victor) Date: Sun, 27 Apr 2014 00:23:54 +0000 Subject: [issue21216] getaddrinfo is wrongly considered thread safe on linux In-Reply-To: <1397496103.55.0.0681287877532.issue21216@psf.upfronthosting.co.za> Message-ID: <1398558234.63.0.774707709814.issue21216@psf.upfronthosting.co.za> STINNER Victor added the comment: @Julien.Palard: Ping? Without more information, I would suggest to close the issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 02:26:10 2014 From: report at bugs.python.org (STINNER Victor) Date: Sun, 27 Apr 2014 00:26:10 +0000 Subject: [issue20924] openssl init 100% CPU utilization on Windows In-Reply-To: <1394807354.77.0.238568366714.issue20924@psf.upfronthosting.co.za> Message-ID: <1398558370.5.0.508200835547.issue20924@psf.upfronthosting.co.za> STINNER Victor added the comment: > Please also report the Windows version you are using. I don't see the answer to this question ---------- title: openssl init 100% CPU utilization -> openssl init 100% CPU utilization on Windows _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 02:26:44 2014 From: report at bugs.python.org (Shankar Unni) Date: Sun, 27 Apr 2014 00:26:44 +0000 Subject: [issue21302] time.sleep (floatsleep()) should use clock_nanosleep() on Linux In-Reply-To: <1397851923.06.0.0550198760464.issue21302@psf.upfronthosting.co.za> Message-ID: <1398558404.11.0.140799587927.issue21302@psf.upfronthosting.co.za> Shankar Unni added the comment: > If you want to modify time.sleep(), you must be careful of the portability: Windows, Linux, but also Mac OS X, FreeBSD, Solaris, etc. Oh, I totally agree. What I'm trying to do is to define another autoconf flag (HAVE_CLOCK_NANOSLEEP), that does a feature test and enable that flag, and just use that if available. Now that's a good point that if we have clock_nanosleep() on another platform (non-Linux) and it does the wrong thing, then I might have to add further discrimination. For now, one sticking point that I've stumbled across is that clock_nanosleep() requires "-lrt". Complicates the autoconf check a bit. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 02:28:08 2014 From: report at bugs.python.org (STINNER Victor) Date: Sun, 27 Apr 2014 00:28:08 +0000 Subject: [issue21090] File read silently stops after EIO I/O error In-Reply-To: <1396045786.33.0.781369785301.issue21090@psf.upfronthosting.co.za> Message-ID: <1398558488.33.0.153315360133.issue21090@psf.upfronthosting.co.za> STINNER Victor added the comment: @ivank: Can you please answer to questions? It's hard to understand the issue. Without more information, I would suggest to close the issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 02:28:51 2014 From: report at bugs.python.org (STINNER Victor) Date: Sun, 27 Apr 2014 00:28:51 +0000 Subject: [issue21356] Support LibreSSL (instead of OpenSSL): make RAND_egd optional In-Reply-To: <1398522096.15.0.100207892067.issue21356@psf.upfronthosting.co.za> Message-ID: <1398558531.81.0.441469836236.issue21356@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: LibreSSL/RAND_egd fix needed. -> Support LibreSSL (instead of OpenSSL): make RAND_egd optional _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 02:31:02 2014 From: report at bugs.python.org (STINNER Victor) Date: Sun, 27 Apr 2014 00:31:02 +0000 Subject: [issue21351] refcounts not respected at process exit In-Reply-To: <1398454746.98.0.985879059912.issue21351@psf.upfronthosting.co.za> Message-ID: <1398558662.51.0.802120910312.issue21351@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 02:31:49 2014 From: report at bugs.python.org (STINNER Victor) Date: Sun, 27 Apr 2014 00:31:49 +0000 Subject: [issue17552] Add a new socket.sendfile() method In-Reply-To: <1364326073.47.0.699222209849.issue17552@psf.upfronthosting.co.za> Message-ID: <1398558709.03.0.521806101473.issue17552@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: socket.sendfile() -> Add a new socket.sendfile() method _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 02:32:15 2014 From: report at bugs.python.org (STINNER Victor) Date: Sun, 27 Apr 2014 00:32:15 +0000 Subject: [issue21350] bug in file.writelines accepting buffers In-Reply-To: <1398444021.42.0.983935463224.issue21350@psf.upfronthosting.co.za> Message-ID: <1398558735.35.0.803671997296.issue21350@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 02:32:27 2014 From: report at bugs.python.org (STINNER Victor) Date: Sun, 27 Apr 2014 00:32:27 +0000 Subject: [issue21225] io.py: Improve docstrings for classes In-Reply-To: <1397508646.21.0.210626779275.issue21225@psf.upfronthosting.co.za> Message-ID: <1398558747.02.0.555280770231.issue21225@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 02:36:47 2014 From: report at bugs.python.org (STINNER Victor) Date: Sun, 27 Apr 2014 00:36:47 +0000 Subject: [issue21302] time.sleep (floatsleep()) should use clock_nanosleep() on Linux In-Reply-To: <1398558404.11.0.140799587927.issue21302@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: 2014-04-27 2:26 GMT+02:00 Shankar Unni : >> If you want to modify time.sleep(), you must be careful of the portability: Windows, Linux, but also Mac OS X, FreeBSD, Solaris, etc. > > Oh, I totally agree. What I'm trying to do is to define another autoconf flag (HAVE_CLOCK_NANOSLEEP), that does a feature test and enable that flag, and just use that if available. I'm talking about the expected behaviour which can be found in the documentation of the function: https://docs.python.org/dev/library/time.html#time.sleep ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 03:01:14 2014 From: report at bugs.python.org (Tim Peters) Date: Sun, 27 Apr 2014 01:01:14 +0000 Subject: [issue21351] refcounts not respected at process exit In-Reply-To: <1398454746.98.0.985879059912.issue21351@psf.upfronthosting.co.za> Message-ID: <1398560474.24.0.0647850529214.issue21351@psf.upfronthosting.co.za> Tim Peters added the comment: After more thought, I don't think the user can do anything to influence finalization order in cases like this, short of adding "del" statements (or moral equivalents) to break cycles before the interpreter shuts down. Fine by me ;-) Something CPython could do, when collecting cyclic trash, is pick on objects with the smallest refcount first. That would most often mimic the finalization-order effects of the old bind-module-globals-to-None hack. But it would require more code and more expense to impose a partial order, and would still be an implementation detail specific to CPython (the implementation, as opposed to Python the language). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 05:26:50 2014 From: report at bugs.python.org (ivank) Date: Sun, 27 Apr 2014 03:26:50 +0000 Subject: [issue21090] File read silently stops after EIO I/O error In-Reply-To: <1396045786.33.0.781369785301.issue21090@psf.upfronthosting.co.za> Message-ID: <1398569210.87.0.611331429032.issue21090@psf.upfronthosting.co.za> ivank added the comment: I'm finding it hard to reproduce the bug again with more zpool corruption. (I see the `IOError: [Errno 5] Input/output error` exception now.) I do remember that in the reported case, Python 3.4, node.js, and OpenJDK 7 threw an EIO exception, but Python 2.7 did not. I tested this multiple times. Right now I can only speculate that Python 2.7 silently stops reading only in certain cases, e.g. depending on how Python's reads are aligned with the first byte that causes EIO. I'm still working on getting it reproduced, please hold off on closing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 06:14:44 2014 From: report at bugs.python.org (Jessica McKellar) Date: Sun, 27 Apr 2014 04:14:44 +0000 Subject: [issue9850] obsolete macpath module dangerously broken and should be removed In-Reply-To: <1284441709.03.0.73507598284.issue9850@psf.upfronthosting.co.za> Message-ID: <1398572084.65.0.00212321875221.issue9850@psf.upfronthosting.co.za> Jessica McKellar added the comment: Thanks for writing up this issue, ned.deily, and thanks for providing a patch, chortos. I couldn't find documentation clearly specifying what the correct behavior of macpath.join should be (i.e. what are the exact rules for leading and trailing colons), but comparing the old and updated behavior against the new tests, this patch does make the function's behavior more consistent. * The patch passes `make patchcheck`. * The full test suite passes with this patch. => commit review ---------- keywords: +needs review nosy: +jesstess stage: needs patch -> commit review versions: +Python 2.7, Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 06:41:05 2014 From: report at bugs.python.org (Jessica McKellar) Date: Sun, 27 Apr 2014 04:41:05 +0000 Subject: [issue21361] Add how to run a single test case to the devguide Message-ID: <1398573664.98.0.323689557818.issue21361@psf.upfronthosting.co.za> New submission from Jessica McKellar: I had wanted to run a single TestCase, or single TestCase test method, and saw that how to do this wasn't in the devguide. Pattern-matching from the other rules doesn't work (for now, you have to use unittest instead of test), and asking on IRC, many people didn't know it was possible. :) This patch adds documentation on how to run a single TestCase. I visually inspected the built HTML to confirm that it looks as desired. ---------- components: Devguide files: devguide.diff keywords: easy, needs review, patch messages: 217239 nosy: ezio.melotti, jesstess priority: normal severity: normal stage: patch review status: open title: Add how to run a single test case to the devguide type: enhancement Added file: http://bugs.python.org/file35048/devguide.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 08:24:21 2014 From: report at bugs.python.org (paul j3) Date: Sun, 27 Apr 2014 06:24:21 +0000 Subject: [issue14074] argparse allows nargs>1 for positional arguments but doesn't allow metavar to be a tuple In-Reply-To: <1329845918.75.0.31962840333.issue14074@psf.upfronthosting.co.za> Message-ID: <1398579861.35.0.661200526277.issue14074@psf.upfronthosting.co.za> paul j3 added the comment: This patch fixes both help and error formatting. A module level '_format_metavars' does the formatting for both. I have tried several alternatives, including using the 'usage' style. There is similarity between this fix and that for issue 16468 (custom choices), though I don't think they conflict. In both cases, code needed to format the usage or help is also needed to help format error messages. Issue 9849 (better nargs warning) is another case where error checking in the parser depends on the formatter. In the long run we may want to refactor these issues. ---------- Added file: http://bugs.python.org/file35049/issue14074_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 08:41:54 2014 From: report at bugs.python.org (Jessica McKellar) Date: Sun, 27 Apr 2014 06:41:54 +0000 Subject: [issue11709] help-method crashes if sys.stdin is None In-Reply-To: <1301390764.04.0.564019544953.issue11709@psf.upfronthosting.co.za> Message-ID: <1398580914.66.0.681211806245.issue11709@psf.upfronthosting.co.za> Jessica McKellar added the comment: Thanks for reporting this, palm.kevin, and thanks for the patch, amaury.forgeotdarc. First, just to be explicit here's a short reproducer: import sys sys.stdin = None help(1) (Note that to get to the isatty check you need to provide an argument and it has to be something that has help, so `help()` and `help("a")` don't exercise this code path) Also, here is where sys.stdin can be set to None: http://hg.python.org/cpython/file/dbceba88b96e/Python/pythonrun.c#l1201 The provided patch fixes the above test case; instead of erroring out with the traceback in the original bug report, the plain pager is used and the help message is printed to stdout. Anyone on the nosy list interested in writing some tests? ---------- nosy: +jesstess stage: patch review -> test needed versions: +Python 3.5 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 10:30:36 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 27 Apr 2014 08:30:36 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1398557150.79.0.531385722906.issue21233@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > I read again some remarks about alignement, it was suggested to provide allocators providing an address aligned to a requested alignement. This topic was already discussed in #18835. The alignement issue is really orthogonal to the calloc one, so IMO this shouldn't be discussed here (and FWIW I don't think we should expose those: alignement only matters either for concurrency or SIMD instructions, and I don't think we should try to standardize this kind of API, it's way to special-purpose (then we'd have to think about huge pages, etc...). Whereas calloc is a simple and immediately useful addition, not only for Numpy but also CPython). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 11:30:49 2014 From: report at bugs.python.org (akira) Date: Sun, 27 Apr 2014 09:30:49 +0000 Subject: [issue19940] ssl.cert_time_to_seconds() returns wrong results if local timezone is not UTC In-Reply-To: <1386660552.46.0.291263983729.issue19940@psf.upfronthosting.co.za> Message-ID: <1398591049.4.0.0916886472257.issue19940@psf.upfronthosting.co.za> akira added the comment: Here's a new patch with a simplified ssl.cert_time_to_seconds() implementation that brings strptime() back. The behaviour is changed: - accept both %e and %d strftime formats for days as strptime-based implementation did before - return an integer instead of a float (input date has not fractions of a second) I've added more tests. Please, review. ---------- Added file: http://bugs.python.org/file35050/ssl_cert_time_to_seconds-462470859e57.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 11:49:21 2014 From: report at bugs.python.org (STINNER Victor) Date: Sun, 27 Apr 2014 09:49:21 +0000 Subject: [issue21090] File read silently stops after EIO I/O error In-Reply-To: <1398569210.87.0.611331429032.issue21090@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: 2014-04-27 5:26 GMT+02:00 ivank : > (I see the `IOError: [Errno 5] Input/output error` exception now.) Can you please run your test in strace to see system calls? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 11:49:47 2014 From: report at bugs.python.org (akira) Date: Sun, 27 Apr 2014 09:49:47 +0000 Subject: [issue19940] ssl.cert_time_to_seconds() returns wrong results if local timezone is not UTC In-Reply-To: <1386660552.46.0.291263983729.issue19940@psf.upfronthosting.co.za> Message-ID: <1398592187.37.0.890023946035.issue19940@psf.upfronthosting.co.za> akira added the comment: Replace IndexError with ValueError in the patch because tuple.index raises ValueError. ---------- Added file: http://bugs.python.org/file35051/ssl_cert_time_to_seconds-ps5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 11:51:46 2014 From: report at bugs.python.org (STINNER Victor) Date: Sun, 27 Apr 2014 09:51:46 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: Message-ID: STINNER Victor added the comment: 2014-04-27 10:30 GMT+02:00 Charles-Fran?ois Natali : >> I read again some remarks about alignement, it was suggested to provide allocators providing an address aligned to a requested alignement. This topic was already discussed in #18835. > > The alignement issue is really orthogonal to the calloc one, so IMO > this shouldn't be discussed here (and FWIW I don't think we should > expose those: alignement only matters either for concurrency or SIMD > instructions, and I don't think we should try to standardize this kind > of API, it's way to special-purpose (then we'd have to think about > huge pages, etc...). Whereas calloc is a simple and immediately useful > addition, not only for Numpy but also CPython). This issue was opened to be able to use tracemalloc on numpy. I would like to make sure that calloc is enough for numpy. I would prefer to change the malloc API only once. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 11:59:39 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Sun, 27 Apr 2014 09:59:39 +0000 Subject: [issue19950] Document that unittest.TestCase.__init__ is called once per test In-Reply-To: <1386714858.72.0.878231586551.issue19950@psf.upfronthosting.co.za> Message-ID: <1398592779.16.0.305572564568.issue19950@psf.upfronthosting.co.za> Claudiu.Popa added the comment: In Python 3 docs there is a hint in the documentation for `loadTestsFromModule`: "This method searches module for classes derived from TestCase and creates an instance of the class for each test method defined for the class." The phrase with a fixture per test from Python 2 docs is gone though. It would be nice if the same explanation from loadTestsFromModule could be applied to TestCase documentation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 12:11:12 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Sun, 27 Apr 2014 10:11:12 +0000 Subject: [issue20642] Enhance deepcopy-ing for tuples In-Reply-To: <1392587167.09.0.0900280350163.issue20642@psf.upfronthosting.co.za> Message-ID: <1398593472.14.0.105568789427.issue20642@psf.upfronthosting.co.za> Claudiu.Popa added the comment: Ping? The change is clear, has the same semantics and its a little bit faster. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 12:14:18 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Sun, 27 Apr 2014 10:14:18 +0000 Subject: [issue18039] dbm.open(..., flag="n") does not work and does not give a warning In-Reply-To: <1369269598.14.0.669972141851.issue18039@psf.upfronthosting.co.za> Message-ID: <1398593658.18.0.556536406477.issue18039@psf.upfronthosting.co.za> Claudiu.Popa added the comment: Can anyone review this patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 12:17:52 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Sun, 27 Apr 2014 10:17:52 +0000 Subject: [issue18615] sndhdr.whathdr could return a namedtuple In-Reply-To: <1375370275.79.0.808837089288.issue18615@psf.upfronthosting.co.za> Message-ID: <1398593872.08.0.258885787554.issue18615@psf.upfronthosting.co.za> Claudiu.Popa added the comment: Ping. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 12:21:00 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 27 Apr 2014 10:21:00 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: Message-ID: Charles-Fran?ois Natali added the comment: > This issue was opened to be able to use tracemalloc on numpy. I would > like to make sure that calloc is enough for numpy. I would prefer to > change the malloc API only once. Then please at least rename the issue. Also, I don't see why everything should be done at once: calloc support is a self-contained change, which is useful outside of numpy. Enhanced tracemalloc support for numpy certainly belongs to another issue. Regarding the *Calloc functions: how about we provide a sane API instead of reproducing the cumbersome C API? I mean, why not expose: PyAPI_FUNC(void *) PyMem_Calloc(size_t size); insteaf of PyAPI_FUNC(void *) PyMem_Calloc(size_t nelem, size_t elsize); AFAICT, the two arguments are purely historical (it was used when malloc() didn't guarantee suitable alignment, and has the advantage of performing overflow check when doing the multiplication, but in our code we always check for it anyway). See https://groups.google.com/forum/#!topic/comp.lang.c/jZbiyuYqjB4 http://stackoverflow.com/questions/4083916/two-arguments-to-calloc And http://www.eglibc.org/cgi-bin/viewvc.cgi/trunk/libc/malloc/malloc.c?view=markup to check that calloc(nelem, elsize) is implemented as calloc(nelem * elsize) I'm also concerned about the change to _PyObject_GC_Malloc(): it now calls calloc() instead of malloc(): it can definitely be slower. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 12:32:47 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 27 Apr 2014 10:32:47 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: Message-ID: Charles-Fran?ois Natali added the comment: Note to numpy devs: it would be great if some of you followed the python-dev mailing list (I know it can be quite volume intensive, but maybe simple filters could help keep the noise down): you guys have definitely both expertise and real-life applications that could be very valuable in helping us design the best possible public/private APIs. It's always great to have downstream experts/end-users! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 12:36:05 2014 From: report at bugs.python.org (STINNER Victor) Date: Sun, 27 Apr 2014 10:36:05 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1398594965.45.0.6620318757.issue21233@psf.upfronthosting.co.za> STINNER Victor added the comment: I wrote a short microbenchmark allocating objects using my benchmark.py script. It looks like the operation "(None,) * N" is slower with calloc-3.patch, but it's unclear how much times slower it is. I don't understand why only this operation has different speed. Do you have ideas for other benchmarks? Using the timeit module: $ ./python.orig -m timeit '(None,) * 10**5' 1000 loops, best of 3: 357 usec per loop $ ./python.calloc -m timeit '(None,) * 10**5' 1000 loops, best of 3: 698 usec per loop But with different parameters, the difference is lower: $ ./python.orig -m timeit -r 20 -n '1000' '(None,) * 10**5' 1000 loops, best of 20: 362 usec per loop $ ./python.calloc -m timeit -r 20 -n '1000' '(None,) * 10**5' 1000 loops, best of 20: 392 usec per loop Results of bench_alloc.py: Common platform: CFLAGS: -Wno-unused-result -Werror=declaration-after-statement -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes CPU model: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz Python unicode implementation: PEP 393 Timer info: namespace(adjustable=False, implementation='clock_gettime(CLOCK_MONOTONIC)', monotonic=True, resolution=1e-09) Timer: time.perf_counter SCM: hg revision=462470859e57+ branch=default date="2014-04-26 19:01 -0400" Platform: Linux-3.13.8-200.fc20.x86_64-x86_64-with-fedora-20-Heisenbug Bits: int=32, long=64, long long=64, size_t=64, void*=64 Platform of campaign orig: Timer precision: 42 ns Date: 2014-04-27 12:27:26 Python version: 3.5.0a0 (default:462470859e57, Apr 27 2014, 11:52:55) [GCC 4.8.2 20131212 (Red Hat 4.8.2-7)] Platform of campaign calloc: Timer precision: 45 ns Date: 2014-04-27 12:29:10 Python version: 3.5.0a0 (default:462470859e57+, Apr 27 2014, 12:04:57) [GCC 4.8.2 20131212 (Red Hat 4.8.2-7)] -----------------------------------+--------------+--------------- Tests????????????????????????????? | ????????orig | ????????calloc -----------------------------------+--------------+--------------- object()?????????????????????????? | ???61 ns (*) | ?????????62 ns b'A' * 10????????????????????????? | ???55 ns (*) | ???51 ns (-7%) b'A' * 10**3?????????????????????? | ???99 ns (*) | ?????????94 ns b'A' * 10**6?????????????????????? | ?37.5 us (*) | ???????36.6 us 'A' * 10?????????????????????????? | ???62 ns (*) | ???58 ns (-7%) 'A' * 10**3??????????????????????? | ??107 ns (*) | ????????104 ns 'A' * 10**6??????????????????????? | ???37 us (*) | ???????36.6 us 'A' * 10**8??????????????????????? | ?16.2 ms (*) | ???????16.4 ms decode 10 null bytes from ASCII??? | ??253 ns (*) | ????????248 ns decode 10**3 null bytes from ASCII | ??359 ns (*) | ????????357 ns decode 10**6 null bytes from ASCII | ?78.8 us (*) | ???????78.7 us decode 10**8 null bytes from ASCII | ?26.2 ms (*) | ???????25.9 ms (None,) * 10**0??????????????????? | ???30 ns (*) | ?????????30 ns (None,) * 10**1??????????????????? | ???78 ns (*) | ?????????77 ns (None,) * 10**2??????????????????? | ??427 ns (*) | ??460 ns (+8%) (None,) * 10**3??????????????????? | ??3.5 us (*) | ??3.7 us (+6%) (None,) * 10**4??????????????????? | ?34.7 us (*) | ?37.2 us (+7%) (None,) * 10**5??????????????????? | ??357 us (*) | ??390 us (+9%) (None,) * 10**6??????????????????? | ?3.86 ms (*) | 4.43 ms (+15%) (None,) * 10**7??????????????????? | ?50.4 ms (*) | ???????50.3 ms (None,) * 10**8??????????????????? | ??505 ms (*) | ????????504 ms ([None] * 10)[1:-1]??????????????? | ??121 ns (*) | ????????120 ns ([None] * 10**3)[1:-1]???????????? | ?3.57 us (*) | ???????3.57 us ([None] * 10**6)[1:-1]???????????? | ?4.61 ms (*) | ???????4.59 ms ([None] * 10**8)[1:-1]???????????? | ??585 ms (*) | ????????582 ms -----------------------------------+--------------+--------------- Total????????????????????????????? | 1.19 sec (*) | ??????1.19 sec -----------------------------------+--------------+--------------- ---------- Added file: http://bugs.python.org/file35052/bench_alloc.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 13:02:55 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 27 Apr 2014 11:02:55 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1398596575.29.0.202574699719.issue21233@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Regarding the *Calloc functions: how about we provide a sane API > instead of reproducing the cumbersome C API? Isn't the point of reproducing the C API to allow quickly switching from calloc() to PyObject_Calloc()? (besides, it seems the OpenBSD guys like the two-argument form :-)) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 13:05:55 2014 From: report at bugs.python.org (Stefan Krah) Date: Sun, 27 Apr 2014 11:05:55 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1398596755.82.0.649392736362.issue21233@psf.upfronthosting.co.za> Stefan Krah added the comment: Just to add another data point, I don't find the calloc() API cumbersome. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 13:06:45 2014 From: report at bugs.python.org (Stefan Krah) Date: Sun, 27 Apr 2014 11:06:45 +0000 Subject: [issue20230] structseq types should expose _fields In-Reply-To: <1389575574.46.0.402404595733.issue20230@psf.upfronthosting.co.za> Message-ID: <1398596805.63.0.306990485866.issue20230@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 13:12:44 2014 From: report at bugs.python.org (STINNER Victor) Date: Sun, 27 Apr 2014 11:12:44 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1398597164.17.0.618208848538.issue21233@psf.upfronthosting.co.za> STINNER Victor added the comment: It looks like calloc-3.patch is wrong: it modify _PyObject_GC_Malloc() to fill the newly allocated buffer with zeros, but _PyObject_GC_Malloc() is not only called by PyType_GenericAlloc(): it is also used by _PyObject_GC_New() and _PyObject_GC_NewVar(). The patch is maybe a little bit slower because it writes zeros twice. calloc.patch adds "PyObject* _PyObject_GC_Calloc(size_t);" and doesn't have this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 13:13:30 2014 From: report at bugs.python.org (Stefan Krah) Date: Sun, 27 Apr 2014 11:13:30 +0000 Subject: [issue1820] Enhance Object/structseq.c to match namedtuple and tuple api In-Reply-To: <1200284428.58.0.762384814897.issue1820@psf.upfronthosting.co.za> Message-ID: <1398597210.8.0.175076430769.issue1820@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 13:26:55 2014 From: report at bugs.python.org (Stefan Krah) Date: Sun, 27 Apr 2014 11:26:55 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1398598015.2.0.930172577148.issue21233@psf.upfronthosting.co.za> Stefan Krah added the comment: Actually, I think we have to match the C-API: For instance, in Modules/_decimal/_decimal.c:5527 the libmpdec allocators are set to the Python allocators. So I'd need to do: mpd_callocfunc = PyMem_Calloc; I suppose that's a common use case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 13:39:29 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Sun, 27 Apr 2014 11:39:29 +0000 Subject: [issue21362] concurrent.futures does not validate that max_workers is proper Message-ID: <1398598769.27.0.217084820664.issue21362@psf.upfronthosting.co.za> New submission from Claudiu.Popa: Due to some bad math on my side, I passed max_workers=0 to concurrent.futures.ThreadPoolExecutor. This didn't fail properly, but hanged. The same behaviour occurs in ProcessPoolExecutor, but this time it fails internally with something like this: Exception in thread Thread-1: Traceback (most recent call last): File "C:\Python34\lib\threading.py", line 921, in _bootstrap_inner self.run() File "C:\Python34\lib\threading.py", line 869, in run self._target(*self._args, **self._kwargs) File "C:\Python34\lib\concurrent\futures\process.py", line 225, in _queue_management_worker assert sentinels AssertionError The attached patch checks that *max_workers* is <= 0 and raises ValueError if so. ---------- components: Library (Lib) files: futures_max_workers.patch keywords: patch messages: 217258 nosy: Claudiu.Popa, bquinlan priority: normal severity: normal status: open title: concurrent.futures does not validate that max_workers is proper type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file35053/futures_max_workers.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 13:41:04 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Sun, 27 Apr 2014 11:41:04 +0000 Subject: [issue21362] concurrent.futures does not validate that max_workers is proper In-Reply-To: <1398598769.27.0.217084820664.issue21362@psf.upfronthosting.co.za> Message-ID: <1398598864.93.0.689589568425.issue21362@psf.upfronthosting.co.za> Claudiu.Popa added the comment: For instance, multiprocessing behaves like this: >>> multiprocessing.Pool(-1) Traceback (most recent call last): File "", line 1, in File "C:\Python34\lib\multiprocessing\context.py", line 118, in Pool context=self.get_context()) File "C:\Python34\lib\multiprocessing\pool.py", line 157, in __init__ raise ValueError("Number of processes must be at least 1") ValueError: Number of processes must be at least 1 >>> ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 14:56:29 2014 From: report at bugs.python.org (Armin Ronacher) Date: Sun, 27 Apr 2014 12:56:29 +0000 Subject: [issue21363] io.TextIOWrapper always closes wrapped files Message-ID: <1398603389.33.0.793055654008.issue21363@psf.upfronthosting.co.za> New submission from Armin Ronacher: I'm trying to write some code that fixes a misconfigured sys.stdin on a case by case bases but unfortunately I cannot use TextIOWrapper for this because it always closes the underlying file: Python >>> import io >>> sys.stdin.encoding 'ANSI_X3.4-1968' >>> stdin = sys.stdin >>> correct_stdin = io.TextIOWrapper(stdin.buffer, 'utf-8') >>> correct_stdin.readline() foobar 'foobar\n' >>> del correct_stdin >>> stdin.readline() Traceback (most recent call last): File "", line 1, in ValueError: I/O operation on closed file. Ideally there would be a way to disable this behavior. ---------- messages: 217260 nosy: aronacher priority: normal severity: normal status: open title: io.TextIOWrapper always closes wrapped files _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 15:00:19 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Sun, 27 Apr 2014 13:00:19 +0000 Subject: [issue16104] Compileall script: add option to use multiple cores In-Reply-To: <1349124414.14.0.0730954283721.issue16104@psf.upfronthosting.co.za> Message-ID: <1398603619.88.0.353572982134.issue16104@psf.upfronthosting.co.za> Claudiu.Popa added the comment: Added a new patch with improvements suggested by Jim. Thanks! I removed the handling of processes=1, because it can still be useful: having a background worker which processes the files received from _walk_dir. Also, it checks that compile_dir receives a positive *processes* value, otherwise it raises a ValueError. As a side note, I just found that ProcessPoolExecutor / ThreadPoolExecutor don't verify the value of processes, leading to certain types of errors (see issue21362 for more details). Jim, the default for processes is still None, meaning "do not use multiple process", because the purpose of ProcessPoolExecutor makes it easy for it to use processes=None=os.cpu_count(). Here we want the user to be explicit about wanting multiple processes or not. ---------- Added file: http://bugs.python.org/file35054/issue16104_9.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 15:19:03 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 27 Apr 2014 13:19:03 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1398597164.17.0.618208848538.issue21233@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > It looks like calloc-3.patch is wrong: it modify _PyObject_GC_Malloc() to fill the newly allocated buffer with zeros, but _PyObject_GC_Malloc() is not only called by PyType_GenericAlloc(): it is also used by _PyObject_GC_New() and _PyObject_GC_NewVar(). The patch is maybe a little bit slower because it writes zeros twice. Exactly (sorry, I thought you'd already seen that, otherwise I could have told you!) > Actually, I think we have to match the C-API: For instance, in > Modules/_decimal/_decimal.c:5527 the libmpdec allocators are > set to the Python allocators. Hmm, ok then, I didn't know we were plugging our allocators for external libraries: that's indeed a very good reason to keep the same prototype. But I still find this API cumbersome: calloc is exactly like malloc except for the zeroing, so the prototype could be simpler (a quick look at Victor's patch shows a lot of calloc(1, n), which is a sign something's wrong). Maybe it's just me ;-) Otherwise, a random thought: by changing PyType_GenericAlloc() from malloc() + memset(0) to calloc(), there could be a subtle side effect: if a given type relies on the 0-setting (which is documented), and doesn't do any other work on the allocated area behind the scenes (think about a mmap-like object), we could lose our capacity to detect MemoryError, and run into segfaults instead. Because if a code creates many such objects which basically just do calloc(), on operating systems with memory overommitting (such as Linux), the calloc() allocations will pretty much always succeed, but will segfault when the page is first written to in case of low memory. I don't think such use cases should be common: I would expect most types to use tp_alloc(type, 0) and then use an internal additional pointer for the allocations it needs, or immediately write to the allocated memory area right after allocation, but that's something to keep in mind. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 15:33:27 2014 From: report at bugs.python.org (Steven D'Aprano) Date: Sun, 27 Apr 2014 13:33:27 +0000 Subject: [issue16104] Compileall script: add option to use multiple cores In-Reply-To: <1349124414.14.0.0730954283721.issue16104@psf.upfronthosting.co.za> Message-ID: <1398605607.05.0.920500701946.issue16104@psf.upfronthosting.co.za> Changes by Steven D'Aprano : ---------- nosy: -steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 16:01:47 2014 From: report at bugs.python.org (Berker Peksag) Date: Sun, 27 Apr 2014 14:01:47 +0000 Subject: [issue21225] io.py: Improve docstrings for classes In-Reply-To: <1397508646.21.0.210626779275.issue21225@psf.upfronthosting.co.za> Message-ID: <1398607307.23.0.315163661525.issue21225@psf.upfronthosting.co.za> Berker Peksag added the comment: Can this be closed? (or needs backport to 2.7? http://hg.python.org/cpython/file/2.7/Lib/io.py#l69) ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 16:06:47 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Sun, 27 Apr 2014 14:06:47 +0000 Subject: [issue16104] Compileall script: add option to use multiple cores In-Reply-To: <1349124414.14.0.0730954283721.issue16104@psf.upfronthosting.co.za> Message-ID: <1398607607.74.0.802972569651.issue16104@psf.upfronthosting.co.za> Claudiu.Popa added the comment: Add new patch with fixes proposed by Berker Peksag. Thanks for the review. Hopefully, this is the last iteration of this patch. ---------- Added file: http://bugs.python.org/file35055/issue16104_10.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 16:18:13 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 27 Apr 2014 14:18:13 +0000 Subject: [issue21090] File read silently stops after EIO I/O error In-Reply-To: <1396045786.33.0.781369785301.issue21090@psf.upfronthosting.co.za> Message-ID: <1398608293.82.0.317571617151.issue21090@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: I'm with Antoine, it's likely a glibc bug. We already had a similar issue with fwrite(): http://bugs.python.org/issue17976 ---------- nosy: +neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 16:20:08 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 27 Apr 2014 14:20:08 +0000 Subject: [issue21090] File read silently stops after EIO I/O error In-Reply-To: <1396045786.33.0.781369785301.issue21090@psf.upfronthosting.co.za> Message-ID: <1398608408.8.0.339485324719.issue21090@psf.upfronthosting.co.za> Antoine Pitrou added the comment: ivank, if you know some C, perhaps you could write a trivial program that does an fopen() followed by an fread() of 131072 bytes, and see if the fread() errors out. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 16:44:53 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 27 Apr 2014 14:44:53 +0000 Subject: [issue21361] Add how to run a single test case to the devguide In-Reply-To: <1398573664.98.0.323689557818.issue21361@psf.upfronthosting.co.za> Message-ID: <3gGsN459wvz7LjN@mail.python.org> Roundup Robot added the comment: New changeset 6b912c90de72 by Benjamin Peterson in branch 'default': say how to run one test (closes #21361) http://hg.python.org/devguide/rev/6b912c90de72 ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 16:54:10 2014 From: report at bugs.python.org (Tim Golden) Date: Sun, 27 Apr 2014 14:54:10 +0000 Subject: [issue21349] crash in winreg SetValueEx with memoryview In-Reply-To: <1398446482.48.0.369974839933.issue21349@psf.upfronthosting.co.za> Message-ID: <1398610450.2.0.0187843383504.issue21349@psf.upfronthosting.co.za> Tim Golden added the comment: Committed. Thanks for the patch. ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 17:01:23 2014 From: report at bugs.python.org (Eric V. Smith) Date: Sun, 27 Apr 2014 15:01:23 +0000 Subject: [issue21320] dict() allows keyword expansion with integer keys, e.g. dict(**{5:'v'}) In-Reply-To: <1398081299.38.0.288058317096.issue21320@psf.upfronthosting.co.za> Message-ID: <1398610883.88.0.337264496688.issue21320@psf.upfronthosting.co.za> Eric V. Smith added the comment: I agree with Raymond: this isn't a practical problem worth solving. If it's causing an actual problem, please re-open this issue and give a use case. Thanks. ---------- nosy: +eric.smith resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 17:03:53 2014 From: report at bugs.python.org (Armin Ronacher) Date: Sun, 27 Apr 2014 15:03:53 +0000 Subject: [issue21364] Documentation Recommends Broken Pattern Message-ID: <1398611033.23.0.241148860666.issue21364@psf.upfronthosting.co.za> New submission from Armin Ronacher: The documentation recommends replacing sys.stdin with a binary stream currently: https://docs.python.org/3/library/sys.html#sys.stdin This sounds like a bad idea because it will break pretty much everything in Python in the process. As example: >>> import sys >>> sys.stdin = sys.stdin.detach() >>> input('Test: ') Traceback (most recent call last): File "", line 1, in AttributeError: '_io.BufferedReader' object has no attribute 'errors' >>> sys.stdout = sys.stdout.detach() >>> print('Hello World!') Traceback (most recent call last): File "", line 1, in TypeError: 'str' does not support the buffer interface ---------- messages: 217270 nosy: aronacher priority: normal severity: normal status: open title: Documentation Recommends Broken Pattern _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 17:37:07 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 27 Apr 2014 15:37:07 +0000 Subject: [issue9291] mimetypes initialization fails on Windows because of non-Latin characters in registry In-Reply-To: <1279454095.41.0.733053669611.issue9291@psf.upfronthosting.co.za> Message-ID: <3gGtXL1cyYz7Lk2@mail.python.org> Roundup Robot added the comment: New changeset 18cfc2a42772 by Tim Golden in branch '2.7': Issue #9291 Do not attempt to re-encode mimetype data read from registry in ANSI mode. Initial patches by Dmitry Jemerov & Vladimir Iofik http://hg.python.org/cpython/rev/18cfc2a42772 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 17:38:18 2014 From: report at bugs.python.org (Paul Sokolovsky) Date: Sun, 27 Apr 2014 15:38:18 +0000 Subject: [issue21365] asyncio.Task reference misses the most important fact about it, related info spread around intros and example commentary instead Message-ID: <1398613098.75.0.265677522517.issue21365@psf.upfronthosting.co.za> New submission from Paul Sokolovsky: It caused me a big surprise that asyncio.Task object automatically schedules itself in the main loop for execution upon creation (i.e. in constructor). Nowhere in the main reference part of section "18.5.2.4. Task" (https://docs.python.org/3.5/library/asyncio-task.html#task) does it mention that fact. Vice versa, it explicitly says that Task is merely "A coroutine object wrapped in a Future.", which surely sets grounds for surprise when finding that Task is not just coroutine wrapped in Future, but exhibits extra behavior unexpected of plain Future. Docs cursorily mention this property of Task outside main reference section for it. Specifically: 1) "18.5.2.1. Coroutines", end of intro section: "In the case of a coroutine object, there are two basic ways to start it running: call yield from coroutine from another coroutine (assuming the other coroutine is already running!), or convert it to a Task." I would argue that this is way too cursorily and doesn't put strong enough emphasis on the property of self-scheduling, to catch attention of novice or casual reader. For example, my entailments after reading the passage above are: "... or convert it to a Task, to schedule it in a loop [explicitly], because a coroutine can't be scheduled in a loop directly, but Task can be". 2) Very end of subsection "18.5.2.4.1. Example: Parallel execution of tasks", a short line squeezed between colored example block and new section heading - a place where some user will miss it outright: "A task is automatically scheduled for execution when it is created." Based on case study above, I would like to propose: 1). In section "18.5.2.4. Task", in class description, make unmissable fact that instantiating an object makes it scheduled. For example, append after: "A coroutine object wrapped in a Future. Subclass of Future." following: "Instantiating object of this class automatically schedules it to be run in an event loop specified by 'loop' parameter (or default event loop)." 2) Ideally, update 2 excerpts above to convey more explicit information, and be more visible (for case 2, for example, move it before the example, not after). ---------- assignee: docs at python components: Documentation messages: 217272 nosy: docs at python, pfalcon priority: normal severity: normal status: open title: asyncio.Task reference misses the most important fact about it, related info spread around intros and example commentary instead type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 17:39:48 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 27 Apr 2014 15:39:48 +0000 Subject: [issue9291] mimetypes initialization fails on Windows because of non-Latin characters in registry In-Reply-To: <1279454095.41.0.733053669611.issue9291@psf.upfronthosting.co.za> Message-ID: <3gGtbR3tpNz7Lkg@mail.python.org> Roundup Robot added the comment: New changeset 0c8a7299c7e3 by Tim Golden in branch '2.7': Issue #9291 Add ACKS & NEWS http://hg.python.org/cpython/rev/0c8a7299c7e3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 17:43:01 2014 From: report at bugs.python.org (STINNER Victor) Date: Sun, 27 Apr 2014 15:43:01 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1398613381.6.0.0251398335923.issue21233@psf.upfronthosting.co.za> STINNER Victor added the comment: "And http://www.eglibc.org/cgi-bin/viewvc.cgi/trunk/libc/malloc/malloc.c?view=markup to check that calloc(nelem, elsize) is implemented as calloc(nelem * elsize)" __libc_calloc() starts with a check on integer overflow. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 17:44:45 2014 From: report at bugs.python.org (Paul Sokolovsky) Date: Sun, 27 Apr 2014 15:44:45 +0000 Subject: [issue21365] asyncio.Task reference misses the most important fact about it, related info spread around intros and example commentary instead In-Reply-To: <1398613098.75.0.265677522517.issue21365@psf.upfronthosting.co.za> Message-ID: <1398613485.44.0.527820272992.issue21365@psf.upfronthosting.co.za> Paul Sokolovsky added the comment: Based on discussion https://groups.google.com/forum/#!topic/python-tulip/zfMQIUcIR-0 . That discussion actually questions the grounds of such Task behavior, and points it as a violation of "Explicit is better than implicit" principle, and as inconsistent behavior wrt to similar objects in Python stdlib (threads, processes, etc.) This ticket however assumes that there're very good reasons for such behavior, and/or it just should be accepted as API idiosyncrasy which is late to fix, and just tries to make sure that docs are not culprit for mismatching user expectations. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 17:59:55 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 27 Apr 2014 15:59:55 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1398613381.6.0.0251398335923.issue21233@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > __libc_calloc() starts with a check on integer overflow. Yes, see my previous message: """ AFAICT, the two arguments are purely historical (it was used when malloc() didn't guarantee suitable alignment, and has the advantage of performing overflow check when doing the multiplication, but in our code we always check for it anyway). """ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 18:12:19 2014 From: report at bugs.python.org (Jon Brandvein) Date: Sun, 27 Apr 2014 16:12:19 +0000 Subject: [issue21366] Document that return in finally overwrites prev value Message-ID: <1398615139.09.0.290952002497.issue21366@psf.upfronthosting.co.za> New submission from Jon Brandvein: def foo(): try: return 1 finally; return 2 print(foo()) # 2 I've seen this peculiar case discussed on a few blogs lately, but was unable to find confirmation that this behavior is defined. In the try/finally section of Doc/reference/compound_stmts.rst, immediately after the sentence beginning > When a return, break, or continue statement is executed I propose adding something to the effect of: > A return statement in a finally clause overrides the value of any return statement executed in the try suite. This wording also handles the case of nested try/finally blocks. ---------- assignee: docs at python components: Documentation messages: 217277 nosy: brandjon, docs at python priority: normal severity: normal status: open title: Document that return in finally overwrites prev value type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 18:13:19 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Sun, 27 Apr 2014 16:13:19 +0000 Subject: [issue16104] Compileall script: add option to use multiple cores In-Reply-To: <1349124414.14.0.0730954283721.issue16104@psf.upfronthosting.co.za> Message-ID: <1398615199.52.0.29930194148.issue16104@psf.upfronthosting.co.za> Changes by Claudiu.Popa : Added file: http://bugs.python.org/file35056/issue16104_11.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 18:21:14 2014 From: report at bugs.python.org (eryksun) Date: Sun, 27 Apr 2014 16:21:14 +0000 Subject: [issue21363] io.TextIOWrapper always closes wrapped files In-Reply-To: <1398603389.33.0.793055654008.issue21363@psf.upfronthosting.co.za> Message-ID: <1398615674.3.0.74282725447.issue21363@psf.upfronthosting.co.za> eryksun added the comment: It works if you detach the buffer beforehand: >>> import io, sys >>> stdin = sys.stdin >>> stdin.flush() >>> correct_stdin = io.TextIOWrapper(stdin.buffer, 'utf-8') >>> correct_stdin.readline() foobar 'foobar\n' >>> correct_stdin.detach() <_io.BufferedReader name=''> >>> del correct_stdin >>> stdin.readline() foobar 'foobar\n' ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 18:22:54 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 27 Apr 2014 16:22:54 +0000 Subject: [issue21342] multiprocessing RLock and Lock raise incorrect exceptions when releasing an unlocked lock. In-Reply-To: <1398319251.34.0.871128764935.issue21342@psf.upfronthosting.co.za> Message-ID: <1398615774.6.0.471464674031.issue21342@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Thanks for the patch. That's IMO a good change, but I would only apply it to default, and not backport it. ---------- nosy: +neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 18:27:05 2014 From: report at bugs.python.org (Berker Peksag) Date: Sun, 27 Apr 2014 16:27:05 +0000 Subject: [issue21365] asyncio.Task reference misses the most important fact about it, related info spread around intros and example commentary instead In-Reply-To: <1398613098.75.0.265677522517.issue21365@psf.upfronthosting.co.za> Message-ID: <1398616025.58.0.0147254443267.issue21365@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +giampaolo.rodola, gvanrossum, haypo, pitrou, yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 18:30:17 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Sun, 27 Apr 2014 16:30:17 +0000 Subject: [issue21362] concurrent.futures does not validate that max_workers is proper In-Reply-To: <1398598769.27.0.217084820664.issue21362@psf.upfronthosting.co.za> Message-ID: <1398616217.39.0.727593947095.issue21362@psf.upfronthosting.co.za> Claudiu.Popa added the comment: Attached patch with improvements suggested by Charles-Fran?ois Natali. Thank you for the review. ---------- Added file: http://bugs.python.org/file35057/issue21362.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 18:31:43 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 27 Apr 2014 16:31:43 +0000 Subject: [issue21305] PEP 466: update os.urandom In-Reply-To: <1397868674.52.0.918643592406.issue21305@psf.upfronthosting.co.za> Message-ID: <1398616303.68.0.514450011947.issue21305@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Like Antoine, I'm really skeptical about the backport: honestly, this change doesn't bring much in a normal application. To run into the number of open file descriptors limit (so the "scalability" aspect), one would need to have *many* concurrent threads reading from /dev/urandom. For the "performance" aspect, I have a hard time believing that the overhead of the extra open() + close() syscalls is significant in a realistic workload. If reading from /dev/urandom becomes a bottleneck, this means that you're depleting your entropy pool anyway, so you're in for some potential trouble... > There is a reason we don't backport new features! Couldn't agree more. This whole "let's backport security enhancements" sounds scary to me. ---------- nosy: +neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 18:31:56 2014 From: report at bugs.python.org (STINNER Victor) Date: Sun, 27 Apr 2014 16:31:56 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1398616316.22.0.571366717942.issue21233@psf.upfronthosting.co.za> STINNER Victor added the comment: list: items are allocated in a second memory block. PyList_New() uses memset(0) to set all items to NULL. tuple: header and items are stored in a single structure (PyTupleObject), in a single memory block. PyTuple_New() fills the items will NULL (so write again null bytes). Something can be optimized here. dict: header, keys and values are stored in 3 different memory blocks. It may be interesting to use calloc() to allocate keys and values. Initialization of keys and values to NULL uses a dummy loop. I expect that memset(0) would be faster. Anyway, I expect that all items of builtin containers (tuple, list, dict, etc.) are set to non-NULL values. So the lazy initialization to zeros may be useless for them. It means that benchmarking builtin containers should not show any speedup. Something else (numpy?) should be used to see an interesting speedup. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 18:38:51 2014 From: report at bugs.python.org (STINNER Victor) Date: Sun, 27 Apr 2014 16:38:51 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1398616731.4.0.50026045517.issue21233@psf.upfronthosting.co.za> STINNER Victor added the comment: "Because if a code creates many such objects which basically just do calloc(), on operating systems with memory overommitting (such as Linux), the calloc() allocations will pretty much always succeed, but will segfault when the page is first written to in case of low memory." Overcommit leads to segmentation fault when there is no more memory, but I don't see how calloc() is worse then malloc()+memset(0). It will crash in both cases, no? In my experience (embedded device with low memory), programs crash because they don't check the result of malloc() (return NULL on allocation failure), not because of overcommit. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 18:39:10 2014 From: report at bugs.python.org (Nathaniel Smith) Date: Sun, 27 Apr 2014 16:39:10 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1398616750.43.0.230171095582.issue21233@psf.upfronthosting.co.za> Nathaniel Smith added the comment: @Charles-Fran?ois: I think your worries about calloc and overcommit are unjustified. First, calloc and malloc+memset actually behave the same way here -- with a large allocation and overcommit enabled, malloc and calloc will both go ahead and return the large allocation, and then the actual out-of-memory (OOM) event won't occur until the memory is accessed. In the malloc+memset case this access will occur immediately after the malloc, during the memset -- but this is still too late for us to detect the malloc failure. Second, OOM does not cause segfaults on any system I know. On Linux it wakes up the OOM killer, which shoots some random (possibly guilty) process in the head. The actual program which triggered the OOM is quite likely to escape unscathed. In practice, the *only* cases where you can get a MemoryError on modern systems are (a) if the user has turned overcommit off, (b) you're on a tiny embedded system that doesn't have overcommit, (c) if you run out of virtual address space. None of these cases are affected by the differences between malloc and calloc. Regarding the calloc API: it's a wart, but it seems like a pretty unavoidable wart at this point, and the API compatibility argument is strong. I think we should just keep the two argument form and live with it... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 18:42:53 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 27 Apr 2014 16:42:53 +0000 Subject: [issue20962] Rather modest chunk size in gzip.GzipFile In-Reply-To: <1395082726.87.0.730756156096.issue20962@psf.upfronthosting.co.za> Message-ID: <1398616973.17.0.111041328706.issue20962@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: William, thanks for the benchmarks. Unfortunately this type of benchmark depends on the hardware (disk, SSD, emmoey bandwitdh, etc). So I'd suggest, instead of using an hardcoded value, to simply reuse io.DEFAULT_BUFFER_SIZE. That way, if some day we decide to change it, all user code wil benefit from the change. ---------- nosy: +neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 18:52:52 2014 From: report at bugs.python.org (Florent Xicluna) Date: Sun, 27 Apr 2014 16:52:52 +0000 Subject: [issue21364] Documentation Recommends Broken Pattern In-Reply-To: <1398611033.23.0.241148860666.issue21364@psf.upfronthosting.co.za> Message-ID: <1398617572.93.0.671544507372.issue21364@psf.upfronthosting.co.za> Changes by Florent Xicluna : ---------- components: +IO nosy: +benjamin.peterson, flox, hynek, pitrou, stutzbach type: -> behavior versions: +Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 18:57:10 2014 From: report at bugs.python.org (Florent Xicluna) Date: Sun, 27 Apr 2014 16:57:10 +0000 Subject: [issue21362] concurrent.futures does not validate that max_workers is proper In-Reply-To: <1398598769.27.0.217084820664.issue21362@psf.upfronthosting.co.za> Message-ID: <1398617830.32.0.67420770401.issue21362@psf.upfronthosting.co.za> Changes by Florent Xicluna : ---------- nosy: +flox stage: -> patch review versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 19:00:10 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 27 Apr 2014 17:00:10 +0000 Subject: [issue21364] Documentation Recommends Broken Pattern In-Reply-To: <1398611033.23.0.241148860666.issue21364@psf.upfronthosting.co.za> Message-ID: <1398618010.71.0.487890133542.issue21364@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Initial introduction is 59cb9c074e09. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 19:00:22 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Sun, 27 Apr 2014 17:00:22 +0000 Subject: [issue21362] concurrent.futures does not validate that max_workers is proper In-Reply-To: <1398598769.27.0.217084820664.issue21362@psf.upfronthosting.co.za> Message-ID: <1398618021.99.0.971200775692.issue21362@psf.upfronthosting.co.za> Changes by Claudiu.Popa : Added file: http://bugs.python.org/file35058/issue21362_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 19:00:29 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 27 Apr 2014 17:00:29 +0000 Subject: [issue18314] Have os.unlink remove junction points In-Reply-To: <1372335321.1.0.479247042071.issue18314@psf.upfronthosting.co.za> Message-ID: <3gGwNX45XVz7Llc@mail.python.org> Roundup Robot added the comment: New changeset 17df50df62c7 by Tim Golden in branch 'default': Issue #18314 os.unlink will now remove junction points on Windows. Patch by Kim Gr?sman. http://hg.python.org/cpython/rev/17df50df62c7 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 19:03:01 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 27 Apr 2014 17:03:01 +0000 Subject: [issue18314] Have os.unlink remove junction points In-Reply-To: <1372335321.1.0.479247042071.issue18314@psf.upfronthosting.co.za> Message-ID: <3gGwRS56xVz7LkZ@mail.python.org> Roundup Robot added the comment: New changeset 4b97092aa4bd by Tim Golden in branch 'default': Issue #18314 Add NEWS item. http://hg.python.org/cpython/rev/4b97092aa4bd ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 19:12:14 2014 From: report at bugs.python.org (Lee Clemens) Date: Sun, 27 Apr 2014 17:12:14 +0000 Subject: [issue21367] multiprocessing.JoinableQueue requires new kwarg Message-ID: <1398618734.12.0.810845662855.issue21367@psf.upfronthosting.co.za> New submission from Lee Clemens: Not mentioned (at least not specifically) in the release notes, multiprocessing.JoinableQueue now requires 'ctx' keyword argument: def __init__(self, maxsize=0, *, ctx): This causes an application calling JoinableQueue() to work with 3.3.2 (my single test) to work, but not with 3.4.0 TypeError: __init__() missing 1 required keyword-only argument: 'ctx' The documentation is also incorrect: https://docs.python.org/3.4/library/multiprocessing.html#multiprocessing.JoinableQueue ---------- components: Interpreter Core messages: 217289 nosy: sftw at leeclemens.net priority: normal severity: normal status: open title: multiprocessing.JoinableQueue requires new kwarg type: compile error versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 19:25:45 2014 From: report at bugs.python.org (Lee Clemens) Date: Sun, 27 Apr 2014 17:25:45 +0000 Subject: [issue21367] multiprocessing.JoinableQueue requires new kwarg In-Reply-To: <1398618734.12.0.810845662855.issue21367@psf.upfronthosting.co.za> Message-ID: <1398619545.63.0.655274410233.issue21367@psf.upfronthosting.co.za> Lee Clemens added the comment: Same issue (ctx keyword) occurs with multiprocessing.queues.SimpleQueue ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 19:28:15 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Sun, 27 Apr 2014 17:28:15 +0000 Subject: [issue21367] multiprocessing.JoinableQueue requires new kwarg In-Reply-To: <1398618734.12.0.810845662855.issue21367@psf.upfronthosting.co.za> Message-ID: <1398619695.71.0.38211390925.issue21367@psf.upfronthosting.co.za> Changes by Claudiu.Popa : ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 19:29:04 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 27 Apr 2014 17:29:04 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1398616750.43.0.230171095582.issue21233@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > @Charles-Fran?ois: I think your worries about calloc and overcommit are unjustified. First, calloc and malloc+memset actually behave the same way here -- with a large allocation and overcommit enabled, malloc and calloc will both go ahead and return the large allocation, and then the actual out-of-memory (OOM) event won't occur until the memory is accessed. In the malloc+memset case this access will occur immediately after the malloc, during the memset -- but this is still too late for us to detect the malloc failure. Not really: what you describe only holds for a single object. But if you allocate let's say 1000 such objects at once: - in the malloc + memset case, the committed pages are progressively accessed (i.e. the pages for object N are accessed before the memory is allocated for object N+1), so they will be counted not only as committed, but also as active (for example the RSS will increase gradually): so at some point, even though by default the Linux VM subsystem is really lenient toward overcommitting, you'll likely have malloc/mmap return NULL because of this - in the calloc() case, all the memory is first committed, but not touched: the kernel will likely happily overcommit all of this. Only when you start progressively accessing the pages will the OOM kick in. > Second, OOM does not cause segfaults on any system I know. On Linux it wakes up the OOM killer, which shoots some random (possibly guilty) process in the head. The actual program which triggered the OOM is quite likely to escape unscathed. Ah, did I say segfault? Sorry, I of course meant that the process will get nuked by the OOM killer. > In practice, the *only* cases where you can get a MemoryError on modern systems are (a) if the user has turned overcommit off, (b) you're on a tiny embedded system that doesn't have overcommit, (c) if you run out of virtual address space. None of these cases are affected by the differences between malloc and calloc. That's a common misconception: provided that the memory allocated is accessed progressively (see above point), you'll often get ENOMEM, even with overcommitting: $ /sbin/sysctl -a | grep overcommit vm.nr_overcommit_hugepages = 0 vm.overcommit_memory = 0 vm.overcommit_ratio = 50 $ cat /tmp/test.py l = [] with open('/proc/self/status') as f: try: for i in range(50000000): l.append(i) except MemoryError: for line in f: if 'VmPeak' in line: print(line) raise $ python /tmp/test.py VmPeak: 720460 kB Traceback (most recent call last): File "/tmp/test.py", line 7, in l.append(i) MemoryError I have a 32-bit machine, but the process definitely has more than 720MB of address space ;-) If your statement were true, this would mean that it's almost impossible to get ENOMEM with overcommitting on a 64-bit machine, which is - fortunately - not true. Just try python -c "[i for i in range()]" on a 64-bit machine, I'll bet you'll get a MemoryError (ENOMEM). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 19:37:48 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 27 Apr 2014 17:37:48 +0000 Subject: [issue21305] PEP 466: update os.urandom In-Reply-To: <1398616303.68.0.514450011947.issue21305@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: Yep, it's scary indeed, but such a long lived feature release is a novel situation that may require some adjustments to our risk management. However, we can still decide to defer some of the changes until 2.7.8, even though the notion of backporting them has been approved in principle. For 2.7.7, we should probably focus on the more essential SSL enhancements. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 19:38:31 2014 From: report at bugs.python.org (Tim Golden) Date: Sun, 27 Apr 2014 17:38:31 +0000 Subject: [issue18314] Have os.unlink remove junction points In-Reply-To: <1372335321.1.0.479247042071.issue18314@psf.upfronthosting.co.za> Message-ID: <1398620311.74.0.772719907712.issue18314@psf.upfronthosting.co.za> Tim Golden added the comment: Backed out the commits after all the Windows buildbots broke. Need to look further. (No problems on a Win7 or Ubuntu build here). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 19:40:15 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 27 Apr 2014 17:40:15 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1398620415.46.0.26027827755.issue21233@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Just try python -c "[i for i in > range()]" on a 64-bit machine, I'll bet you'll get a > MemoryError (ENOMEM). Hmm, I get an OOM kill here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 19:41:49 2014 From: report at bugs.python.org (Nathaniel Smith) Date: Sun, 27 Apr 2014 17:41:49 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1398620509.5.0.0569535389024.issue21233@psf.upfronthosting.co.za> Nathaniel Smith added the comment: On my laptop (x86-64, Linux 3.13, 12 GB RAM): $ python3 -c "[i for i in range(999999999)]" zsh: killed python3 -c "[i for i in range(999999999)]" $ dmesg | tail -n 2 [404714.401901] Out of memory: Kill process 10752 (python3) score 687 or sacrifice child [404714.401903] Killed process 10752 (python3) total-vm:17061508kB, anon-rss:10559004kB, file-rss:52kB And your test.py produces the same result. Are you sure you don't have a ulimit set on address space? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 19:47:36 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 27 Apr 2014 17:47:36 +0000 Subject: [issue21340] Possible concurrency bug in asyncio, AttributeError in tasks.py In-Reply-To: <1398305622.34.0.507325141901.issue21340@psf.upfronthosting.co.za> Message-ID: <3gGxQv4T2rz7LpS@mail.python.org> Roundup Robot added the comment: New changeset d42d3d3f9c41 by Guido van Rossum in branch '3.4': asyncio: Be careful accessing instance variables in __del__ (closes #21340). http://hg.python.org/cpython/rev/d42d3d3f9c41 New changeset 0cb436c6f082 by Guido van Rossum in branch 'default': Merge 3.4 -> default: asyncio: Be careful accessing instance variables in __del__ (closes #21340). http://hg.python.org/cpython/rev/0cb436c6f082 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 19:48:44 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 27 Apr 2014 17:48:44 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1398620509.5.0.0569535389024.issue21233@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > And your test.py produces the same result. Are you sure you don't have a ulimit set on address space? Yep, I'm sure: $ ulimit -v unlimited It's probably due to the exponential over-allocation used by the array (to guarantee amortized constant cost). How about: python -c "b = bytes('x' * )" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 19:53:22 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 27 Apr 2014 17:53:22 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: Message-ID: Charles-Fran?ois Natali added the comment: Dammit, read: python -c 'b"x" * (2**48)' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 19:54:56 2014 From: report at bugs.python.org (Jessica McKellar) Date: Sun, 27 Apr 2014 17:54:56 +0000 Subject: [issue5001] Remove assertion-based checking in multiprocessing In-Reply-To: <1232382762.58.0.610641171059.issue5001@psf.upfronthosting.co.za> Message-ID: <1398621296.91.0.934951079422.issue5001@psf.upfronthosting.co.za> Jessica McKellar added the comment: Thanks for the patches, vladris! I've reviewed the latest version, and it addresses all of Antoine's review feedback. Ezio left some additional feedback (http://bugs.python.org/review/5001/#ps3407) which still needs to be addressed. ---------- nosy: +jesstess _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 20:13:18 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 27 Apr 2014 18:13:18 +0000 Subject: [issue19977] Use "surrogateescape" error handler for sys.stdin and sys.stdout on UNIX for the C locale In-Reply-To: <1386952820.2.0.77364136667.issue19977@psf.upfronthosting.co.za> Message-ID: <1398622398.84.0.584402252891.issue19977@psf.upfronthosting.co.za> Nick Coghlan added the comment: Additional environments where the system misreports the encoding to use (courtesy of Armin Ronacher & Graham Dumpleton on Twitter): upstart, Salt, mod_wsgi. Note that for more complex applications (e.g. integrated web UIs, socket servers, sending email), round tripping to the standard streams won't be enough - what we really need is a better "source of truth" as to the real system encoding when POSIX compliant systems provide incorrect configuration data to the interpreter. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 20:14:46 2014 From: report at bugs.python.org (Stefan Krah) Date: Sun, 27 Apr 2014 18:14:46 +0000 Subject: [issue1820] Enhance Object/structseq.c to match namedtuple and tuple api In-Reply-To: <1200284428.58.0.762384814897.issue1820@psf.upfronthosting.co.za> Message-ID: <1398622486.11.0.0324228780965.issue1820@psf.upfronthosting.co.za> Stefan Krah added the comment: >> 1. _asdict() returns a normal dictionary. I don't know if this is what >> is required. Good question. I don't think we can import OrderedDict from collections because of the impact on startup time (_collections_abc was created to avoid the issue for MutableMapping). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 20:27:31 2014 From: report at bugs.python.org (Nathaniel Smith) Date: Sun, 27 Apr 2014 18:27:31 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1398623251.49.0.459241305179.issue21233@psf.upfronthosting.co.za> Nathaniel Smith added the comment: Right, python3 -c 'b"x" * (2 ** 48)' does give an instant MemoryError for me. So I was wrong about it being the VM limit indeed. The documentation on this is terrible! But, if I'm reading this right: http://lxr.free-electrons.com/source/mm/util.c#L434 the actual rules are: overcommit mode 1: allocating a VM range always succeeds. overcommit mode 2: (Slightly simplified) You can allocate total VM ranges up to (swap + RAM * overcommit_ratio), and overcommit_ratio is 50% by default. So that's a bit odd, but whatever. This is still entirely a limit on VM size. overcommit mode 0 ("guess", the default): when allocating a VM range, the kernel imagines what would happen if you immediately used all those pages. If that would put you OOM, then we fall back to mode 2 rules. If that would *not* put you OOM, then the allocation unconditionally succeeds. So yeah, touching pages can affect whether a later malloc returns ENOMEM. I'm not sure any of this actually matters in the Python case though :-). There's still no reason to go touching pages pre-emptively just in case we might write to them later -- all that does is increase the interpreter's memory footprint, which can't help anything. If people are worried about overcommit, then they should turn off overcommit, not try and disable it on a piece-by-piece basis by trying to get individual programs to memory before they need it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 20:31:50 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 27 Apr 2014 18:31:50 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: Message-ID: Charles-Fran?ois Natali added the comment: Alright, it bothered me so I wrote a small C testcase (attached), which calls malloc in a loop, and can call memset upon the allocated block right after allocation: $ gcc -o /tmp/test /tmp/test.c; /tmp/test malloc() returned NULL after 3050MB $ gcc -DDO_MEMSET -o /tmp/test /tmp/test.c; /tmp/test malloc() returned NULL after 2130MB Without memset, the kernel happily allocates until we reach the 3GB user address space limit. With memset, it bails out way before. I don't know what this'll give on 64-bit, but I assume one should get comparable result. I would guess that the reason why the Python list allocation fails is because of the exponential allocation scheme: since memory is allocated in large chunks before being used, the kernel happily overallocates. With a more progressive allocation+usage, it should return ENOMEM at some point. Anyway, that's probably off-topic! ---------- Added file: http://bugs.python.org/file35059/test.c _______________________________________ Python tracker _______________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: test.c Type: text/x-csrc Size: 412 bytes Desc: not available URL: From report at bugs.python.org Sun Apr 27 20:36:51 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 27 Apr 2014 18:36:51 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1398623251.49.0.459241305179.issue21233@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > So yeah, touching pages can affect whether a later malloc returns ENOMEM. > > I'm not sure any of this actually matters in the Python case though :-). There's still no reason to go touching pages pre-emptively just in case we might write to them later -- all that does is increase the interpreter's memory footprint, which can't help anything. If people are worried about overcommit, then they should turn off overcommit, not try and disable it on a piece-by-piece basis by trying to get individual programs to memory before they need it. Absolutely: that's why I'm really in favor of exposing calloc, this could definitely help many workloads. Victor, did you run any non-trivial benchmark, like pybench & Co? As I said, I'm not expecting any improvement, I just want to make sure there's not hidden regression somewhere (like the one for GC-tracked objects above). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 20:37:28 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 27 Apr 2014 18:37:28 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: Message-ID: <1398623846.2380.4.camel@fsol> Antoine Pitrou added the comment: > $ gcc -o /tmp/test /tmp/test.c; /tmp/test > malloc() returned NULL after 3050MB > $ gcc -DDO_MEMSET -o /tmp/test /tmp/test.c; /tmp/test > malloc() returned NULL after 2130MB > > Without memset, the kernel happily allocates until we reach the 3GB > user address space limit. > With memset, it bails out way before. > > I don't know what this'll give on 64-bit, but I assume one should get > comparable result. Both OOM here (3.11.0-20-generic, 64-bit, Ubuntu). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 20:49:35 2014 From: report at bugs.python.org (Stefan Krah) Date: Sun, 27 Apr 2014 18:49:35 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1398624575.49.0.831297327796.issue21233@psf.upfronthosting.co.za> Stefan Krah added the comment: This is probably offtopic, but I think people who want reliable MemoryErrors can use limits, e.g. via djb's softlimit (daemontools): $ softlimit -m 100000000 ./python Python 3.5.0a0 (default:462470859e57+, Apr 27 2014, 19:34:06) [GCC 4.7.2] on linux Type "help", "copyright", "credits" or "license" for more information. >>> [i for i in range(9999999)] Traceback (most recent call last): File "", line 1, in File "", line 1, in MemoryError ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 21:03:45 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 27 Apr 2014 19:03:45 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1398623846.2380.4.camel@fsol> Message-ID: Charles-Fran?ois Natali added the comment: > Both OOM here (3.11.0-20-generic, 64-bit, Ubuntu). Hm... What's /proc/sys/vm/overcommit_memory ? If it's set to 0, then the kernel will always overcommit. If you set it to 2, normally you'd definitely get ENOMEM (which is IMO much nicer than getting nuked by the OOM killer, especially because, like in real life, there's often collateral damage ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 21:07:37 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 27 Apr 2014 19:07:37 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: Message-ID: Charles-Fran?ois Natali added the comment: > Hm... > What's /proc/sys/vm/overcommit_memory ? > If it's set to 0, then the kernel will always overcommit. I meant 1 (damn, I need sleep). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 21:09:37 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 27 Apr 2014 19:09:37 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: Message-ID: <1398625775.2380.6.camel@fsol> Antoine Pitrou added the comment: > Hm... > What's /proc/sys/vm/overcommit_memory ? > If it's set to 0, then the kernel will always overcommit. Ah, indeed. > If you set it to 2, normally you'd definitely get ENOMEM You're right, but with weird results: $ gcc -o /tmp/test test.c; /tmp/test malloc() returned NULL after 600MB $ gcc -DDO_MEMSET -o /tmp/test test.c; /tmp/test malloc() returned NULL after 600MB (I'm supposed to have gigabytes free?!) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 21:15:06 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 27 Apr 2014 19:15:06 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1398625775.2380.6.camel@fsol> Message-ID: Charles-Fran?ois Natali added the comment: >> Hm... >> What's /proc/sys/vm/overcommit_memory ? >> If it's set to 0, then the kernel will always overcommit. > > Ah, indeed. See above, I mistyped: 0 is the default (which is already quite optimistic), 1 is always. >> If you set it to 2, normally you'd definitely get ENOMEM > > You're right, but with weird results: > > $ gcc -o /tmp/test test.c; /tmp/test > malloc() returned NULL after 600MB > $ gcc -DDO_MEMSET -o /tmp/test test.c; /tmp/test > malloc() returned NULL after 600MB > > (I'm supposed to have gigabytes free?!) The formula is RAM * vm.overcommit_ratio /100 + swap So if you don't have swap, or a low overcommit_ratio, it could explain why it returns so early. Or maybe you have some processes with a lot of mapped-yet-unused memory (chromium is one of those for example). Anyway, it's really a mess! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 21:24:21 2014 From: report at bugs.python.org (=?utf-8?q?Kim_Gr=C3=A4sman?=) Date: Sun, 27 Apr 2014 19:24:21 +0000 Subject: [issue18314] Have os.unlink remove junction points In-Reply-To: <1372335321.1.0.479247042071.issue18314@psf.upfronthosting.co.za> Message-ID: <1398626661.64.0.871060547162.issue18314@psf.upfronthosting.co.za> Kim Gr?sman added the comment: Thanks for pushing this forward! Do you have links to the failing bots I could take a look at? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 21:27:19 2014 From: report at bugs.python.org (Tim Golden) Date: Sun, 27 Apr 2014 19:27:19 +0000 Subject: [issue18314] Have os.unlink remove junction points In-Reply-To: <1398626661.64.0.871060547162.issue18314@psf.upfronthosting.co.za> Message-ID: <535D5A15.1040906@timgolden.me.uk> Tim Golden added the comment: Here are a couple: http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/4423 http://buildbot.python.org/all/builders/x86%20Windows7%203.x/builds/8288 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 21:30:25 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 27 Apr 2014 19:30:25 +0000 Subject: [issue21368] Check for systemd locale on startup if current locale is set to POSIX Message-ID: <1398627025.84.0.804520187603.issue21368@psf.upfronthosting.co.za> New submission from Nick Coghlan: Issue 19977 added "surrogateescape" to the fallback settings for the standard streams if Python 3 appears to be running under the POSIX locale (which Python 3 currently reads as setting a default encoding of ASCII, which is almost certainly wrong on any modern Linux system). If a modern Linux system is using systemd as the process manager, then there will likely be a "/etc/locale.conf" file providing settings like LANG - due to problematic requirements in the POSIX specification, this file (when available) is likely to be a better "source of truth" regarding the system encoding than the environment where the interpreter process is started, at least when the latter is claiming ASCII as the default encoding. See http://www.freedesktop.org/software/systemd/man/locale.conf.html for more details. ---------- components: Interpreter Core messages: 217313 nosy: ncoghlan priority: normal severity: normal status: open title: Check for systemd locale on startup if current locale is set to POSIX versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 21:30:49 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 27 Apr 2014 19:30:49 +0000 Subject: [issue21362] concurrent.futures does not validate that max_workers is proper In-Reply-To: <1398598769.27.0.217084820664.issue21362@psf.upfronthosting.co.za> Message-ID: <1398627049.32.0.840532508476.issue21362@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 21:34:06 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 27 Apr 2014 19:34:06 +0000 Subject: [issue19977] Use "surrogateescape" error handler for sys.stdin and sys.stdout on UNIX for the C locale In-Reply-To: <1386952820.2.0.77364136667.issue19977@psf.upfronthosting.co.za> Message-ID: <1398627246.0.0.0432461705881.issue19977@psf.upfronthosting.co.za> Nick Coghlan added the comment: Issue 21368 now suggests looking for /etc/locale.conf before falling back to ASCII+surrogateescape. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 21:48:32 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 27 Apr 2014 19:48:32 +0000 Subject: [issue19977] Use "surrogateescape" error handler for sys.stdin and sys.stdout on UNIX for the C locale In-Reply-To: <1386952820.2.0.77364136667.issue19977@psf.upfronthosting.co.za> Message-ID: <1398628112.48.0.734847360563.issue19977@psf.upfronthosting.co.za> Antoine Pitrou added the comment: We should not overcomplicate this. I suggest that we simply use utf-8 under the C locale. ---------- versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 22:43:06 2014 From: report at bugs.python.org (Jessica McKellar) Date: Sun, 27 Apr 2014 20:43:06 +0000 Subject: [issue13330] Attempt full test coverage of LocaleTextCalendar.formatweekday In-Reply-To: <1320300850.58.0.556745870791.issue13330@psf.upfronthosting.co.za> Message-ID: <1398631386.38.0.481423131331.issue13330@psf.upfronthosting.co.za> Jessica McKellar added the comment: Thanks for working to increase our test coverage, Sean.Fleming! Looking at the current coverage, the there is one line in LocaleTextCalendar.formatweekday without coverage: http://hg.python.org/cpython/file/e159cb0d955b/Lib/calendar.py#l519. You add some additional tests, but they are mostly testing some very literal aspects of the implementation rather than the purpose of the function. For example: + self.assertRaises(IndexError, calendar.LocaleTextCalendar(locale='').formatweekday, 7, 1 ) It's true that this will raise an IndexError, but formatweekday isn't supposed to be called with these values. I've added some tests that add coverage for the line that didn't have coverage, while focusing on the purpose of the function, namely to provide an appropriate day name when constrained to various widths. * The patch passes the full test suite * The patch passes `make patchcheck` * The patch results in full coverage for LocaleTextCalendar.formatweekday Coverage results, before and after: $ ./python.exe ../coveragepy/ run --pylib --source=calendar Lib/test/regrtest.py test_calendar [1/1] test_calendar 1 test OK. nitefly:cpython jesstess$ ./python.exe ../coveragepy/ report --show-missing Name Stmts Miss Cover Missing -------------------------------------------- Lib/calendar 375 54 86% 511, 519, 541, 608-699, 703 $ patch -p1 < issue13330.patch patching file Lib/test/test_calendar.py patching file Misc/ACKS $ ./python.exe ../coveragepy/ run --pylib --source=calendar Lib/test/regrtest.py test_calendar [1/1] test_calendar 1 test OK. nitefly:cpython jesstess$ ./python.exe ../coveragepy/ report --show-missing Name Stmts Miss Cover Missing -------------------------------------------- Lib/calendar 375 53 86% 511, 541, 608-699, 703 (519 was the one line without coverage inside LocaleTextCalendar.formatweekday) ---------- nosy: +jesstess versions: +Python 3.5 -Python 3.3 Added file: http://bugs.python.org/file35060/issue13330.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 22:47:39 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 27 Apr 2014 20:47:39 +0000 Subject: [issue19977] Use "surrogateescape" error handler for sys.stdin and sys.stdout on UNIX for the C locale In-Reply-To: <1398628112.48.0.734847360563.issue19977@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: If you can convince Stephen Turnbull that's a good idea, sure. It's probably more likely to be the right thing than "ASCII" or "ASCII + surrogateescape", but in the absence of hard data, he's in a better position than we are to judge the likely impact of that, at least in Japan. I'm also going to hunt around on freedesktop.org to see if there's anything more general there on the topic of encodings. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 27 23:04:38 2014 From: report at bugs.python.org (=?utf-8?q?Kim_Gr=C3=A4sman?=) Date: Sun, 27 Apr 2014 21:04:38 +0000 Subject: [issue18314] Have os.unlink remove junction points In-Reply-To: <1372335321.1.0.479247042071.issue18314@psf.upfronthosting.co.za> Message-ID: <1398632678.3.0.286799345311.issue18314@psf.upfronthosting.co.za> Kim Gr?sman added the comment: Thanks! At first I suspected 32 vs 64 bit, but the failing bots cover both... One thing that stands out to me as risky is the memcmp() against "\\??\\", which could overrun a short src_path buffer. But I don't think that would fail here. I must have made some mistake with the REPARSE_DATA_BUFFER, but I can't see anything off hand. What are our debugging options? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 00:14:42 2014 From: report at bugs.python.org (Kathleen Weaver) Date: Sun, 27 Apr 2014 22:14:42 +0000 Subject: [issue20265] Bring Windows docs up to date In-Reply-To: <1389757265.26.0.116885263001.issue20265@psf.upfronthosting.co.za> Message-ID: <1398636882.55.0.971055674706.issue20265@psf.upfronthosting.co.za> Kathleen Weaver added the comment: Latest update ---------- Added file: http://bugs.python.org/file35061/mywork.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 00:26:05 2014 From: report at bugs.python.org (Sworddragon) Date: Sun, 27 Apr 2014 22:26:05 +0000 Subject: [issue21369] Extended modes for tarfile.TarFile() Message-ID: <1398637565.27.0.953592639835.issue21369@psf.upfronthosting.co.za> New submission from Sworddragon: tarfile.open() does support optionally an compression method on the mode argument in the form of 'filemode[:compression]' but tarfile.TarFile() does only suport 'a', 'r' and 'w'. Is there a special reason that tarfile.TarFile() doesn't directly support an optional compression method? Otherwise it would be nice if they could be used directly on tarfile.TarFile() too. ---------- components: Library (Lib) messages: 217320 nosy: Sworddragon priority: normal severity: normal status: open title: Extended modes for tarfile.TarFile() type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 00:37:53 2014 From: report at bugs.python.org (John Rusnak) Date: Sun, 27 Apr 2014 22:37:53 +0000 Subject: [issue21370] segfault from simple traceback.format_exc call Message-ID: <1398638273.35.0.105572602615.issue21370@psf.upfronthosting.co.za> New submission from John Rusnak: Launch python3.3 and then >>> import traceback >>> tracebacke.format_exc() Seomteims a long trace about missing attribute is produced, on subequent of sometimes first call, python executable segfaults. I see this behavior in an app as well then calling format_exc() under a real exception condition. ---------- messages: 217321 nosy: John.Rusnak priority: normal severity: normal status: open title: segfault from simple traceback.format_exc call versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 00:40:54 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Sun, 27 Apr 2014 22:40:54 +0000 Subject: [issue20951] SSLSocket.send() returns 0 for non-blocking socket In-Reply-To: <1395004591.32.0.211111410214.issue20951@psf.upfronthosting.co.za> Message-ID: <1398638454.29.0.823497535776.issue20951@psf.upfronthosting.co.za> Nikolaus Rath added the comment: As discussed on python-dev, here is a patch that changes the behavior of send() and sendall() to raise SSLWant* exceptions instead of returning zero. ---------- Added file: http://bugs.python.org/file35062/issue20951_r2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 01:03:31 2014 From: report at bugs.python.org (STINNER Victor) Date: Sun, 27 Apr 2014 23:03:31 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1398639811.45.0.600702417766.issue21233@psf.upfronthosting.co.za> STINNER Victor added the comment: I splitted my patch into two parts: - calloc-4.patch: add new "Calloc" functions including _PyObject_GC_Calloc() - use_calloc.patch: patch types (bytes, dict, list, set, tuple, etc.) and various modules to use calloc I reverted my changes on _PyObject_GC_Malloc() and added _PyObject_GC_Calloc(), performance regressions are gone. Creating a large tuple is a little bit (8%) faster. But the real speedup is to build a large bytes strings of null bytes: $ ./python.orig -m timeit 'bytes(50*1024*1024)' 100 loops, best of 3: 5.7 msec per loop $ ./python.calloc -m timeit 'bytes(50*1024*1024)' 100000 loops, best of 3: 4.12 usec per loop On Linux, no memory is allocated, even if you read the bytes content. RSS is almost unchanged. Ok, now the real use case where it becomes faster: I implemented the same optimization for bytearray. $ ./python.orig -m timeit 'bytearray(50*1024*1024)' 100 loops, best of 3: 6.33 msec per loop $ ./python.calloc -m timeit 'bytearray(50*1024*1024)' 100000 loops, best of 3: 4.09 usec per loop If you overallocate a bytearray and only write a few bytes, the bytes of end of bytearray will not be allocated (at least on Linux). Result of bench_alloc.py comparing original Python to patched Python (calloc-4.patch + use_calloc.patch). Common platform: SCM: hg revision=4b97092aa4bd+ tag=tip branch=default date="2014-04-27 18:02 +0100" Timer info: namespace(adjustable=False, implementation='clock_gettime(CLOCK_MONOTONIC)', monotonic=True, resolution=1e-09) Python unicode implementation: PEP 393 CFLAGS: -Wno-unused-result -Werror=declaration-after-statement -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes Bits: int=32, long=64, long long=64, size_t=64, void*=64 Timer: time.perf_counter CPU model: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz Platform: Linux-3.13.9-200.fc20.x86_64-x86_64-with-fedora-20-Heisenbug Platform of campaign orig: Timer precision: 42 ns Date: 2014-04-28 00:27:19 Python version: 3.5.0a0 (default:4b97092aa4bd, Apr 28 2014, 00:24:03) [GCC 4.8.2 20131212 (Red Hat 4.8.2-7)] Platform of campaign calloc: Timer precision: 54 ns Date: 2014-04-28 00:28:35 Python version: 3.5.0a0 (default:4b97092aa4bd+, Apr 28 2014, 00:25:56) [GCC 4.8.2 20131212 (Red Hat 4.8.2-7)] -----------------------------------+-------------+-------------- Tests????????????????????????????? | ???????orig | ???????calloc -----------------------------------+-------------+-------------- object()?????????????????????????? | ??61 ns (*) | ?71 ns (+16%) b'A' * 10????????????????????????? | ??54 ns (*) | ????????52 ns b'A' * 10**3?????????????????????? | ?124 ns (*) | 110 ns (-12%) b'A' * 10**6?????????????????????? | 38.4 us (*) | ??????38.5 us 'A' * 10?????????????????????????? | ??59 ns (*) | ????????62 ns 'A' * 10**3??????????????????????? | ?132 ns (*) | 107 ns (-19%) 'A' * 10**6??????????????????????? | 38.5 us (*) | ??????38.5 us 'A' * 10**8??????????????????????? | 10.3 ms (*) | ??????10.6 ms decode 10 null bytes from ASCII??? | ?264 ns (*) | ???????263 ns decode 10**3 null bytes from ASCII | ?403 ns (*) | ?379 ns (-6%) decode 10**6 null bytes from ASCII | 80.5 us (*) | ??????80.5 us decode 10**8 null bytes from ASCII | 17.7 ms (*) | ??????17.3 ms (None,) * 10**0??????????????????? | ??29 ns (*) | ????????28 ns (None,) * 10**1??????????????????? | ??75 ns (*) | ????????76 ns (None,) * 10**2??????????????????? | ?461 ns (*) | ???????460 ns (None,) * 10**3??????????????????? | ?3.6 us (*) | ??????3.57 us (None,) * 10**4??????????????????? | 35.7 us (*) | ??????35.7 us (None,) * 10**5??????????????????? | ?364 us (*) | ???????365 us (None,) * 10**6??????????????????? | 4.12 ms (*) | ??????4.11 ms (None,) * 10**7??????????????????? | 43.5 ms (*) | 40.3 ms (-7%) (None,) * 10**8??????????????????? | ?433 ms (*) | ?400 ms (-8%) ([None] * 10)[1:-1]??????????????? | ?121 ns (*) | 134 ns (+11%) ([None] * 10**3)[1:-1]???????????? | 3.62 us (*) | ??????3.61 us ([None] * 10**6)[1:-1]???????????? | 4.24 ms (*) | ??????4.22 ms ([None] * 10**8)[1:-1]???????????? | ?440 ms (*) | ?402 ms (-9%) -----------------------------------+-------------+-------------- Total????????????????????????????? | ?954 ms (*) | ?880 ms (-8%) -----------------------------------+-------------+-------------- ---------- Added file: http://bugs.python.org/file35063/calloc-4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 01:03:40 2014 From: report at bugs.python.org (STINNER Victor) Date: Sun, 27 Apr 2014 23:03:40 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1398639820.67.0.721500931314.issue21233@psf.upfronthosting.co.za> Changes by STINNER Victor : Added file: http://bugs.python.org/file35064/use_calloc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 01:15:48 2014 From: report at bugs.python.org (STINNER Victor) Date: Sun, 27 Apr 2014 23:15:48 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1398640548.12.0.00484967905945.issue21233@psf.upfronthosting.co.za> STINNER Victor added the comment: bench_alloc2.py: updated benchmark script. I added bytes(n) and bytearray(n) tests and removed the test decoding from ASCII. Common platform: Timer: time.perf_counter Timer info: namespace(adjustable=False, implementation='clock_gettime(CLOCK_MONOTONIC)', monotonic=True, resolution=1e-09) Platform: Linux-3.13.9-200.fc20.x86_64-x86_64-with-fedora-20-Heisenbug SCM: hg revision=4b97092aa4bd+ tag=tip branch=default date="2014-04-27 18:02 +0100" Python unicode implementation: PEP 393 Bits: int=32, long=64, long long=64, size_t=64, void*=64 CFLAGS: -Wno-unused-result -Werror=declaration-after-statement -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes CPU model: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz Platform of campaign orig: Date: 2014-04-28 01:11:49 Timer precision: 39 ns Python version: 3.5.0a0 (default:4b97092aa4bd, Apr 28 2014, 01:02:01) [GCC 4.8.2 20131212 (Red Hat 4.8.2-7)] Platform of campaign calloc: Date: 2014-04-28 01:12:29 Timer precision: 44 ns Python version: 3.5.0a0 (default:4b97092aa4bd+, Apr 28 2014, 01:06:54) [GCC 4.8.2 20131212 (Red Hat 4.8.2-7)] -----------------------+-------------+---------------- Tests????????????????? | ???????orig | ?????????calloc -----------------------+-------------+---------------- object()?????????????? | ??62 ns (*) | ???72 ns (+16%) b'A' * 10????????????? | ??53 ns (*) | ??????????52 ns b'A' * 10**3?????????? | ??96 ns (*) | ??110 ns (+15%) b'A' * 10**6?????????? | 38.5 us (*) | ????????38.6 us 'A' * 10?????????????? | ??59 ns (*) | ??????????61 ns 'A' * 10**3??????????? | ?105 ns (*) | ?????????108 ns 'A' * 10**6??????????? | 38.6 us (*) | ????????38.6 us 'A' * 10**8??????????? | 10.3 ms (*) | ????????10.4 ms (None,) * 10**0??????? | ??29 ns (*) | ??????????29 ns (None,) * 10**1??????? | ??75 ns (*) | ??????????76 ns (None,) * 10**2??????? | ?432 ns (*) | ???461 ns (+7%) (None,) * 10**3??????? | 3.58 us (*) | ?????????3.6 us (None,) * 10**4??????? | 35.8 us (*) | ????????35.7 us (None,) * 10**5??????? | ?365 us (*) | ?????????365 us (None,) * 10**6??????? | ?4.1 ms (*) | ????????4.13 ms (None,) * 10**7??????? | 43.6 ms (*) | ??40.3 ms (-8%) (None,) * 10**8??????? | ?433 ms (*) | ???401 ms (-7%) ([None] * 10)[1:-1]??? | ?122 ns (*) | ??134 ns (+10%) ([None] * 10**3)[1:-1] | ?3.6 us (*) | ????????3.62 us ([None] * 10**6)[1:-1] | 4.22 ms (*) | ?????????4.2 ms ([None] * 10**8)[1:-1] | ?441 ms (*) | ???402 ms (-9%) bytes(10)????????????? | ?137 ns (*) | ?????????136 ns bytes(10**3)?????????? | ?181 ns (*) | ???191 ns (+5%) bytes(10**6)?????????? | 38.7 us (*) | ????????39.2 us bytes(10**8)?????????? | 10.3 ms (*) | 4.36 us (-100%) bytearray(10)????????? | ?138 ns (*) | ??153 ns (+11%) bytearray(10**3)?????? | ?184 ns (*) | ??211 ns (+14%) bytearray(10**6)?????? | 38.7 us (*) | ????????39.3 us bytearray(10**8)?????? | 10.3 ms (*) | 4.32 us (-100%) -----------------------+-------------+---------------- Total????????????????? | ?957 ms (*) | ??862 ms (-10%) -----------------------+-------------+---------------- ---------- Added file: http://bugs.python.org/file35065/bench_alloc2.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 01:16:51 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 27 Apr 2014 23:16:51 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1398640548.12.0.00484967905945.issue21233@psf.upfronthosting.co.za> Message-ID: <1398640609.2380.7.camel@fsol> Antoine Pitrou added the comment: > Common platform: > Timer: time.perf_counter > Timer info: namespace(adjustable=False, implementation='clock_gettime(CLOCK_MONOTONIC)', monotonic=True, resolution=1e-09) > Platform: Linux-3.13.9-200.fc20.x86_64-x86_64-with-fedora-20-Heisenbug ^^^^^^^^^ Are you sure this is a good platform for performance reports? :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 01:20:04 2014 From: report at bugs.python.org (STINNER Victor) Date: Sun, 27 Apr 2014 23:20:04 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1398640804.8.0.879395405799.issue21233@psf.upfronthosting.co.za> STINNER Victor added the comment: > Are you sure this is a good platform for performance reports? :) Don't hesitate to rerun my benchmark on more different platforms? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 01:22:50 2014 From: report at bugs.python.org (STINNER Victor) Date: Sun, 27 Apr 2014 23:22:50 +0000 Subject: [issue21340] Possible concurrency bug in asyncio, AttributeError in tasks.py In-Reply-To: <3gGxQv4T2rz7LpS@mail.python.org> Message-ID: STINNER Victor added the comment: Why not using try/except AttributeError? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 01:26:39 2014 From: report at bugs.python.org (STINNER Victor) Date: Sun, 27 Apr 2014 23:26:39 +0000 Subject: [issue21368] Check for systemd locale on startup if current locale is set to POSIX In-Reply-To: <1398627025.84.0.804520187603.issue21368@psf.upfronthosting.co.za> Message-ID: <1398641199.17.0.807221210645.issue21368@psf.upfronthosting.co.za> STINNER Victor added the comment: I don't think that Python should read such configuration file. If you consider that something is wrong here, please report the issue to the C library. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 01:33:57 2014 From: report at bugs.python.org (STINNER Victor) Date: Sun, 27 Apr 2014 23:33:57 +0000 Subject: [issue19977] Use "surrogateescape" error handler for sys.stdin and sys.stdout on UNIX for the C locale In-Reply-To: Message-ID: STINNER Victor added the comment: > We should not overcomplicate this. I suggest that we simply use utf-8 under the C locale. Do you mean utf8/strict or utf8/surrogateescape? utf8/strict doesn't work (os.listdir raises an unicode error) if your system is configured to use latin1 (ex: filenames are stored in this encoding), but unfortunately your program is running in an empty environment (so will use the POSIX locale). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 01:34:41 2014 From: report at bugs.python.org (STINNER Victor) Date: Sun, 27 Apr 2014 23:34:41 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1398641681.6.0.682108822384.issue21233@psf.upfronthosting.co.za> STINNER Victor added the comment: > Don't hesitate to rerun my benchmark on more different platforms? Oops, I wanted to write ";-)" not "?". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 01:35:24 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 27 Apr 2014 23:35:24 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1398641724.09.0.972408836585.issue21233@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Ok, now the real use case where it becomes faster: I implemented the > same optimization for bytearray. The real use case I envision is with huge powers of two. If I write: x = 2 ** 1000000 then all of x's bytes except the highest one will be zeros. If we map those to /dev/zero, it will be a massive saving for programs using huge powers of two. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 01:57:39 2014 From: report at bugs.python.org (STINNER Victor) Date: Sun, 27 Apr 2014 23:57:39 +0000 Subject: [issue19977] Use "surrogateescape" error handler for sys.stdin and sys.stdout on UNIX for the C locale In-Reply-To: <1386952820.2.0.77364136667.issue19977@psf.upfronthosting.co.za> Message-ID: <1398643059.92.0.0558590506668.issue19977@psf.upfronthosting.co.za> STINNER Victor added the comment: > We should not overcomplicate this. I suggest that we simply use utf-8 under the C locale. Please open a new issue if you would prefer UTF-8. You will have to solve different technical issues. I tried to list some of them in issues #19846 and #19847. In short, you should always decode and encode "OS data" with the same encoding. Python "file system encoding" is the locale encoding because in some places, PyUnicode_DecodeLocale[AndSize]() is used (ex: to decode PYTHONWARNINGS environment variable). A common location is PyUnicode_DecodeFSDefaultAndSize() before the Python codec is loaded. See also _Py_wchar2char() and _Py_char2wchar() functions which use the locale encoding and are used in many places. I'm now closing the issue because the initial point (use surrogateescape error handler) is implemented in Python 3.5, and backporting such major change in Python 3.4 branch is risky right now. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 02:09:33 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 28 Apr 2014 00:09:33 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1398643773.38.0.494546096476.issue21233@psf.upfronthosting.co.za> STINNER Victor added the comment: > The real use case I envision is with huge powers of two. I'm not sure that it's a common use case, but it can be nice to optimize this case if it doesn't make longobject.c more complex. It looks like calloc() becomes interesting for objects larger than 1 MB. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 02:15:49 2014 From: report at bugs.python.org (Ned Deily) Date: Mon, 28 Apr 2014 00:15:49 +0000 Subject: [issue5001] Remove assertion-based checking in multiprocessing In-Reply-To: <1232382762.58.0.610641171059.issue5001@psf.upfronthosting.co.za> Message-ID: <1398644149.63.0.238890415145.issue5001@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +sbt versions: +Python 3.4, Python 3.5 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 02:18:08 2014 From: report at bugs.python.org (Ned Deily) Date: Mon, 28 Apr 2014 00:18:08 +0000 Subject: [issue21369] Extended modes for tarfile.TarFile() In-Reply-To: <1398637565.27.0.953592639835.issue21369@psf.upfronthosting.co.za> Message-ID: <1398644288.76.0.0285980268697.issue21369@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +lars.gustaebel _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 02:28:24 2014 From: report at bugs.python.org (Berker Peksag) Date: Mon, 28 Apr 2014 00:28:24 +0000 Subject: [issue21369] Extended modes for tarfile.TarFile() In-Reply-To: <1398637565.27.0.953592639835.issue21369@psf.upfronthosting.co.za> Message-ID: <1398644904.12.0.430556998668.issue21369@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 03:38:29 2014 From: report at bugs.python.org (Elizabeth Myers) Date: Mon, 28 Apr 2014 01:38:29 +0000 Subject: [issue21031] [patch] Add AlpineLinux to the platform module's supported distributions list In-Reply-To: <1395547536.87.0.0316178193706.issue21031@psf.upfronthosting.co.za> Message-ID: <1398649109.12.0.662750987061.issue21031@psf.upfronthosting.co.za> Elizabeth Myers added the comment: Any information or updates? :) ---------- status: open -> languishing _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 04:02:39 2014 From: report at bugs.python.org (Li Zhenhua) Date: Mon, 28 Apr 2014 02:02:39 +0000 Subject: [issue21371] struct lconv does not have decimal_point on android platform Message-ID: <1398650559.39.0.586667315036.issue21371@psf.upfronthosting.co.za> New submission from Li Zhenhua: When compile python for android, it gets error because struct lconv does not have a member "decimal_point". ---------- components: Cross-Build files: lconv_member.patch keywords: patch messages: 217335 nosy: lizhenhua priority: normal severity: normal status: open title: struct lconv does not have decimal_point on android platform type: compile error versions: Python 3.5 Added file: http://bugs.python.org/file35066/lconv_member.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 04:03:47 2014 From: report at bugs.python.org (Ian Cordasco) Date: Mon, 28 Apr 2014 02:03:47 +0000 Subject: [issue10510] distutils upload/register should use CRLF in HTTP requests In-Reply-To: <1290489114.33.0.672814735109.issue10510@psf.upfronthosting.co.za> Message-ID: <1398650627.04.0.643392280657.issue10510@psf.upfronthosting.co.za> Ian Cordasco added the comment: I've attached a patch that should fix this issue. Please review and let me know if changes are necessary. ---------- keywords: +patch Added file: http://bugs.python.org/file35067/compliant_distutils.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 04:17:25 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 28 Apr 2014 02:17:25 +0000 Subject: [issue1820] Enhance Object/structseq.c to match namedtuple and tuple api In-Reply-To: <1200284428.58.0.762384814897.issue1820@psf.upfronthosting.co.za> Message-ID: <1398651445.05.0.578282142366.issue1820@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > any chance of the easy (_fields) change being committed > and putting off the harder parts until later? Yes, it is not an all-or-nothing exercise. >> 1. _asdict() returns a normal dictionary. I don't know if this is what >> is required. A regular dict would work just fine for now (there is a patch to introduce an OrderedDict in C, but that transition could be done later. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 05:36:15 2014 From: report at bugs.python.org (Jessica McKellar) Date: Mon, 28 Apr 2014 03:36:15 +0000 Subject: [issue13204] sys.flags.__new__ crashes In-Reply-To: <1318889665.83.0.350090316357.issue13204@psf.upfronthosting.co.za> Message-ID: <1398656175.44.0.8804877825.issue13204@psf.upfronthosting.co.za> Jessica McKellar added the comment: Thanks for reporting this and providing a patch, Trundle. The Python 3 patch didn't apply cleanly anymore, so I regenerated it and added tests for sys.version_info and sys.getwindowsversion. * The patch passes `make patchcheck` * The full test suite passes with this patch. * Testing manually, without this patch each of the following segfaults, and with the patch they raise errors instead: import sys; sys.flags.__new__(type(sys.flags)) import sys; sys.version_info.__new__(type(sys.version_info)) import sys; sys.getwindowsversion().__new__(type(sys.getwindowsversion())) One important caveat is that while I confirmed the sys.getwindowsversion segfault on Windows, I don't have Visual Studio set up so I couldn't build and test the new test for sys.getwindowsversion (I ran the full test suite on OSX, where this test is skipped). ---------- keywords: +needs review nosy: +jesstess versions: +Python 3.5 -Python 3.2, Python 3.3 Added file: http://bugs.python.org/file35068/issue13204.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 05:42:48 2014 From: report at bugs.python.org (Antoine Pietri) Date: Mon, 28 Apr 2014 03:42:48 +0000 Subject: [issue19776] Provide expanduser() on Path objects In-Reply-To: <1385409778.55.0.842571848249.issue19776@psf.upfronthosting.co.za> Message-ID: <1398656568.18.0.433771805025.issue19776@psf.upfronthosting.co.za> Antoine Pietri added the comment: > I think that `absolute` method should call `expanduser` and `expandvars` (do you plan to include it?) automatically. This should be optional (via default arguments: `expanduser=True, expandvars=True`. I think it shouldn't. (Or shouldn't be set to True by default anyway). absolute() method resolves symlinks, and it would make no sense to expand tildes and vars, which are purely a "shell syntax". . and .. are real things in the filesystem, ~ is just a notation commonly used (since it's in the SCL spec), but it's not *part* of the path, that's why you can totally have a valid ~ file. Making absolute() expand tildes would be illogic, unintuitive and unpythonic. (+1 for the .expanduser() patch though, I went here after searching for this feature in the docs). ---------- nosy: +seirl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 06:03:26 2014 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 28 Apr 2014 04:03:26 +0000 Subject: [issue21340] Possible concurrency bug in asyncio, AttributeError in tasks.py In-Reply-To: <1398305622.34.0.507325141901.issue21340@psf.upfronthosting.co.za> Message-ID: <1398657806.5.0.888681450853.issue21340@psf.upfronthosting.co.za> Guido van Rossum added the comment: Sorry, should have let someone review it. I'm a bit out of practice. :-) But in this case I think three-arg getattr() is better; less code, less indentation, and the final question (is the frame not None?) must still be asked. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 06:03:29 2014 From: report at bugs.python.org (Jessica McKellar) Date: Mon, 28 Apr 2014 04:03:29 +0000 Subject: [issue13096] ctypes: segfault with large POINTER type names In-Reply-To: <1317700059.13.0.375039668353.issue13096@psf.upfronthosting.co.za> Message-ID: <1398657809.62.0.248634134193.issue13096@psf.upfronthosting.co.za> Jessica McKellar added the comment: Thanks for the report and patch, meador.inge. I'd prefer not to add more globals that are only used in one place, but doing so is consistent with the existing style of test_pointers.py, and there's plenty in this file that could be cleaned up in another ticket. * The patch passes `make patchcheck`. * The full test suite passes with this patch. * The reproducers in this issue segfault for me without this patch and do not segfault with this patch. lgtm! => commit review ---------- keywords: +needs review nosy: +jesstess stage: patch review -> commit review versions: +Python 3.5 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 07:42:46 2014 From: report at bugs.python.org (Carol Willing) Date: Mon, 28 Apr 2014 05:42:46 +0000 Subject: [issue21026] Document sitecustomize.py problems with pythonw In-Reply-To: <1395519186.07.0.912886400259.issue21026@psf.upfronthosting.co.za> Message-ID: <1398663766.12.0.407198208009.issue21026@psf.upfronthosting.co.za> Carol Willing added the comment: Updated documentation using Terry Reedy's suggested addition. ---------- nosy: +willingc Added file: http://bugs.python.org/file35069/issue21026.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 08:03:24 2014 From: report at bugs.python.org (Jessica McKellar) Date: Mon, 28 Apr 2014 06:03:24 +0000 Subject: [issue13583] sqlite3.Row doesn't support slice indexes In-Reply-To: <1323639948.36.0.717803065724.issue13583@psf.upfronthosting.co.za> Message-ID: <1398665004.47.0.520502906121.issue13583@psf.upfronthosting.co.za> Jessica McKellar added the comment: Thanks for the ticket and patch, xapple! I updated the patch to address the compiler warning and use assertEqual. While testing, I noticed that slicing with steps wasn't supported, so I expanded the sqlite3.Row slicing code to support steps, and added some additional tests. The slicing code in Modules/_sqlite/row.c:pysqlite_row_subscript is unfortunately pretty redundant with the slicing code in Objects/tupleobject.c. It'd be better to either be able to factor the code from both into a function (but I couldn't see how to do this without making it part of the public API), or have tuple, sqlite.Row, etc. implement a shared slicing interface. Perhaps we should defer that decision to a future ticket, though. Note that even after this patch, sqlite.Row instances don't support negative indices. * This patch passes `make patchcheck`. * The full test suite passes with this patch. * There are no build warnings related to the patch. ---------- keywords: +needs review nosy: +jesstess versions: +Python 3.5 -Python 3.3 Added file: http://bugs.python.org/file35070/issue13583.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 08:04:55 2014 From: report at bugs.python.org (Jessica McKellar) Date: Mon, 28 Apr 2014 06:04:55 +0000 Subject: [issue13583] sqlite3.Row doesn't support slice indexes In-Reply-To: <1323639948.36.0.717803065724.issue13583@psf.upfronthosting.co.za> Message-ID: <1398665095.52.0.162451319901.issue13583@psf.upfronthosting.co.za> Jessica McKellar added the comment: I've also uploaded a short script that sets up an in-memory sqlite database that fetches Rows, for easy manual testing. ---------- Added file: http://bugs.python.org/file35071/sqlite3_slicing_demo.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 08:34:40 2014 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Mon, 28 Apr 2014 06:34:40 +0000 Subject: [issue21369] Extended modes for tarfile.TarFile() In-Reply-To: <1398637565.27.0.953592639835.issue21369@psf.upfronthosting.co.za> Message-ID: <1398666880.96.0.373178227052.issue21369@psf.upfronthosting.co.za> Lars Gust?bel added the comment: That was a design decision. What would be the advantage of having the TarFile class offer the compression itself? ---------- assignee: -> lars.gustaebel _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 09:11:58 2014 From: report at bugs.python.org (Florent Xicluna) Date: Mon, 28 Apr 2014 07:11:58 +0000 Subject: [issue18472] Update PEP 8 to encourage modern conventions In-Reply-To: <1373973528.84.0.159091610788.issue18472@psf.upfronthosting.co.za> Message-ID: <1398669118.65.0.809374209186.issue18472@psf.upfronthosting.co.za> Changes by Florent Xicluna : ---------- nosy: +flox _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 09:51:02 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 28 Apr 2014 07:51:02 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1398671462.8.0.245261093031.issue21233@psf.upfronthosting.co.za> STINNER Victor added the comment: It looks like Windows supports also lazy initialization of memory pages initialized to zero. According to my microbenchmark on Linux and Windows, only bytes(n) and bytearray(n) are really faster with use_calloc.patch. Most changes of use_calloc.patch are maybe useless since all bytes are initilized to zero, but just after that they are replaced with new bytes. Results of bench_alloc2.py on Windows 7: original vs calloc-4.patch+use_calloc.patch: Common platform: Timer: time.perf_counter Python unicode implementation: PEP 393 Bits: int=32, long=32, long long=64, size_t=32, void*=32 Platform: Windows-7-6.1.7601-SP1 CFLAGS: None Timer info: namespace(adjustable=False, implementation='QueryPerformanceCounter( )', monotonic=True, resolution=1e-08) Platform of campaign orig: SCM: hg revision=4b97092aa4bd branch=default date="2014-04-27 18:02 +0100" Date: 2014-04-28 09:35:30 Python version: 3.5.0a0 (default, Apr 28 2014, 09:33:30) [MSC v.1600 32 bit (Int el)] Timer precision: 4.47 us Platform of campaign calloc: SCM: hg revision=4f0aaa8804c6 tag=tip branch=default date="2014-04-28 09:27 +020 0" Date: 2014-04-28 09:37:37 Python version: 3.5.0a0 (default:4f0aaa8804c6, Apr 28 2014, 09:37:03) [MSC v.160 0 32 bit (Intel)] Timer precision: 4.44 us -----------------------+-------------+---------------- Tests????????????????? | ???????orig | ?????????calloc -----------------------+-------------+---------------- object()?????????????? | ?121 ns (*) | ??109 ns (-10%) b'A' * 10????????????? | ??77 ns (*) | ??????????79 ns b'A' * 10**3?????????? | ?159 ns (*) | ???168 ns (+5%) b'A' * 10**6?????????? | ?428 us (*) | ?????????415 us 'A' * 10?????????????? | ??87 ns (*) | ??????????89 ns 'A' * 10**3??????????? | ?175 ns (*) | ?????????177 ns 'A' * 10**6??????????? | ?429 us (*) | ???454 us (+6%) 'A' * 10**8??????????? | 48.4 ms (*) | ??????????49 ms (None,) * 10**0??????? | ??49 ns (*) | ??????????51 ns (None,) * 10**1??????? | ?115 ns (*) | ???99 ns (-14%) (None,) * 10**2??????? | ?433 ns (*) | ?????????422 ns (None,) * 10**3??????? | 3.58 us (*) | ????????3.57 us (None,) * 10**4??????? | 34.9 us (*) | ????????34.9 us (None,) * 10**5??????? | ?347 us (*) | ?????????351 us (None,) * 10**6??????? | 5.14 ms (*) | ??4.85 ms (-6%) (None,) * 10**7??????? | 53.2 ms (*) | ??50.2 ms (-6%) (None,) * 10**8??????? | ?563 ms (*) | ???515 ms (-9%) ([None] * 10)[1:-1]??? | ?217 ns (*) | ?????????217 ns ([None] * 10**3)[1:-1] | 3.89 us (*) | ????????3.92 us ([None] * 10**6)[1:-1] | 5.13 ms (*) | ????????5.17 ms ([None] * 10**8)[1:-1] | ?634 ms (*) | ??533 ms (-16%) bytes(10)????????????? | ?193 ns (*) | ???206 ns (+7%) bytes(10**3)?????????? | ?266 ns (*) | ??296 ns (+12%) bytes(10**6)?????????? | ?414 us (*) | ?3.89 us (-99%) bytes(10**8)?????????? | 44.2 ms (*) | 4.56 us (-100%) bytearray(10)????????? | ?229 ns (*) | ???243 ns (+6%) bytearray(10**3)?????? | ?301 ns (*) | ??330 ns (+10%) bytearray(10**6)?????? | ?421 us (*) | ?3.89 us (-99%) bytearray(10**8)?????? | 44.4 ms (*) | 4.56 us (-100%) -----------------------+-------------+---------------- Total????????????????? | 1.4 sec (*) | 1.16 sec (-17%) -----------------------+-------------+---------------- ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 10:16:04 2014 From: report at bugs.python.org (Marc Schlaich) Date: Mon, 28 Apr 2014 08:16:04 +0000 Subject: [issue21372] multiprocessing.util.register_after_fork inconsistency Message-ID: <1398672964.28.0.985951406539.issue21372@psf.upfronthosting.co.za> New submission from Marc Schlaich: multiprocessing.util.register_after_fork does not behave consistently on Windows because the `_afterfork_registry` is not transferred to the subprocess. The following example fails on Windows while it works perfectly on Linux: import multiprocessing.util def hook(*args): print (args) def func(): print ('func') if __name__ == '__main__': multiprocessing.util.register_after_fork(hook, hook) p = multiprocessing.Process(target=func) p.start() ---------- components: Windows messages: 217347 nosy: schlamar priority: normal severity: normal status: open title: multiprocessing.util.register_after_fork inconsistency type: behavior versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 10:31:41 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 28 Apr 2014 08:31:41 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1398673901.48.0.364895855719.issue21233@psf.upfronthosting.co.za> STINNER Victor added the comment: Changes on the pickle module don't look like an interesting optimization. It even looks slower. $ python perf.py -b fastpickle,fastunpickle,pickle,pickle_dict,pickle_list,slowpickle,slowunpickle,unpickle ../default/python.orig ../default/python.calloc ... Report on Linux selma 3.13.9-200.fc20.x86_64 #1 SMP Fri Apr 4 12:13:05 UTC 2014 x86_64 x86_64 Total CPU cores: 4 ### fastpickle ### Min: 0.364510 -> 0.374144: 1.03x slower Avg: 0.367882 -> 0.377714: 1.03x slower Significant (t=-11.54) Stddev: 0.00493 -> 0.00347: 1.4209x smaller The following not significant results are hidden, use -v to show them: fastunpickle, pickle_dict, pickle_list. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 11:01:14 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 28 Apr 2014 09:01:14 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1398675674.98.0.0545595035397.issue21233@psf.upfronthosting.co.za> STINNER Victor added the comment: Patch version 5. This patch is ready for a review. Summary of calloc-5.patch: - add the following functions: * void* PyMem_RawCalloc(size_t nelem, size_t elsize) * void* PyMem_Calloc(size_t nelem, size_t elsize) * void* PyObject_Calloc(size_t nelem, size_t elsize) * PyObject* _PyObject_GC_Calloc(size_t basicsize) - add "void* calloc(void *ctx, size_t nelem, size_t elsize)" field to the PyMemAllocator structure - optimize bytes(n) and bytearray(n) to allocate objects using calloc() instead of malloc() - update tracemalloc to trace also calloc() - document new functions and add unit tests for the calloc "hook" (in _testcapi) Changes between versions 4 and 5: - revert all changes except bytes(n) and bytearray(n) of use_calloc.patch: they were useless according to benchmarks - _PyObject_GC_Calloc() now takes a single parameter - add versionadded and versionchanged fields in the documentation According to benchmarks, calloc() is only useful for large allocation (1 MB?) if only a part of the memory block is modified (to non-zero bytes) just after the allocation. Untouched memory pages don't use physical memory and don't use RSS memory pages, but it is possible to read their content (null bytes). Using calloc() instead of malloc()+memset(0) doens't look to be faster (it may be a little bit slower) if all bytes are set just after the allocation. I chose to only use one parameter for _PyObject_GC_Calloc() because this function is used to allocate Python objects. A structure of a Python object must start with PyObject_HEAD or PyObject_VAR_HEAD and so the total size of an object cannot be expressed as NELEM * ELEMSIZE. I have no use case for _PyObject_GC_Calloc(), but it makes sense to use it to allocate a large Python object tracked by the GC and using a single memory block for the Python header + data. PyObject_Calloc() simply use memset(0) for small objects (<= 512 bytes). It delegates the allocation to PyMem_RawCalloc(), and so indirectly to calloc(), for larger objects. Note: use_calloc.patch is no more needed, I merged the two patches since only bytes(n) and bytearray(n) now use calloc(). ---------- Added file: http://bugs.python.org/file35072/calloc-5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 11:02:23 2014 From: report at bugs.python.org (Stefan Krah) Date: Mon, 28 Apr 2014 09:02:23 +0000 Subject: [issue20305] Android's incomplete locale.h implementation prevents cross-compilation In-Reply-To: <1390155202.76.0.360148898057.issue20305@psf.upfronthosting.co.za> Message-ID: <1398675743.92.0.523678372156.issue20305@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: +lizhenhua _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 11:03:22 2014 From: report at bugs.python.org (Stefan Krah) Date: Mon, 28 Apr 2014 09:03:22 +0000 Subject: [issue21371] struct lconv does not have decimal_point on android platform In-Reply-To: <1398650559.39.0.586667315036.issue21371@psf.upfronthosting.co.za> Message-ID: <1398675802.68.0.0540940521006.issue21371@psf.upfronthosting.co.za> Stefan Krah added the comment: This looks like a duplicate. ---------- nosy: +skrah resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Android's incomplete locale.h implementation prevents cross-compilation _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 11:15:06 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 28 Apr 2014 09:15:06 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1398676506.19.0.732457019341.issue21233@psf.upfronthosting.co.za> STINNER Victor added the comment: Demo of calloc-5.patch on Linux. Thanks to calloc(), bytes(50 * 1024 * 1024) doesn't allocate memory for null bytes and so the RSS memory is unchanged (+148 kB, not +50 MB), but tracemalloc says that 50 MB were allocated. $ ./python -X tracemalloc Python 3.5.0a0 (default:4b97092aa4bd+, Apr 28 2014, 10:40:53) [GCC 4.8.2 20131212 (Red Hat 4.8.2-7)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import os, tracemalloc >>> os.system("grep RSS /proc/%s/status" % os.getpid()) VmRSS: 10736 kB 0 >>> before = tracemalloc.get_traced_memory()[0] >>> large = bytes(50 * 1024 * 1024) >>> import sys >>> sys.getsizeof(large) / 1024. 51200.0478515625 >>> (tracemalloc.get_traced_memory()[0] - before) / 1024. 51198.1962890625 >>> os.system("grep RSS /proc/%s/status" % os.getpid()) VmRSS: 10884 kB 0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 11:34:03 2014 From: report at bugs.python.org (Stefan Krah) Date: Mon, 28 Apr 2014 09:34:03 +0000 Subject: [issue5404] Cross-compiling Python In-Reply-To: <1235984629.04.0.168155698084.issue5404@psf.upfronthosting.co.za> Message-ID: <1398677643.1.0.100994466973.issue5404@psf.upfronthosting.co.za> Stefan Krah added the comment: Ping. Is this still an issue for anyone in 3.4? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 11:42:20 2014 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Mon, 28 Apr 2014 09:42:20 +0000 Subject: [issue21220] Enhance obmalloc allocation strategy In-Reply-To: <1397499786.06.0.606856949694.issue21220@psf.upfronthosting.co.za> Message-ID: <1398678140.56.0.764883578537.issue21220@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: >> This significantly helps fragmentation in programs with dynamic memory usage, e.g. long running programs. > On which programs? The fragmentation of the memory depends a lot on how the program allocates memory. For example, if a program has no "temporary memory peak", it should not be a victim of the memory fragmentation. "Long running programs." E.g. web servers and so on. Where there is a churn in memory usage. As objects are allocated and released with some sort of churn. New objects will be allocated from lower-address pages, where higher address pages are increasingly likely to be freed as no-longer used objects are released. This is the second best thing to a sliding-block allocator and is motivated by the same requirements that makes such an sliding-block allocator (such as pypy uses) desirable in the first place. > To measure the improvment of such memory allocator, more benchmarks (speed and fragmentation) should be run than a single test (memcruch.py included in the test) written to benchmark the allocator. Yes. Memcrunch was specifically written to simulate a case where objects are continuously created and released, such as might be expected in a server, with a peak in memory usage followed by lower memory usage, and to demonstrate that the pages allocated during the peak will be released later as memory churn causes memory usage to migrate toward lower addresses. However, following Antoine's advice I ran the Benchmarks testsuite and found an adverse effect in the n-body benchmark. That can have two causes: a) the insertion cost of the block when a block moves from 'full' to 'used'. This is a rare event and should be unimportant. I will instrument this for this test and see if it is really the reason b) Cache effects because a newly 'used' block is not immediately allocated from. Again, it happens rarely that a block is linked at the head so this shouldn't be significant. Because of this, this change isn't yet ready to be applied. If however I manage to change the policy so that memory usage becomes better while still preserving performance of the benchmark tests, I will report back :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 11:48:24 2014 From: report at bugs.python.org (Cory Benfield) Date: Mon, 28 Apr 2014 09:48:24 +0000 Subject: [issue20188] ALPN support for TLS In-Reply-To: <1389153179.88.0.510995543218.issue20188@psf.upfronthosting.co.za> Message-ID: <1398678504.84.0.211960536198.issue20188@psf.upfronthosting.co.za> Changes by Cory Benfield : ---------- nosy: +Lukasa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 12:06:51 2014 From: report at bugs.python.org (Sworddragon) Date: Mon, 28 Apr 2014 10:06:51 +0000 Subject: [issue21369] Extended modes for tarfile.TarFile() In-Reply-To: <1398637565.27.0.953592639835.issue21369@psf.upfronthosting.co.za> Message-ID: <1398679611.45.0.594528090843.issue21369@psf.upfronthosting.co.za> Sworddragon added the comment: The TarFile class provides more options. Alternatively a file object could be used but this means additional code (and maybe IO overhead). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 12:07:29 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 28 Apr 2014 10:07:29 +0000 Subject: [issue19977] Use "surrogateescape" error handler for sys.stdin and sys.stdout on UNIX for the C locale In-Reply-To: Message-ID: <1398679645.2302.1.camel@fsol> Antoine Pitrou added the comment: > > We should not overcomplicate this. I suggest that we simply use utf-8 under the C locale. > > Do you mean utf8/strict or utf8/surrogateescape? > > utf8/strict doesn't work (os.listdir raises an unicode error) if your > system is configured to use latin1 (ex: filenames are stored in this > encoding), but unfortunately your program is running in an empty > environment (so will use the POSIX locale). The issue is about stdin and stdout, I'm not sure why os.listdir would be affected. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 12:08:25 2014 From: report at bugs.python.org (Giampaolo Rodola') Date: Mon, 28 Apr 2014 10:08:25 +0000 Subject: [issue13559] Use sendfile where possible in httplib In-Reply-To: <1323377245.96.0.509517020675.issue13559@psf.upfronthosting.co.za> Message-ID: <1398679705.25.0.301894649731.issue13559@psf.upfronthosting.co.za> Changes by Giampaolo Rodola' : ---------- dependencies: +Add a new socket.sendfile() method versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 12:21:21 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 28 Apr 2014 10:21:21 +0000 Subject: [issue20306] Lack of pw_gecos field in Android's struct passwd causes cross-compilation for the pwd module to fail In-Reply-To: <1390155821.88.0.335321844624.issue20306@psf.upfronthosting.co.za> Message-ID: <1398680481.52.0.180360110379.issue20306@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Interesting. It seems pw_gecos isn't mandated by POSIX: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/pwd.h.html I wonder if there's a better way to do this (autoconf check?) than an Android-specific #ifdef, though. ---------- nosy: +pitrou versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 12:43:19 2014 From: report at bugs.python.org (Stefan Krah) Date: Mon, 28 Apr 2014 10:43:19 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1398681799.75.0.901215058328.issue21233@psf.upfronthosting.co.za> Stefan Krah added the comment: With the latest patch the decimal benchmark with a lot of small allocations is consistently 2% slower. Large factorials (where the operands are initialized to zero for the number-theoretic transform) have the same performance with and without the patch. It would be interesting to see some NumPy benchmarks (Nathaniel?). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 12:56:39 2014 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Mon, 28 Apr 2014 10:56:39 +0000 Subject: [issue21369] Extended modes for tarfile.TarFile() In-Reply-To: <1398637565.27.0.953592639835.issue21369@psf.upfronthosting.co.za> Message-ID: <1398682599.29.0.486037208965.issue21369@psf.upfronthosting.co.za> Lars Gust?bel added the comment: You can pass keyword arguments to tarfile.open(), which will be passed to the TarFile constructor. You can also use pass fileobj arguments to tarfile.open(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 13:02:19 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 28 Apr 2014 11:02:19 +0000 Subject: [issue13204] sys.flags.__new__ crashes In-Reply-To: <1318889665.83.0.350090316357.issue13204@psf.upfronthosting.co.za> Message-ID: <1398682939.23.0.722496693949.issue13204@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thanks for the patch, Jessica. It seems to work under Windows here. ---------- versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 13:08:35 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 28 Apr 2014 11:08:35 +0000 Subject: [issue13204] sys.flags.__new__ crashes In-Reply-To: <1318889665.83.0.350090316357.issue13204@psf.upfronthosting.co.za> Message-ID: <3gHNX24k90z7LjR@mail.python.org> Roundup Robot added the comment: New changeset 7052fdd90a11 by Antoine Pitrou in branch '3.4': Issue #13204: Calling sys.flags.__new__ would crash the interpreter, now it raises a TypeError. http://hg.python.org/cpython/rev/7052fdd90a11 New changeset a14012352f65 by Antoine Pitrou in branch 'default': Issue #13204: Calling sys.flags.__new__ would crash the interpreter, now it raises a TypeError. http://hg.python.org/cpython/rev/a14012352f65 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 13:09:00 2014 From: report at bugs.python.org (Sworddragon) Date: Mon, 28 Apr 2014 11:09:00 +0000 Subject: [issue21369] Extended modes for tarfile.TarFile() In-Reply-To: <1398637565.27.0.953592639835.issue21369@psf.upfronthosting.co.za> Message-ID: <1398683340.4.0.545027926524.issue21369@psf.upfronthosting.co.za> Sworddragon added the comment: Interesting, after reading the documentation again I would now assume that is what **kwargs is for. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 13:09:58 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 28 Apr 2014 11:09:58 +0000 Subject: [issue13204] sys.flags.__new__ crashes In-Reply-To: <1318889665.83.0.350090316357.issue13204@psf.upfronthosting.co.za> Message-ID: <1398683398.47.0.333723117694.issue13204@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I've committed the patch to 3.4 and 3.5. I'm closing the issue, I don't think fixing 2.7 is important at this point. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 13:17:19 2014 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Mon, 28 Apr 2014 11:17:19 +0000 Subject: [issue21369] Extended modes for tarfile.TarFile() In-Reply-To: <1398637565.27.0.953592639835.issue21369@psf.upfronthosting.co.za> Message-ID: <1398683839.29.0.0306486479062.issue21369@psf.upfronthosting.co.za> Lars Gust?bel added the comment: Jup. That's it. ---------- priority: normal -> low resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 13:21:17 2014 From: report at bugs.python.org (Donald Stufft) Date: Mon, 28 Apr 2014 11:21:17 +0000 Subject: [issue21305] PEP 466: update os.urandom In-Reply-To: <1397868674.52.0.918643592406.issue21305@psf.upfronthosting.co.za> Message-ID: <1398684077.46.0.486877556167.issue21305@psf.upfronthosting.co.za> Donald Stufft added the comment: "Depleting" /dev/urandom isn't actually a thing. /dev/urandom on all modern *nix OSs uses a fast PRNG which is secure as long as it has received enough bytes of initial entropy. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 13:50:52 2014 From: report at bugs.python.org (Stefan Krah) Date: Mon, 28 Apr 2014 11:50:52 +0000 Subject: [issue1820] Enhance Object/structseq.c to match namedtuple and tuple api In-Reply-To: <1200284428.58.0.762384814897.issue1820@psf.upfronthosting.co.za> Message-ID: <1398685852.6.0.362372847193.issue1820@psf.upfronthosting.co.za> Stefan Krah added the comment: Is accessing _fields a common operation? Personally I'd use a PyGetSetDef and generate the tuple on access (perhaps cache the result). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 13:51:11 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 28 Apr 2014 11:51:11 +0000 Subject: [issue21305] PEP 466: update os.urandom In-Reply-To: <1398684077.46.0.486877556167.issue21305@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > "Depleting" /dev/urandom isn't actually a thing. /dev/urandom on all modern *nix OSs uses a fast PRNG which is secure as long as it has received enough bytes of initial entropy. I didn't say "deplete /dev/urandom", I said that when reading from /dev/urandom "you're depleting your entropy pool". So reading from /dev/urandom won't block, but it can starve processes that read from /dev/random, and that's a problem. See https://groups.google.com/forum/#!msg/fa.linux.kernel/Ocl01d8TzT0/KDCon2ZUm1AJ I think since 2.6 Linux uses two different entropy pools for /dev/random and /dev/urandom, but that might not be true for every OS. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 13:53:48 2014 From: report at bugs.python.org (Meador Inge) Date: Mon, 28 Apr 2014 11:53:48 +0000 Subject: [issue13096] ctypes: segfault with large POINTER type names In-Reply-To: <1317700059.13.0.375039668353.issue13096@psf.upfronthosting.co.za> Message-ID: <1398686028.71.0.143662872324.issue13096@psf.upfronthosting.co.za> Meador Inge added the comment: Thanks for the review and reminder about this issue, jesstess. I will apply the patch later today. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 14:20:48 2014 From: report at bugs.python.org (Shiz) Date: Mon, 28 Apr 2014 12:20:48 +0000 Subject: [issue20306] Lack of pw_gecos field in Android's struct passwd causes cross-compilation for the pwd module to fail In-Reply-To: <1390155821.88.0.335321844624.issue20306@psf.upfronthosting.co.za> Message-ID: <1398687648.54.0.136366206619.issue20306@psf.upfronthosting.co.za> Shiz added the comment: Ah, yes, if it's not actually mandated by POSIX, something like HAVE_PASSWD_PW_GECOS would be more appropriate. I'll rework the patch into something more generic. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 14:52:33 2014 From: report at bugs.python.org (Donald Stufft) Date: Mon, 28 Apr 2014 12:52:33 +0000 Subject: [issue21305] PEP 466: update os.urandom In-Reply-To: <1397868674.52.0.918643592406.issue21305@psf.upfronthosting.co.za> Message-ID: <1398689553.1.0.00973656515503.issue21305@psf.upfronthosting.co.za> Donald Stufft added the comment: I don't think what you're worrying about here is something that has a high chance of happening, if it even occurs in the wild at all. To be clear in order for that to matter at all in the context of this ticket, some software would need to be reading from /dev/random (which almost zero software should be doing) on a system where you have a high number of threads or async handlers all reading from /dev/urandom at the same time and reading enough data off of it to drop the entropy estimation in the primary pool down below whatever amount of data that the other process is attempting to read from /dev/random. In that case no "trouble" will occur and the process reading from /dev/random will just block waiting on additional entropy to be collected so that the entropy estimation is high enough to fulfill the request. AFAIK there are zero practical concerns from reading as much as you want off of /dev/urandom as often as you want. What this change does is make it "safe" to just simply use os.urandom in order to generate random bytes in a Python application. The current situation is such that any use of os.urandom is potentially a place where your application will crash in highly concurrent environments. This will drive people to either: A) Poorly reimplement the persistent FD option, especially troublesome on Windows because the simple approach to doing so will flat out not work on Windows B) Use a userspace CSPRNG, this is considered ill advised by most reputable cryptographer's as most of them have had issues at one point in time or another, and they all generally depend on the security of /dev/urandom anyways so if /dev/urandom fall they fall as well. Using os.urandom is the *right* thing to do for getting random in an application, but the current implementation effectively punishes people who use it if their application is highly concurrent. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 14:55:25 2014 From: report at bugs.python.org (Maxime Lorant) Date: Mon, 28 Apr 2014 12:55:25 +0000 Subject: [issue21373] robotparser: Automatically call modified function in read() Message-ID: <1398689725.23.0.532137440879.issue21373@psf.upfronthosting.co.za> New submission from Maxime Lorant: For the moment, RobotFileParser (on both Python 2.x and 3.x) has a method modified, but it is never called in the class itself, hence the last_checked attribute is always at 0 if the user doesn't call modified() explicitly. I would suggest to add a call to modified() at the end of the read() method. It makes more sense to have a last_checked value (returns in mtime()) updated by the class itself. Especially when the doc says: "Returns the time the ``robots.txt`` file was last fetched.". Currently this sentence isn't true, since the value has to be updated by the user. ---------- components: Library (Lib) files: robotparser.diff keywords: patch messages: 217370 nosy: mlorant, orsenthil priority: normal severity: normal status: open title: robotparser: Automatically call modified function in read() type: enhancement versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file35073/robotparser.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 15:20:45 2014 From: report at bugs.python.org (=?utf-8?q?William_Tis=C3=A4ter?=) Date: Mon, 28 Apr 2014 13:20:45 +0000 Subject: [issue20962] Rather modest chunk size in gzip.GzipFile In-Reply-To: <1395082726.87.0.730756156096.issue20962@psf.upfronthosting.co.za> Message-ID: <1398691245.65.0.146486528329.issue20962@psf.upfronthosting.co.za> William Tis?ter added the comment: That makes sense. I proceeded and updated `Lib/gzip.py` to use `io.DEFAULT_BUFFER_SIZE` instead. This will change the existing behaviour in two ways: * Start using 1024 * 8 as buffer size instead of 1024. * Add one more kwarg (`buffer_size`) to `GzipFile.__init__()`. Ps. This is my first patch, tell me if I'm missing something. ---------- Added file: http://bugs.python.org/file35074/20962_default-buffer-size.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 15:34:01 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 28 Apr 2014 13:34:01 +0000 Subject: [issue21305] PEP 466: update os.urandom In-Reply-To: <1398689553.1.0.00973656515503.issue21305@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > Using os.urandom is the *right* thing to do for getting random in an application, but the current implementation effectively punishes people who use it if their application is highly concurrent. And I argue that this scenario is almost as likely as the one you depict above: we never had a bug report before, and if you have a look at the the bug report which led to the change in question, it's not clear at all that all threads were indeed reading from /dev/urandom when EMFILE was raised. Since reading from /dev/urandom shouldn't block, it's not clear at all how a realistic workload would actually hit the file descriptor limit because RLIMIT_NOFILE threads are reading from /dev/urandom. But don't get me wrong, I'm not saying this change is useless, it actually makes sense to use a persistent FD. But backporting always has a risk, which has to be balanced. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 15:35:43 2014 From: report at bugs.python.org (akira) Date: Mon, 28 Apr 2014 13:35:43 +0000 Subject: [issue19940] ssl.cert_time_to_seconds() returns wrong results if local timezone is not UTC In-Reply-To: <1386660552.46.0.291263983729.issue19940@psf.upfronthosting.co.za> Message-ID: <1398692143.84.0.415818266118.issue19940@psf.upfronthosting.co.za> akira added the comment: I've updated the patch: - fixed the code example in the documentation to use int instead of float result - removed assertion on the int returned type (float won't lose precision for the practical dates but guaranteeing an integer would be nice) - reworded the scary comment - removed tests that test the tests Ready for review. ---------- Added file: http://bugs.python.org/file35075/ssl_cert_time_to_seconds-ps6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 15:38:36 2014 From: report at bugs.python.org (Donald Stufft) Date: Mon, 28 Apr 2014 13:38:36 +0000 Subject: [issue21305] PEP 466: update os.urandom In-Reply-To: <1397868674.52.0.918643592406.issue21305@psf.upfronthosting.co.za> Message-ID: <1398692316.67.0.521734309762.issue21305@psf.upfronthosting.co.za> Donald Stufft added the comment: > But backporting always has a risk, which has to be balanced. Sure, which is why a PEP was written, discussed and accepted to find that balance. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 16:09:39 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 28 Apr 2014 14:09:39 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1398694179.34.0.339588067443.issue21233@psf.upfronthosting.co.za> STINNER Victor added the comment: > With the latest patch the decimal benchmark with a lot of small > allocations is consistently 2% slower. Does your benchmark use bytes(int) or bytearray(int)? If not, I guess that your benchmark is not reliable because only these two functions are changed by calloc-5.patch, except if there is a bug in my patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 17:01:51 2014 From: report at bugs.python.org (Jim Jewett) Date: Mon, 28 Apr 2014 15:01:51 +0000 Subject: [issue21362] concurrent.futures does not validate that max_workers is proper In-Reply-To: <1398598769.27.0.217084820664.issue21362@psf.upfronthosting.co.za> Message-ID: <1398697311.53.0.733245148783.issue21362@psf.upfronthosting.co.za> Jim Jewett added the comment: I confirm the bug. The patch looks good. ---------- nosy: +Jim.Jewett _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 17:11:54 2014 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 28 Apr 2014 15:11:54 +0000 Subject: [issue8776] Bytes version of sys.argv In-Reply-To: <1274357456.02.0.0768864678422.issue8776@psf.upfronthosting.co.za> Message-ID: <1398697914.95.0.646742689311.issue8776@psf.upfronthosting.co.za> Nick Coghlan added the comment: I'd like to revisit this after PEP 432 is in place, since having to do this dance for arg processing when running on Linux in the POSIX locale is somewhat lame: argv = sys.argv encoding = locale.getpreferredencoding() # Hope nobody changed the locale! fixed_encoding = read_encoding_from("/etc/locale.conf") # For example argvb = [arg.encode(encoding, "surrogateescape") for arg in argv] fixed_argv = [arg.decode(fixed_encoding, "surrogateescape") for arg in argvb] (For stricter parsing, leave out the second "surrogateescape") Now, if PEP 432 resolves the system encoding issue such that we are able to use the right encoding even when locale.getpreferredencoding() returns the wrong answer, then it may not be worthwhile to also provide sys.argvb (especially since it won't help hybrid 2/3 code). On the other hand, like os.environb, it does make it easier for POSIX-only code paths that wants to handle boundary encoding issues directly to stick with consuming the binary data directly and avoid the interpreter's automatic conversion to the text domain. Note also that os.environb is only available when os.supports_bytes_environ is True, so it would make sense to only provide sys.argvb in the circumstances where we provide os.environb. ---------- assignee: -> ncoghlan nosy: +ncoghlan resolution: wont fix -> later status: closed -> open versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 17:12:56 2014 From: report at bugs.python.org (Jim Jewett) Date: Mon, 28 Apr 2014 15:12:56 +0000 Subject: [issue1599254] mailbox: other programs' messages can vanish without trace Message-ID: <1398697976.28.0.295022386502.issue1599254@psf.upfronthosting.co.za> Jim Jewett added the comment: pinging David Watson: What is the status? If I understand correctly, (and I may well not), you have already opened other issues for parts of this, and (only) the final patch is ready for patch (and hopefully) commit review. Is this correct? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 17:14:44 2014 From: report at bugs.python.org (Jim Jewett) Date: Mon, 28 Apr 2014 15:14:44 +0000 Subject: [issue20974] email module docs say not compatible with current python version In-Reply-To: <1395176910.11.0.458502603486.issue20974@psf.upfronthosting.co.za> Message-ID: <1398698084.36.0.576592463925.issue20974@psf.upfronthosting.co.za> Jim Jewett added the comment: I don't know for sure if the compatibility claims are correct, but the patch looks good. ---------- stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 17:52:17 2014 From: report at bugs.python.org (Stefan Krah) Date: Mon, 28 Apr 2014 15:52:17 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1398700337.7.0.783401118928.issue21233@psf.upfronthosting.co.za> Stefan Krah added the comment: Hmm, obmalloc.c changed as well, so already the gcc optimizer can take different paths and produce different results. Also I did set mpd_callocfunc to PyMem_Calloc(). 2% slowdown is far from being a tragic result, so I guess we can ignore that. The bytes() speedup is very nice. Allocations that took one second are practically instant now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 18:00:26 2014 From: report at bugs.python.org (Stefan Krah) Date: Mon, 28 Apr 2014 16:00:26 +0000 Subject: [issue21374] DecimalTuple.__module__ is set to _frozen_importlib Message-ID: <1398700826.27.0.585241892269.issue21374@psf.upfronthosting.co.za> New submission from Stefan Krah: >>> x = Decimal(9).as_tuple() >>> import pickle >>> pickle.dumps(x) Traceback (most recent call last): File "", line 1, in _pickle.PicklingError: Can't pickle : attribute lookup DecimalTuple on _frozen_importlib failed ---------- components: Extension Modules messages: 217381 nosy: skrah priority: normal severity: normal stage: needs patch status: open title: DecimalTuple.__module__ is set to _frozen_importlib type: behavior versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 18:31:59 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 28 Apr 2014 16:31:59 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1398700337.7.0.783401118928.issue21233@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > Also I did set mpd_callocfunc to PyMem_Calloc(). 2% slowdown is far > from being a tragic result, so I guess we can ignore that. Agreed. > The bytes() speedup is very nice. Allocations that took one second > are practically instant now. Indeed. Victor, thanks for the great work! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 18:59:56 2014 From: report at bugs.python.org (Stefan Krah) Date: Mon, 28 Apr 2014 16:59:56 +0000 Subject: [issue21370] segfault from simple traceback.format_exc call In-Reply-To: <1398638273.35.0.105572602615.issue21370@psf.upfronthosting.co.za> Message-ID: <1398704396.7.0.661403219177.issue21370@psf.upfronthosting.co.za> Stefan Krah added the comment: I cannot reproduce this. Which platform? Does it happen with Python 3.4? ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 19:03:44 2014 From: report at bugs.python.org (Stefan Krah) Date: Mon, 28 Apr 2014 17:03:44 +0000 Subject: [issue19354] test_format fails on RHEL-6 In-Reply-To: <1382466990.37.0.806335115025.issue19354@psf.upfronthosting.co.za> Message-ID: <1398704624.84.0.288363411312.issue19354@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- resolution: -> out of date stage: -> resolved status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 19:05:11 2014 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 28 Apr 2014 17:05:11 +0000 Subject: [issue21354] PyCFunction_New no longer exposed by python DLL breaking bdist_wininst installers In-Reply-To: <1398499255.25.0.881446688113.issue21354@psf.upfronthosting.co.za> Message-ID: <1398704711.69.0.847346395472.issue21354@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Ok, I'll take a look. Sorry, probably I've missed python3.def file. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 19:11:25 2014 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 28 Apr 2014 17:11:25 +0000 Subject: [issue19977] Use "surrogateescape" error handler for sys.stdin and sys.stdout on UNIX for the C locale In-Reply-To: <1398679645.2302.1.camel@fsol> Message-ID: Nick Coghlan added the comment: Victor was referring to code like "print(os.listdir())". Those are the motivating cases for ensuring round trips from system APIs to the standard streams work correctly. There's also the problem that sys.argv currently relies on the locale encoding directly, because the filesystem encoding hasn't been worked out at that point (see issue 8776). So this current change will also make "print(sys.argv)" work more reliably in the POSIX locale. The conclusion I have come to is that any further decoupling of Python 3 from the locale encoding will actually depend on getting the PEP 432 bootstrapping changes implemented, reviewed and the PEP approved, so we have more interpreter infrastructure in place by the time the interpreter starts trying to figure out all these boundary encoding issues. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 19:13:17 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 28 Apr 2014 17:13:17 +0000 Subject: [issue19977] Use "surrogateescape" error handler for sys.stdin and sys.stdout on UNIX for the C locale In-Reply-To: Message-ID: <1398705195.2393.5.camel@fsol> Antoine Pitrou added the comment: > The conclusion I have come to is that any further decoupling of Python 3 > from the locale encoding will actually depend on getting the PEP 432 > bootstrapping changes implemented, reviewed and the PEP approved, so we > have more interpreter infrastructure in place by the time the interpreter > starts trying to figure out all these boundary encoding issues. Yeah. My proposal had more to do with the fact that we should some day switch to utf-8 by default on all POSIX systems, regardless of what the system advertises as "best encoding". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 19:19:54 2014 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 28 Apr 2014 17:19:54 +0000 Subject: [issue19977] Use "surrogateescape" error handler for sys.stdin and sys.stdout on UNIX for the C locale In-Reply-To: <1398705195.2393.5.camel@fsol> Message-ID: Nick Coghlan added the comment: Antoine Pitrou added the comment: > Yeah. My proposal had more to do with the fact that we should some day > switch to utf-8 by default on all POSIX systems, regardless of what the > system advertises as "best encoding". Yeah, that seems like a plausible future to me as well, and knowing it's a step along that path actually gives me more motivation to get back to working on the startup issues :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 19:28:58 2014 From: report at bugs.python.org (Stefan Krah) Date: Mon, 28 Apr 2014 17:28:58 +0000 Subject: [issue1533105] NetBSD build with --with-pydebug causes SIGSEGV Message-ID: <1398706138.55.0.198190303234.issue1533105@psf.upfronthosting.co.za> Stefan Krah added the comment: Given msg84518 and msg118909 I think this can be closed. ---------- resolution: -> out of date stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 19:59:54 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 28 Apr 2014 17:59:54 +0000 Subject: [issue21375] Fix and test overflow behavior in the C version of heapq Message-ID: <1398707994.45.0.696035798055.issue21375@psf.upfronthosting.co.za> New submission from Raymond Hettinger: The Py_ssizet indexes can overflow the "childpos" variable: childpos = 2*pos + 1; /* leftmost child position */ while (childpos < endpos) ... http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html ---------- assignee: rhettinger components: Extension Modules messages: 217389 nosy: rhettinger priority: normal severity: normal stage: needs patch status: open title: Fix and test overflow behavior in the C version of heapq type: behavior versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 20:05:57 2014 From: report at bugs.python.org (Philip Sequeira) Date: Mon, 28 Apr 2014 18:05:57 +0000 Subject: [issue21376] asyncio docs refer to wrong TimeoutError Message-ID: <1398708357.06.0.922465155945.issue21376@psf.upfronthosting.co.za> New submission from Philip Sequeira: Example: https://docs.python.org/3.4/library/asyncio-task.html TimeoutError is mentioned several times, and links to the OSError subclass. However, the actual TimeoutError raised by asyncio stuff is the one from concurrent.futures, which is not compatible. The docs as they are seem to suggest that something like "except TimeoutError" would be appropriate, when in fact that would not produce the expected behavior; "except asyncio.TimeoutError" is what you'd want. ---------- assignee: docs at python components: Documentation messages: 217390 nosy: docs at python, qmega priority: normal severity: normal status: open title: asyncio docs refer to wrong TimeoutError versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 20:13:19 2014 From: report at bugs.python.org (Steve Dower) Date: Mon, 28 Apr 2014 18:13:19 +0000 Subject: [issue1284316] Win32: Security problem with default installation directory Message-ID: <1398708799.46.0.415586296965.issue1284316@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- nosy: +steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 20:22:01 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 28 Apr 2014 18:22:01 +0000 Subject: [issue20962] Rather modest chunk size in gzip.GzipFile In-Reply-To: <1395082726.87.0.730756156096.issue20962@psf.upfronthosting.co.za> Message-ID: <1398709321.48.0.427240583039.issue20962@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > So I'd suggest, instead of using an hardcoded value, to simply reuse io.DEFAULT_BUFFER_SIZE. > That way, if some day we decide to change it, all user code wil benefit from the change. I don't think io.DEFAULT_BUFFER_SIZE makes much sense as a heuristic for the gzip module (or compressed files in general). Perhaps gzip should get its own DEFAULT_BUFFER_SIZE? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 20:49:35 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 28 Apr 2014 18:49:35 +0000 Subject: [issue19940] ssl.cert_time_to_seconds() returns wrong results if local timezone is not UTC In-Reply-To: <1386660552.46.0.291263983729.issue19940@psf.upfronthosting.co.za> Message-ID: <1398710975.22.0.829915775901.issue19940@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thanks for the updated patch, Akira! I'm gonna take a look right now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 20:52:27 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 28 Apr 2014 18:52:27 +0000 Subject: [issue20962] Rather modest chunk size in gzip.GzipFile In-Reply-To: <1398709321.48.0.427240583039.issue20962@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > I don't think io.DEFAULT_BUFFER_SIZE makes much sense as a heuristic for the gzip module (or compressed files in general). Perhaps gzip should get its own DEFAULT_BUFFER_SIZE? Do you mean from a namespace point of vue, or from a performance point of view? Because this size is used to read/write from underlying the file object, so using the io default would make sense, no? Sure, it might not be optimal for compressed files, but I gues that the optimal value is function of the compression-level block size and many other factors which are just too varied to come up with a reasonable heuristic. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 20:57:46 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 28 Apr 2014 18:57:46 +0000 Subject: [issue19940] ssl.cert_time_to_seconds() returns wrong results if local timezone is not UTC In-Reply-To: <1386660552.46.0.291263983729.issue19940@psf.upfronthosting.co.za> Message-ID: <3gHZxQ0R3Qz7Ljx@mail.python.org> Roundup Robot added the comment: New changeset 7191c37238d5 by Antoine Pitrou in branch 'default': Issue #19940: ssl.cert_time_to_seconds() now interprets the given time string in the UTC timezone (as specified in RFC 5280), not the local timezone. http://hg.python.org/cpython/rev/7191c37238d5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 20:58:17 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 28 Apr 2014 18:58:17 +0000 Subject: [issue19940] ssl.cert_time_to_seconds() returns wrong results if local timezone is not UTC In-Reply-To: <1386660552.46.0.291263983729.issue19940@psf.upfronthosting.co.za> Message-ID: <1398711497.97.0.65241231873.issue19940@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I've committed the patch. Thank you very much for contributing! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 20:59:42 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 28 Apr 2014 18:59:42 +0000 Subject: [issue20962] Rather modest chunk size in gzip.GzipFile In-Reply-To: Message-ID: <1398711580.2393.7.camel@fsol> Antoine Pitrou added the comment: > Sure, it might not be optimal for compressed files, but I gues that > the optimal value is function of the compression-level block size and > many other factors which are just too varied to come up with a > reasonable heuristic. Well, I think that compressed files in general would benefit from a larger buffer size than plain binary I/O, but that's just a hunch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 21:12:37 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 28 Apr 2014 19:12:37 +0000 Subject: [issue21312] Update thread_foobar.h to include timed locking and TLS support In-Reply-To: <1397928633.2.0.869900067411.issue21312@psf.upfronthosting.co.za> Message-ID: <3gHbGX6GBrz7Lkn@mail.python.org> Roundup Robot added the comment: New changeset 7bb1bda5dcef by Antoine Pitrou in branch 'default': Issue #21312: Update the thread_foobar.h template file to include newer threading APIs. Patch by Jack McCracken. http://hg.python.org/cpython/rev/7bb1bda5dcef ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 21:13:13 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 28 Apr 2014 19:13:13 +0000 Subject: [issue21312] Update thread_foobar.h to include timed locking and TLS support In-Reply-To: <1397928633.2.0.869900067411.issue21312@psf.upfronthosting.co.za> Message-ID: <1398712393.54.0.520116244741.issue21312@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok, noone chimed in, so I committed the patch :-) Thank you very much for your contribution! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 21:20:44 2014 From: report at bugs.python.org (Jim Jewett) Date: Mon, 28 Apr 2014 19:20:44 +0000 Subject: [issue16104] Compileall script: add option to use multiple cores In-Reply-To: <1349124414.14.0.0730954283721.issue16104@psf.upfronthosting.co.za> Message-ID: <1398712844.51.0.321714781298.issue16104@psf.upfronthosting.co.za> Jim Jewett added the comment: Trying to put bounds on the disagreements. Does anyone disagree with any of the following: (1) compileall currently runs single-threaded in a single process. (2) This enhancement intends to allow parallelization by process. (3) Users MAY need to express whether they (require/forbid/are expressly apathetic concerning) paralellization. (3A) There is some doubt that this even needs to be user-controlled. (3B) If it is user-controlled, the patch proposes adding a "processes" parameter to do this. (3C) There have been suggestions of other names (notably "workers"), but *if* it is user-controlled, the idea of a new parameter is not controversial. (4) Users MAY need to control the degree of parallelization. (4A) If so, setting the value of the new parameter to a positive integer > 1 is an acceptable solution. (4B) There is not yet consensus on how to represent "Use multi-processing, with the default degree for this system.", "Do NOT use multiprocessing.", or "I don't care." (4C) Suggested values have included 1, 0, -1, any negative number, None, and specific strings. The precise mapping between some of these and the three cases of 4B is not agreed. (5) If multiprocessing is explicitly requested, what should happen when it is not available? (5A) Fall back to the current way, without multi-processing. (5B) Fall back to the current way, without multi-processing, but issue a Warning. (5C) Raise an Exception. (ValueError, ImportError, NotImplemented?) (6) Portions of the documentation unrelated to this should be fixed. But ideally, that would be done separately, and it will NOT be a pre-requisite to this patch. --------------------------------------------------- Another potential value set None (the default) ==> let the system parallelize as best it can -- as it does in multiprocessing. If the system picks "not in parallel at all", that is also OK, and no warning is raised. 0 ==> Do not parallelize. positive integers ==> Use that many processes. negative ==> ValueError Would these uses of 0 and negative be too surprising for someone? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 21:20:55 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 28 Apr 2014 19:20:55 +0000 Subject: [issue21376] asyncio docs refer to wrong TimeoutError In-Reply-To: <1398708357.06.0.922465155945.issue21376@psf.upfronthosting.co.za> Message-ID: <1398712855.45.0.47796802283.issue21376@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Gasp. Perhaps concurrent.futures.TimeoutError can inherit from the standard TimeoutError? The following patch doesn't seem to disrupt the test suite: diff --git a/Lib/concurrent/futures/_base.py b/Lib/concurrent/futures/_base.py --- a/Lib/concurrent/futures/_base.py +++ b/Lib/concurrent/futures/_base.py @@ -49,7 +49,7 @@ class CancelledError(Error): """The Future was cancelled.""" pass -class TimeoutError(Error): +class TimeoutError(Error, TimeoutError): """The operation exceeded the given deadline.""" pass ---------- assignee: docs at python -> components: +Library (Lib) nosy: +giampaolo.rodola, gvanrossum, haypo, pitrou, yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 21:21:32 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 28 Apr 2014 19:21:32 +0000 Subject: [issue16104] Compileall script: add option to use multiple cores In-Reply-To: <1349124414.14.0.0730954283721.issue16104@psf.upfronthosting.co.za> Message-ID: <1398712892.12.0.89658182349.issue16104@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: -pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 21:24:26 2014 From: report at bugs.python.org (Skip Montanaro) Date: Mon, 28 Apr 2014 19:24:26 +0000 Subject: [issue20962] Rather modest chunk size in gzip.GzipFile In-Reply-To: <1398711580.2393.7.camel@fsol> Message-ID: Skip Montanaro added the comment: On Mon, Apr 28, 2014 at 1:59 PM, Antoine Pitrou wrote: > Well, I think that compressed files in general would benefit from a > larger buffer size than plain binary I/O, but that's just a hunch. I agree. When writing my patch, my (perhaps specious) thinking went like this. * We have a big-ass file, so we compress it. * On average, when seeking to another point in that file, we probably want to go a long way. * It's possible that operating system read-ahead semantics will make read performance relatively high. * That would put more burden on the Python code to be efficient. * Larger buffer sizes will reduce the amount of Python bytecode which must be executed. So, if I have a filesystem block size of 8192 bytes, while that would represent some sort of "optimal" chunk size, in practice, I think operating system read-ahead and post-read processing of the bytes read will tend to suggest larger chunk sizes. Hence my naive choice of 16k bytes for _CHUNK_SIZE in my patch. Skip ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 21:26:12 2014 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 28 Apr 2014 19:26:12 +0000 Subject: [issue21376] asyncio docs refer to wrong TimeoutError In-Reply-To: <1398708357.06.0.922465155945.issue21376@psf.upfronthosting.co.za> Message-ID: <1398713172.24.0.553137259656.issue21376@psf.upfronthosting.co.za> Guido van Rossum added the comment: I considered this, and decided against unifying the two TimeoutErrors. First the builtin TimeoutError is specifically a subclass of OSError representing the case where errno is ETIMEDOUT. But asyncio.TimeoutError means nothing of the sort. Second, the precedent is concurrent.futures.TimeoutError. The asyncio one is used under the same conditions as that one. I think we should just update the links in the docs to be correct. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 21:26:35 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 28 Apr 2014 19:26:35 +0000 Subject: [issue5404] Cross-compiling Python In-Reply-To: <1235984629.04.0.168155698084.issue5404@psf.upfronthosting.co.za> Message-ID: <1398713195.65.0.517780943511.issue5404@psf.upfronthosting.co.za> Gregory P. Smith added the comment: I haven't tried a cross compile in ages. If nothing else I don't think this issue should be closed until we have at least one buildbot setup to cross compile it and run it on the target platform. That's on my long "todo for python" wish list but I haven't had time to figure out how to set that up yet. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 21:28:56 2014 From: report at bugs.python.org (Tim Golden) Date: Mon, 28 Apr 2014 19:28:56 +0000 Subject: [issue18314] Have os.unlink remove junction points In-Reply-To: <1372335321.1.0.479247042071.issue18314@psf.upfronthosting.co.za> Message-ID: <1398713336.41.0.959574889719.issue18314@psf.upfronthosting.co.za> Tim Golden added the comment: I'm just pinging #python-dev to see if there's a way to request a buildbot build from a specific server-side clone. Meanwhile, though, I definitely introduced a change into your code which I thought I had reverted, but clearly hadn't! The code, as committed, used PyMem_RawAlloc in place of the calloc() call you had, but didn't replace the later free() by its PyMem counterpart. If I don't get any joy with the clone-specific buildbot question, I'll just rebuild from your original patch, re-commit, and watch the buildbots. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 21:33:02 2014 From: report at bugs.python.org (Ned Deily) Date: Mon, 28 Apr 2014 19:33:02 +0000 Subject: [issue21372] multiprocessing.util.register_after_fork inconsistency In-Reply-To: <1398672964.28.0.985951406539.issue21372@psf.upfronthosting.co.za> Message-ID: <1398713582.4.0.939854783077.issue21372@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 21:34:13 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 28 Apr 2014 19:34:13 +0000 Subject: [issue21057] TextIOWrapper does not support reading bytearrays or memoryviews In-Reply-To: <1395720869.89.0.455515257207.issue21057@psf.upfronthosting.co.za> Message-ID: <1398713653.59.0.458733843073.issue21057@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > My usecase is that I have a binary stream class that internally uses memoryviews. Ok, I think it is a reasonable use case. I'm gonna look at your patch and give it a review. ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 21:47:24 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 28 Apr 2014 19:47:24 +0000 Subject: [issue21377] PyBytes_Concat could try to concat in-place Message-ID: <1398714444.35.0.443659487134.issue21377@psf.upfronthosting.co.za> New submission from Antoine Pitrou: Currently, PyBytes_Concat always creates a new bytes object for the result. However, when Py_REFCNT(*pv) == 1, it could instead call _PyBytes_Resize() and then concat the second argument in place. (like e.g. _PyUnicode_Append does) ---------- components: Interpreter Core messages: 217406 nosy: haypo, nikratio, pitrou priority: normal severity: normal status: open title: PyBytes_Concat could try to concat in-place type: performance versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 21:47:57 2014 From: report at bugs.python.org (Anton Afanasyev) Date: Mon, 28 Apr 2014 19:47:57 +0000 Subject: [issue21321] itertools.islice() doesn't release reference to the source iterator when the slice is exhausted In-Reply-To: <1398082430.51.0.59207810702.issue21321@psf.upfronthosting.co.za> Message-ID: <1398714477.7.0.844701459634.issue21321@psf.upfronthosting.co.za> Anton Afanasyev added the comment: Hi Antoine, I have no found a way to check resource usage in test infrastructure and I don't think it could be done carefully. The only method I found to test issue is straightforward: just to check source iterator is not referenced from itertools.islice() after the latter has been exhausted: ================================================ a = [random.random() for i in range(10)] before = sys.getrefcount(a) b = islice(a, 5) for i in b: pass after = sys.getrefcount(a) self.assertEqual(before, after) ================================================ Attaching "issue21321_2.7_e3217efa6edd_3.diff" and "issue21321_3.4_8c8315bac6a8_3.diff" patches with this test included in "Lib/test/test_itertools.py". ---------- Added file: http://bugs.python.org/file35076/issue21321_2.7_e3217efa6edd_3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 21:48:34 2014 From: report at bugs.python.org (Anton Afanasyev) Date: Mon, 28 Apr 2014 19:48:34 +0000 Subject: [issue21321] itertools.islice() doesn't release reference to the source iterator when the slice is exhausted In-Reply-To: <1398082430.51.0.59207810702.issue21321@psf.upfronthosting.co.za> Message-ID: <1398714514.97.0.950890798591.issue21321@psf.upfronthosting.co.za> Changes by Anton Afanasyev : Added file: http://bugs.python.org/file35077/issue21321_3.4_8c8315bac6a8_3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 21:51:23 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 28 Apr 2014 19:51:23 +0000 Subject: [issue8776] Bytes version of sys.argv In-Reply-To: <1274357456.02.0.0768864678422.issue8776@psf.upfronthosting.co.za> Message-ID: <1398714683.48.0.496459346482.issue8776@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Without commenting on this specific proposal, I would like to make an overall observation that Python is impairing its usability by adding too-many-ways-to-it in a number of categories (file descriptor variants of file methods, multiple versions of time.time, byte variants of everything that is done with strings). Python 3 was intended to be a cleaner, more learnable version of Python. Instead, it is growing enums, multiple dispatch, and multiple variants of every function. Professional programmers can be well served by some of the these tools, but the Python universe is much larger than that and the other users are not being well served by these additions (too many choices impairs usability and learnability). ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 21:54:55 2014 From: report at bugs.python.org (David Bolen) Date: Mon, 28 Apr 2014 19:54:55 +0000 Subject: [issue17861] put opcode information in one place In-Reply-To: <1367162089.6.0.986391601417.issue17861@psf.upfronthosting.co.za> Message-ID: <1398714895.26.0.0490679808421.issue17861@psf.upfronthosting.co.za> David Bolen added the comment: This generator script breaks the daily OSX DMG builds on my bolen-dmg buildslave for the 3.x branch. The issue is with the use of "with" as the slave uses Python 2.5 to build the installer. Now, that's old, and I'm not even sure how necessary the daily builds are to keep running, but I believe the Mac build-installer script still tries to target 2.5 as a minimum - though I'm not sure if that's true for all build tools. But the fix is fairly simple (a __future__ import). See attached patch. Alternatively, if the minimum Python to build the installer should be bumped, I can work on that for the slave. ---------- nosy: +db3l Added file: http://bugs.python.org/file35078/generate_opcode_h.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 21:54:56 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 28 Apr 2014 19:54:56 +0000 Subject: [issue21321] itertools.islice() doesn't release reference to the source iterator when the slice is exhausted In-Reply-To: <1398082430.51.0.59207810702.issue21321@psf.upfronthosting.co.za> Message-ID: <1398714896.32.0.230266649653.issue21321@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Anton, the test is wrong: it is taking a reference to the iterable object (the list), not the iterator. To check the reference to the original iterator is released, something like this would work: >>> import itertools, weakref >>> it = (x for x in (1, 2)) >>> wr = weakref.ref(it) >>> it = itertools.islice(it, 1) >>> wr() is None False >>> list(it) [1] >>> wr() is None # returns True with the patch, False without True ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 21:55:20 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 28 Apr 2014 19:55:20 +0000 Subject: [issue21321] itertools.islice() doesn't release reference to the source iterator when the slice is exhausted In-Reply-To: <1398082430.51.0.59207810702.issue21321@psf.upfronthosting.co.za> Message-ID: <1398714920.59.0.598687643938.issue21321@psf.upfronthosting.co.za> Antoine Pitrou added the comment: (note I haven't looked at the C part of the patch) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 22:08:46 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 28 Apr 2014 20:08:46 +0000 Subject: [issue20962] Rather modest chunk size in gzip.GzipFile In-Reply-To: Message-ID: Charles-Fran?ois Natali added the comment: That could make sense, dunno. Note that the bz2 module uses a harcoded 8K value. Note that the buffer size should probably be passed to the open() call. Also, the allocation is quite peculiar: it uses an exponential buffer size, starting at a tiny value: 202 # Starts small, scales exponentially 203 self.min_readsize = 100 In short, I think the overall buffering should be rewritten :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 22:13:29 2014 From: report at bugs.python.org (Skip Montanaro) Date: Mon, 28 Apr 2014 20:13:29 +0000 Subject: [issue20962] Rather modest chunk size in gzip.GzipFile In-Reply-To: Message-ID: Skip Montanaro added the comment: On Mon, Apr 28, 2014 at 3:08 PM, Charles-Fran?ois Natali wrote: > In short, I think the overall buffering should be rewritten :-) Perhaps so, but I think we should open a separate ticket for that instead of instituting some feature creep here (no matter how reasonable the concept or its changes would be). S ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 22:40:54 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 28 Apr 2014 20:40:54 +0000 Subject: [issue20962] Rather modest chunk size in gzip.GzipFile In-Reply-To: Message-ID: Charles-Fran?ois Natali added the comment: > Perhaps so, but I think we should open a separate ticket for that > instead of instituting some feature creep here (no matter how > reasonable the concept or its changes would be). Agreed. The patch looks good to me, so feel free to commit! (FWIW, gzip apparently uses a fixed-32K buffer read). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 22:47:25 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 28 Apr 2014 20:47:25 +0000 Subject: [issue17861] put opcode information in one place In-Reply-To: <1367162089.6.0.986391601417.issue17861@psf.upfronthosting.co.za> Message-ID: <3gHdMw5ys4z7Ljb@mail.python.org> Roundup Robot added the comment: New changeset 1fd9c3f6cf68 by Ned Deily in branch 'default': Issue #17861: Allow generate_opcode_h to run with a system Python 2.5. http://hg.python.org/cpython/rev/1fd9c3f6cf68 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 22:49:24 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 28 Apr 2014 20:49:24 +0000 Subject: [issue8776] Bytes version of sys.argv In-Reply-To: <1274357456.02.0.0768864678422.issue8776@psf.upfronthosting.co.za> Message-ID: <1398718164.45.0.823053353847.issue8776@psf.upfronthosting.co.za> STINNER Victor added the comment: Today I regret os.environb (I added it). If I remember correctly, os.environb was added before the PEP 383 (surrogateescape). This PEP makes os.environb almost useless. In Python 3, Unicode is the natural choice, and thanks to the PEP 383, it's still possible to use any "raw bytes". argvb can be computed in one line: list(map(os.fsencode, sys.argv)). I now suggest to close this issue as wontfix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 22:53:45 2014 From: report at bugs.python.org (Ned Deily) Date: Mon, 28 Apr 2014 20:53:45 +0000 Subject: [issue17861] put opcode information in one place In-Reply-To: <1367162089.6.0.986391601417.issue17861@psf.upfronthosting.co.za> Message-ID: <1398718425.92.0.777104404677.issue17861@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks, David. Ideally, the generator script shouldn't run during an installer build since presumably the generated file should be up-to-date in the repo. "make touch" could handle that but the installer build does use a separate build/object directory and doesn't currently use "make touch". For Python 3.5, the installer build now does need at least a Python 2.6 to build the documentation but there's no reason to unnecessarily break the main build with such a simple fix available. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 23:02:30 2014 From: report at bugs.python.org (Bill Bergmann) Date: Mon, 28 Apr 2014 21:02:30 +0000 Subject: [issue21378] ImportError: No module named 'concurrent.futures' Message-ID: <1398718950.31.0.466187960646.issue21378@psf.upfronthosting.co.za> New submission from Bill Bergmann: python 3.4 attempting to run example at https://docs.python.org/3/library/concurrent.futures.html 17.4.2.1 $ python3 17_4_2.py Traceback (most recent call last): File "", line 2195, in _find_and_load_unlocked AttributeError: 'module' object has no attribute '__path__' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "17_4_2.py", line 1, in import concurrent.futures ImportError: No module named 'concurrent.futures'; 'concurrent' is not a package os: OS X 10.6 from $env: PATH=/Library/Frameworks/Python.framework/Versions/3.4/bin:/Library/Frameworks/Python.framework/Versions/2.7/bin: ... PYTHONPATH=/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/:/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/: ... ---------- components: Library (Lib) messages: 217418 nosy: Bill.Bergmann priority: normal severity: normal status: open title: ImportError: No module named 'concurrent.futures' type: crash versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 23:05:48 2014 From: report at bugs.python.org (Zachary Ware) Date: Mon, 28 Apr 2014 21:05:48 +0000 Subject: [issue17386] Bring Doc/make.bat as close to Doc/Makefile as possible In-Reply-To: <1362781994.31.0.121984055749.issue17386@psf.upfronthosting.co.za> Message-ID: <1398719148.86.0.297577108003.issue17386@psf.upfronthosting.co.za> Zachary Ware added the comment: New patch, fixes a typo bug in a useless statement (by removing the statement) and a few pesky tabs that made their way into make.bat. Also, a little better organization in the vars at the top. ---------- Added file: http://bugs.python.org/file35079/issue17386.v2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 23:06:30 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Mon, 28 Apr 2014 21:06:30 +0000 Subject: [issue21378] ImportError: No module named 'concurrent.futures' In-Reply-To: <1398718950.31.0.466187960646.issue21378@psf.upfronthosting.co.za> Message-ID: <1398719190.69.0.207569385213.issue21378@psf.upfronthosting.co.za> Claudiu.Popa added the comment: Do you have a module/file named concurrent.py in your PATH? ---------- nosy: +Claudiu.Popa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 23:10:29 2014 From: report at bugs.python.org (Hannan Aharonov) Date: Mon, 28 Apr 2014 21:10:29 +0000 Subject: [issue21379] StopIteration is silenced when raised by generator within context manager Message-ID: <1398719429.87.0.781789142964.issue21379@psf.upfronthosting.co.za> New submission from Hannan Aharonov: If the code that defines a context manager performs some operations on a generator that cause it to raise StopIteration, this exception is propagated to the context manager's __exit__() method and there swallowed by a try..except block. This can cause unexpected/unintuitive behaviour. The following simplified example shows an infinite loop caused by this: ------- from contextlib import contextmanager @contextmanager def manager(gen): yield gen.next() emptygen = (_ for _ in ()) while True: with manager(emptygen): print "Infinite Loop" ------- In this case, even though the generator is empty, the loop will never stop, because the generator's StopIteration exception is swallowed by the context manager. (If `gen.next()` was wrapped by try..except that reraises exception as, say, RuntimeError, the program would stop.) I've looked at the source (here: http://hg.python.org/cpython/file/tip/Lib/contextlib.py line 67) and I understand why this is happening: the context manager can't tell the difference between the two kinds of StopIteration - one that is raised by its own completion, and one that is raised by a call in its body. I don't know if this is a bug or expected behavior of nested generators. In any case, I haven't seen this issue mentioned in the documentation, and the behavior is unintuitive. I've searched the bug tracker and found a similar issue that handled swallowing of StopIteration in the code wrapped by the context manager (http://bugs.python.org/issue1705170), and another similar issue (http://bugs.python.org/issue16610) that was closed without resolution. ---------- components: Interpreter Core, Library (Lib) messages: 217421 nosy: hannan.aha, ncoghlan priority: normal severity: normal status: open title: StopIteration is silenced when raised by generator within context manager versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 23:13:47 2014 From: report at bugs.python.org (Ned Deily) Date: Mon, 28 Apr 2014 21:13:47 +0000 Subject: [issue21378] ImportError: No module named 'concurrent.futures' In-Reply-To: <1398718950.31.0.466187960646.issue21378@psf.upfronthosting.co.za> Message-ID: <1398719627.04.0.382676048905.issue21378@psf.upfronthosting.co.za> Ned Deily added the comment: FWIW, works for me using the python.org 3.4 64-bin installer. What is the output of: python3 -c 'import sys;print(sys.version)' As Claudiu suggests, check for a concurrent.py shadowing the standard library version. Also, why are you setting PYTHONPATH to include /Library/Frameworks/Python.framework/Versions/{3.4,2.7}/lib/python3.4/site-packages/? Those are the standard locations for site-packages are included automatically in sys.path by the respective interpreters. Setting PYTHONPATH should not normally be needed. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 23:14:22 2014 From: report at bugs.python.org (Hannan Aharonov) Date: Mon, 28 Apr 2014 21:14:22 +0000 Subject: [issue21379] StopIteration is silenced when raised by generator within context manager In-Reply-To: <1398719429.87.0.781789142964.issue21379@psf.upfronthosting.co.za> Message-ID: <1398719662.69.0.585818672629.issue21379@psf.upfronthosting.co.za> Changes by Hannan Aharonov : ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 23:16:01 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 28 Apr 2014 21:16:01 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1398700337.7.0.783401118928.issue21233@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > Hmm, obmalloc.c changed as well, so already the gcc optimizer can take > different paths and produce different results. If decimal depends on allocator performances, you should maybe try to implement a freelist. > Also I did set mpd_callocfunc to PyMem_Calloc(). I don't understand. 2% slowdown is when you use calloc? Do you have the same speed if you don't use calloc? According to my benchmarks, calloc is slower if some bytes are modified later. > The bytes() speedup is very nice. Allocations that took one second > are practically instant now. Is it really useful? Who need bytes(10**8) object? Faster creation of bytearray(int) may be useful in real applications. I really like bytearray and memoryview to avoid memory copies. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 23:21:42 2014 From: report at bugs.python.org (Michael P. Soulier) Date: Mon, 28 Apr 2014 21:21:42 +0000 Subject: [issue21380] timezone support in strftime methods broken Message-ID: <1398720102.85.0.645448692913.issue21380@psf.upfronthosting.co.za> New submission from Michael P. Soulier: msoulier at cappuccino:~$ python Python 2.7.3 (default, Mar 13 2014, 11:03:55) [GCC 4.7.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from datetime import datetime >>> now = datetime.now() >>> now.strftime("%z") '' >>> import time >>> time.strftime("%z", time.localtime(time.time())) '+0000' >>> I think those calls should be printing the UTC offset, no? ---------- components: Extension Modules messages: 217424 nosy: msoulier priority: normal severity: normal status: open title: timezone support in strftime methods broken type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 28 23:51:59 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 28 Apr 2014 21:51:59 +0000 Subject: [issue21305] PEP 466: update os.urandom In-Reply-To: <1397868674.52.0.918643592406.issue21305@psf.upfronthosting.co.za> Message-ID: <1398721919.68.0.108868854694.issue21305@psf.upfronthosting.co.za> STINNER Victor added the comment: Please don't backport this "feature". We had to wait 20 years before someone requested the feature, but only a few months before the first user reported an issue ("regression"?). IMO it would be much better to use explicitly a random.SystemRandom instance which would keep the fd open, and only use it if you hit the bug (*many* threads calling os.urandom in parallel. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 00:09:16 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 28 Apr 2014 22:09:16 +0000 Subject: [issue7511] msvc9compiler.py: ValueError when trying to compile with VC Express In-Reply-To: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za> Message-ID: <1398722956.82.0.390774100181.issue7511@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +brian.curtin, tim.golden _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 00:13:22 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 28 Apr 2014 22:13:22 +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: <1398723202.55.0.070317858349.issue19217@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ezio, do you intend to add a test to your patch? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 00:21:05 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 28 Apr 2014 22:21:05 +0000 Subject: [issue21225] io.py: Improve docstrings for classes In-Reply-To: <1397508646.21.0.210626779275.issue21225@psf.upfronthosting.co.za> Message-ID: <3gHgS03khZz7LjV@mail.python.org> Roundup Robot added the comment: New changeset 6e23afdee4e4 by Andrew Kuchling in branch '2.7': #21225: copy docstrings from base classes http://hg.python.org/cpython/rev/6e23afdee4e4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 00:21:36 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 28 Apr 2014 22:21:36 +0000 Subject: [issue21225] io.py: Improve docstrings for classes In-Reply-To: <1397508646.21.0.210626779275.issue21225@psf.upfronthosting.co.za> Message-ID: <1398723696.32.0.669618871822.issue21225@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I've backported Andrew's change. ---------- nosy: +pitrou resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 00:22:37 2014 From: report at bugs.python.org (Donald Stufft) Date: Mon, 28 Apr 2014 22:22:37 +0000 Subject: [issue21305] PEP 466: update os.urandom In-Reply-To: <1397868674.52.0.918643592406.issue21305@psf.upfronthosting.co.za> Message-ID: <1398723757.61.0.467382503147.issue21305@psf.upfronthosting.co.za> Donald Stufft added the comment: Well except random.SystemRandom doesn't keep the file open (At least in 2.7) and actually it just calls os.urandom under the covers, also it doesn't make it very nice to get a glob of random bytes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 00:23:00 2014 From: report at bugs.python.org (Stefan Krah) Date: Mon, 28 Apr 2014 22:23:00 +0000 Subject: [issue5404] Cross-compiling Python In-Reply-To: <1235984629.04.0.168155698084.issue5404@psf.upfronthosting.co.za> Message-ID: <1398723780.5.0.0437441920785.issue5404@psf.upfronthosting.co.za> Stefan Krah added the comment: Here's a cross-compile script for arm-linux-gnueabi. Building 3.4 works on Ubuntu 14.04. I cannot run the tests, since I only have an old Debian-ARM qemu image with the wrong glibc version. For 3.5 we have a regression due to the new matrix operator. ---------- Added file: http://bugs.python.org/file35080/arm-linux-gnueabi.sh _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 00:24:24 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 28 Apr 2014 22:24:24 +0000 Subject: [issue21353] document Popen.args attribute In-Reply-To: <1398481373.88.0.978177813548.issue21353@psf.upfronthosting.co.za> Message-ID: <1398723864.44.0.518571350021.issue21353@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Gregory, do you think this is ok to document? ---------- nosy: +gregory.p.smith, pitrou stage: -> patch review versions: -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 00:26:40 2014 From: report at bugs.python.org (Donald Stufft) Date: Mon, 28 Apr 2014 22:26:40 +0000 Subject: [issue21305] PEP 466: update os.urandom In-Reply-To: <1397868674.52.0.918643592406.issue21305@psf.upfronthosting.co.za> Message-ID: <1398724000.45.0.519154270659.issue21305@psf.upfronthosting.co.za> Donald Stufft added the comment: Just verified that 3.x also does not exhibit this behavior with random.SystemRandom (except implicitly through os.urandom doing it). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 00:26:49 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 28 Apr 2014 22:26:49 +0000 Subject: [issue17227] devguide: buggy heading numbers In-Reply-To: <1361217002.34.0.936078305401.issue17227@psf.upfronthosting.co.za> Message-ID: <1398724009.11.0.294007690709.issue17227@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I agree with Chris, changing the tocdepth doesn't sound like the right solution. Is this a Sphinx bug? Georg, could you please take a look? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 00:40:56 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 28 Apr 2014 22:40:56 +0000 Subject: [issue21273] don't defined socket constants which are not implemented for GNU/Hurd In-Reply-To: <1397687407.58.0.755430574464.issue21273@psf.upfronthosting.co.za> Message-ID: <1398724856.66.0.520919474799.issue21273@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok, rejecting. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 00:46:14 2014 From: report at bugs.python.org (akira) Date: Mon, 28 Apr 2014 22:46:14 +0000 Subject: [issue19940] ssl.cert_time_to_seconds() returns wrong results if local timezone is not UTC In-Reply-To: <1386660552.46.0.291263983729.issue19940@psf.upfronthosting.co.za> Message-ID: <1398725174.1.0.00725632963364.issue19940@psf.upfronthosting.co.za> akira added the comment: Antoine, thank you for reviewing. I appreciate the patience. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 00:48:12 2014 From: report at bugs.python.org (Stefan Krah) Date: Mon, 28 Apr 2014 22:48:12 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1398725292.17.0.511833326436.issue21233@psf.upfronthosting.co.za> Stefan Krah added the comment: The order of the nelem/elsize matters for readability. Otherwise it is not intuitive what happens after the jump to redirect in _PyObject_Alloc(). Why would you assert that 'nelem' is one? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 00:58:20 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 28 Apr 2014 22:58:20 +0000 Subject: [issue20355] -W command line options should have higher priority than PYTHONWARNINGS environmental variable In-Reply-To: <1390426906.93.0.692922610327.issue20355@psf.upfronthosting.co.za> Message-ID: <3gHhGz3GVZz7Lmx@mail.python.org> Roundup Robot added the comment: New changeset 78c0d80a04f9 by Antoine Pitrou in branch 'default': Issue #20355: -W command line options now have higher priority than the PYTHONWARNINGS environment variable. Patch by Arfrever. http://hg.python.org/cpython/rev/78c0d80a04f9 New changeset 925c0b611c02 by Antoine Pitrou in branch 'default': Remove a workaround for fixed issue #20355. http://hg.python.org/cpython/rev/925c0b611c02 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 00:58:46 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 28 Apr 2014 22:58:46 +0000 Subject: [issue20355] -W command line options should have higher priority than PYTHONWARNINGS environmental variable In-Reply-To: <1390426906.93.0.692922610327.issue20355@psf.upfronthosting.co.za> Message-ID: <1398725926.5.0.498362069271.issue20355@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Committed. Thanks, Arfrever! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 00:59:58 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 28 Apr 2014 22:59:58 +0000 Subject: [issue20361] -W command line options and PYTHONWARNINGS environmental variable should not override -b / -bb command line options In-Reply-To: <1390468789.64.0.236388970509.issue20361@psf.upfronthosting.co.za> Message-ID: <1398725998.45.0.363679988379.issue20361@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The patch is a bit problematic, because Py_BytesWarningFlag may also be set by e.g. an application embedding Python, but then Python's main.c won't be executed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 01:01:56 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 28 Apr 2014 23:01:56 +0000 Subject: [issue21137] Better repr for threading.Lock() In-Reply-To: <1396487942.81.0.581020836184.issue21137@psf.upfronthosting.co.za> Message-ID: <1398726116.3.0.546876729617.issue21137@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > The repr of threading._RLock contains owner and count, but not > lock/unlock status. The repr of locks from _dummy_thread also should > contain lock/unlock status. And it would be nice to have the > open/closed status in the repr of other synchronization primitives: > Condition, Semaphore, etc. I think it's ok to stay focussed and restrict this issue to threading.Lock (and perhaps RLock). Berker, do you want to provide an updated patch? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 01:08:57 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 28 Apr 2014 23:08:57 +0000 Subject: [issue10203] sqlite3.Row doesn't support sequence protocol In-Reply-To: <1288120293.93.0.799619941752.issue10203@psf.upfronthosting.co.za> Message-ID: <1398726537.48.0.511424075981.issue10203@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Issue #13583 ("sqlite3.Row doesn't support slice indexes") is partly related. ---------- nosy: +jesstess, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 01:25:48 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 28 Apr 2014 23:25:48 +0000 Subject: [issue9815] assertRaises as a context manager keeps tracebacks and frames alive In-Reply-To: <1284103100.0.0.404704166803.issue9815@psf.upfronthosting.co.za> Message-ID: <3gHhtf1kz4z7LjZ@mail.python.org> Roundup Robot added the comment: New changeset 6ab3193e890e by Antoine Pitrou in branch '3.4': Issue #9815: assertRaises now tries to clear references to local variables in the exception's traceback. http://hg.python.org/cpython/rev/6ab3193e890e New changeset 553fe27521be by Antoine Pitrou in branch 'default': Issue #9815: assertRaises now tries to clear references to local variables in the exception's traceback. http://hg.python.org/cpython/rev/553fe27521be ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 01:26:39 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 28 Apr 2014 23:26:39 +0000 Subject: [issue9815] assertRaises as a context manager keeps tracebacks and frames alive In-Reply-To: <1284103100.0.0.404704166803.issue9815@psf.upfronthosting.co.za> Message-ID: <1398727599.82.0.936759856791.issue9815@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I've committed an alternate patch using traceback.clear_frames(). ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 01:30:35 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 28 Apr 2014 23:30:35 +0000 Subject: [issue1615158] POSIX capabilities support Message-ID: <1398727835.84.0.816176822539.issue1615158@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- stage: patch review -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 01:32:37 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 28 Apr 2014 23:32:37 +0000 Subject: [issue7105] weak dict iterators are fragile because of unpredictable GC runs In-Reply-To: <1255282166.4.0.13882602695.issue7105@psf.upfronthosting.co.za> Message-ID: <1398727957.84.0.471267576265.issue7105@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Since this is backported, shouldn't it be closed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 01:33:05 2014 From: report at bugs.python.org (Nathaniel Smith) Date: Mon, 28 Apr 2014 23:33:05 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1398727985.63.0.779990467682.issue21233@psf.upfronthosting.co.za> Nathaniel Smith added the comment: > It would be interesting to see some NumPy benchmarks (Nathaniel?). What is it you want to see? NumPy already uses calloc; we benchmarked it when we added it and it made a huge difference to various realistic workloads :-). What NumPy gets out of this isn't calloc, it's access to tracemalloc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 01:39:32 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 28 Apr 2014 23:39:32 +0000 Subject: [issue9307] Py_TPFLAGS_LONG_SUBCLASS is not documented In-Reply-To: <1279561825.23.0.120090245801.issue9307@psf.upfronthosting.co.za> Message-ID: <3gHjBW1Tv4z7LjQ@mail.python.org> Roundup Robot added the comment: New changeset 37786ae8cc1c by Antoine Pitrou in branch '3.4': Issue #9307: document the various Py_TPFLAGS_*_SUBCLASS flags. Patch by Yury V. Zaytsev. http://hg.python.org/cpython/rev/37786ae8cc1c New changeset d1a03834cec7 by Antoine Pitrou in branch 'default': Issue #9307: document the various Py_TPFLAGS_*_SUBCLASS flags. Patch by Yury V. Zaytsev. http://hg.python.org/cpython/rev/d1a03834cec7 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 01:39:58 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 28 Apr 2014 23:39:58 +0000 Subject: [issue9307] Py_TPFLAGS_LONG_SUBCLASS is not documented In-Reply-To: <1279561825.23.0.120090245801.issue9307@psf.upfronthosting.co.za> Message-ID: <1398728398.12.0.871238239576.issue9307@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This is committed, thank you. ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed versions: +Python 3.4 -Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 01:40:34 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 28 Apr 2014 23:40:34 +0000 Subject: [issue20064] PyObject_Malloc is not documented In-Reply-To: <1387913960.58.0.680621486861.issue20064@psf.upfronthosting.co.za> Message-ID: <1398728434.5.0.401777454079.issue20064@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 01:43:11 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 28 Apr 2014 23:43:11 +0000 Subject: [issue18616] enable more ssl socket options with get_server_certificate In-Reply-To: <1375372562.92.0.356754094449.issue18616@psf.upfronthosting.co.za> Message-ID: <1398728591.65.0.853042722659.issue18616@psf.upfronthosting.co.za> Antoine Pitrou added the comment: To be frank, it's quite easy to open the connection and read the cert yourself, so I don't think complicating this API is very useful. Still, I'm leaving this open so that other developers can chime in. ---------- nosy: +christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 01:45:02 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 28 Apr 2014 23:45:02 +0000 Subject: [issue18400] Minor increase to Pickle test coverage In-Reply-To: <1373259878.07.0.171161881505.issue18400@psf.upfronthosting.co.za> Message-ID: <1398728702.44.0.231253887912.issue18400@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Why only test the _Pickler class and not both the Python and C versions? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 01:46:40 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 28 Apr 2014 23:46:40 +0000 Subject: [issue19767] pathlib: iterfiles() and iterdirs() In-Reply-To: <1385375147.52.0.820545347485.issue19767@psf.upfronthosting.co.za> Message-ID: <1398728800.55.0.398750239305.issue19767@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Having an `iterdirs()` method next to `iterdir()` is very confusing. We should find something else, so how about `files()` and `subdirs()`? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 01:47:43 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 28 Apr 2014 23:47:43 +0000 Subject: [issue19420] Leak in _hashopenssl.c In-Reply-To: <1382961198.75.0.11599120872.issue19420@psf.upfronthosting.co.za> Message-ID: <1398728863.41.0.667798818759.issue19420@psf.upfronthosting.co.za> Antoine Pitrou added the comment: 3.3 is in security mode now, so this can be closed IMO. ---------- nosy: +pitrou resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 01:48:06 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 28 Apr 2014 23:48:06 +0000 Subject: [issue13248] deprecated in 3.2/3.3, should be removed in 3.4 In-Reply-To: <1319392186.66.0.823106983991.issue13248@psf.upfronthosting.co.za> Message-ID: <1398728886.75.0.0153824337205.issue13248@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Apparently we missed some of the stuff here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 01:51:15 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 28 Apr 2014 23:51:15 +0000 Subject: [issue18564] Integer overflow in socketmodule In-Reply-To: <1374861545.82.0.430674187566.issue18564@psf.upfronthosting.co.za> Message-ID: <1398729075.32.0.0222993618983.issue18564@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Michele, do you plan to update this patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 01:58:41 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 28 Apr 2014 23:58:41 +0000 Subject: [issue18727] test for writing dictionary rows to CSV In-Reply-To: <1376409675.57.0.271656920796.issue18727@psf.upfronthosting.co.za> Message-ID: <3gHjcZ0Kwvz7LjS@mail.python.org> Roundup Robot added the comment: New changeset 2502843dbedf by Antoine Pitrou in branch 'default': Issue #18727: improve test coverage of the csv module by testing for DictWriter.writerows. http://hg.python.org/cpython/rev/2502843dbedf ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 01:59:31 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 28 Apr 2014 23:59:31 +0000 Subject: [issue18727] test for writing dictionary rows to CSV In-Reply-To: <1376409675.57.0.271656920796.issue18727@psf.upfronthosting.co.za> Message-ID: <1398729571.26.0.0739996781433.issue18727@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Hi Muhammad, Sorry, I had forgotten about this issue. I have now committed the patch to 3.5. Thanks for your contribution! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 02:04:07 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 29 Apr 2014 00:04:07 +0000 Subject: [issue15088] PyGen_NeedsFinalizing is public, but undocumented In-Reply-To: <1339906861.99.0.42415214654.issue15088@psf.upfronthosting.co.za> Message-ID: <1398729847.93.0.683049449561.issue15088@psf.upfronthosting.co.za> Antoine Pitrou added the comment: For the record, PyGen_NeedsFinalizing still exists but it isn't used anymore in the code base (following PEP 442). ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 02:04:24 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 29 Apr 2014 00:04:24 +0000 Subject: [issue13248] deprecated in 3.2/3.3, should be removed in 3.4 In-Reply-To: <1319392186.66.0.823106983991.issue13248@psf.upfronthosting.co.za> Message-ID: <3gHjlC3xtzz7LjW@mail.python.org> Roundup Robot added the comment: New changeset 2cceb8cb552b by Giampaolo Rodola' in branch 'default': fix isuse #13248: remove previously deprecated asyncore.dispatcher __getattr__ cheap inheritance hack. http://hg.python.org/cpython/rev/2cceb8cb552b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 02:08:08 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 29 Apr 2014 00:08:08 +0000 Subject: [issue10872] Add mode to TextIOWrapper repr In-Reply-To: <1294564948.19.0.858903256762.issue10872@psf.upfronthosting.co.za> Message-ID: <1398730088.12.0.92523462742.issue10872@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- resolution: accepted -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 03:27:38 2014 From: report at bugs.python.org (Christian Tismer) Date: Tue, 29 Apr 2014 01:27:38 +0000 Subject: [issue21381] python build crash on Mavericht Message-ID: <1398734858.53.0.489606157179.issue21381@psf.upfronthosting.co.za> New submission from Christian Tismer: Building python on OSX Mavericks (10.9) of Python 3.4 crashes when this is set: MACOSX_DEPLOYMENT_TARGET=10.7 This happens with OSX 10.9.2, all current updates installed, as of 2014-04-28. Demo script: You can use my attached script to validate this error. The script builds PySide for 16 configurations. Exactly on Python 3.4 / OSX 10.7 it crashes. You can easily tweak the creating loop to just build the crashing case. Cheers -- Chris ---------- components: Build files: pyside_builder.py messages: 217458 nosy: Christian.Tismer priority: low severity: normal stage: needs patch status: open title: python build crash on Mavericht type: crash versions: Python 3.4 Added file: http://bugs.python.org/file35081/pyside_builder.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 03:30:16 2014 From: report at bugs.python.org (Ned Deily) Date: Tue, 29 Apr 2014 01:30:16 +0000 Subject: [issue21381] python build crash on Mavericht In-Reply-To: <1398734858.53.0.489606157179.issue21381@psf.upfronthosting.co.za> Message-ID: <1398735016.3.0.978869948038.issue21381@psf.upfronthosting.co.za> Ned Deily added the comment: In general, we don't test or claim to support building for a deployment target lower than the system being built on. It's always safer to build on the same version as the deployment target. I'll take a look at it, though. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 03:53:52 2014 From: report at bugs.python.org (Christian Tismer) Date: Tue, 29 Apr 2014 01:53:52 +0000 Subject: [issue21381] python build crash on Mavericht In-Reply-To: <1398734858.53.0.489606157179.issue21381@psf.upfronthosting.co.za> Message-ID: <1398736432.6.0.831927571826.issue21381@psf.upfronthosting.co.za> Christian Tismer added the comment: Ned: """In general, we don't test or claim to support building for a deployment target lower than the system being built on.""" This is not convincing, because the cpython builds are always against <$ MACOSX_DEPLOYMENT_TARGET=10.6> . Other builds use the current OS deployment. See for instance homebrew. My script uses them all, from a 10.9 version. This is because I never know what users use for building, and I don't care and build just everything. By your default builds that are uploaded, you do claim that things build for 10.6 exactly, and nothing else. I just think that all targets for all versions should build. Am I mistaken here? ---------- priority: low -> normal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 04:19:35 2014 From: report at bugs.python.org (paul j3) Date: Tue, 29 Apr 2014 02:19:35 +0000 Subject: [issue9253] argparse: optional subparsers In-Reply-To: <1279056589.03.0.566167994161.issue9253@psf.upfronthosting.co.za> Message-ID: <1398737975.57.0.997258334365.issue9253@psf.upfronthosting.co.za> paul j3 added the comment: Another Stackoverflow question triggered by this issue http://stackoverflow.com/questions/23349349/argparse-with-required-subparser ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 04:51:44 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Tue, 29 Apr 2014 02:51:44 +0000 Subject: [issue20951] SSLSocket.send() returns 0 for non-blocking socket In-Reply-To: <1395004591.32.0.211111410214.issue20951@psf.upfronthosting.co.za> Message-ID: <1398739904.42.0.410431617374.issue20951@psf.upfronthosting.co.za> Changes by Nikolaus Rath : Added file: http://bugs.python.org/file35082/issue20951_r3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 05:00:21 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Tue, 29 Apr 2014 03:00:21 +0000 Subject: [issue21057] TextIOWrapper does not support reading bytearrays or memoryviews In-Reply-To: <1395720869.89.0.455515257207.issue21057@psf.upfronthosting.co.za> Message-ID: <1398740421.79.0.624208871878.issue21057@psf.upfronthosting.co.za> Changes by Nikolaus Rath : Added file: http://bugs.python.org/file35083/issue_21057_r3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 05:58:54 2014 From: report at bugs.python.org (Saimadhav Heblikar) Date: Tue, 29 Apr 2014 03:58:54 +0000 Subject: [issue21380] timezone support in strftime methods broken In-Reply-To: <1398720102.85.0.645448692913.issue21380@psf.upfronthosting.co.za> Message-ID: <1398743934.03.0.935163661357.issue21380@psf.upfronthosting.co.za> Changes by Saimadhav Heblikar : ---------- nosy: +sahutd _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 06:01:01 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Tue, 29 Apr 2014 04:01:01 +0000 Subject: [issue21377] PyBytes_Concat could try to concat in-place In-Reply-To: <1398714444.35.0.443659487134.issue21377@psf.upfronthosting.co.za> Message-ID: <1398744061.85.0.131751657351.issue21377@psf.upfronthosting.co.za> Nikolaus Rath added the comment: Tentative patch attached. The test suite still passes, but I'm not sure if it actually exerts the new code path. Is there a standard way to test the C api? ---------- keywords: +patch Added file: http://bugs.python.org/file35084/issue_21377.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 06:01:14 2014 From: report at bugs.python.org (=?utf-8?q?Kim_Gr=C3=A4sman?=) Date: Tue, 29 Apr 2014 04:01:14 +0000 Subject: [issue18314] Have os.unlink remove junction points In-Reply-To: <1372335321.1.0.479247042071.issue18314@psf.upfronthosting.co.za> Message-ID: <1398744074.31.0.0532694209348.issue18314@psf.upfronthosting.co.za> Kim Gr?sman added the comment: Aha, that might cause trouble. I think you should add a memset() to sero out the newly allocated buffer also, I think I may have used calloc to be able to assume it was initialized with zeros. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 06:17:21 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Tue, 29 Apr 2014 04:17:21 +0000 Subject: [issue21377] PyBytes_Concat could try to concat in-place In-Reply-To: <1398714444.35.0.443659487134.issue21377@psf.upfronthosting.co.za> Message-ID: <1398745041.82.0.340677138339.issue21377@psf.upfronthosting.co.za> Changes by Nikolaus Rath : Added file: http://bugs.python.org/file35085/issue_21377_r2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 06:26:20 2014 From: report at bugs.python.org (=?utf-8?q?Kim_Gr=C3=A4sman?=) Date: Tue, 29 Apr 2014 04:26:20 +0000 Subject: [issue18314] Have os.unlink remove junction points In-Reply-To: <1372335321.1.0.479247042071.issue18314@psf.upfronthosting.co.za> Message-ID: <1398745580.71.0.752395485419.issue18314@psf.upfronthosting.co.za> Kim Gr?sman added the comment: Sorry, that wasn't clear. I mean if you change allocator _from_ calloc, make sure the buffer is zeroed out after allocation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 06:33:14 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 29 Apr 2014 04:33:14 +0000 Subject: [issue21026] Document sitecustomize.py problems with pythonw In-Reply-To: <1395519186.07.0.912886400259.issue21026@psf.upfronthosting.co.za> Message-ID: <3gHqjN5LMTz7LjX@mail.python.org> Roundup Robot added the comment: New changeset 79a4560a702f by Terry Jan Reedy in branch '2.7': Closes #21026: Augment site doc based on experiments. Patch by Carol Willing. http://hg.python.org/cpython/rev/79a4560a702f New changeset 3fef95842314 by Terry Jan Reedy in branch '3.4': Issue #21026: Augment site doc based on experiments. Patch by Carol Willing. http://hg.python.org/cpython/rev/3fef95842314 ---------- nosy: +python-dev resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 06:38:51 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 29 Apr 2014 04:38:51 +0000 Subject: [issue21352] improve documentation indexing In-Reply-To: <1398457661.12.0.679738685491.issue21352@psf.upfronthosting.co.za> Message-ID: <1398746331.69.0.462434495376.issue21352@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 07:04:18 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 29 Apr 2014 05:04:18 +0000 Subject: [issue21048] Index 'as' in import and with statements In-Reply-To: <1395638558.42.0.404654056681.issue21048@psf.upfronthosting.co.za> Message-ID: <1398747858.35.0.649911904597.issue21048@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I forgot the # in commit message. Changeset: 90501 (9a0fc12991e2) Closes 21048: Index 'as' in import and with statements. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 07:20:39 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 29 Apr 2014 05:20:39 +0000 Subject: [issue21055] Index (augmented) assignment symbols In-Reply-To: <1395703645.11.0.646299409216.issue21055@psf.upfronthosting.co.za> Message-ID: <3gHrm60t6mz7LjZ@mail.python.org> Roundup Robot added the comment: New changeset d32b6900da6f by Terry Jan Reedy in branch '2.7': Closes #21055: Index (augmented) assignment symbols. http://hg.python.org/cpython/rev/d32b6900da6f New changeset 0b946c8d7837 by Terry Jan Reedy in branch '3.4': Issue #21055: Index (augmented) assignment symbols. http://hg.python.org/cpython/rev/0b946c8d7837 ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 07:23:13 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 29 Apr 2014 05:23:13 +0000 Subject: [issue1820] Enhance Object/structseq.c to match namedtuple and tuple api In-Reply-To: <1200284428.58.0.762384814897.issue1820@psf.upfronthosting.co.za> Message-ID: <1398748993.18.0.958578410534.issue1820@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > Is accessing _fields a common operation? Not common at all -- it is used for introspection. That said, there is nearly zero savings from generating the tuple upon look-up. I would say that using a PyGetSetDef is a false optimization. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 07:30:09 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 29 Apr 2014 05:30:09 +0000 Subject: [issue21054] Improve indexing of syntax symbols In-Reply-To: <1395703578.43.0.642568496743.issue21054@psf.upfronthosting.co.za> Message-ID: <1398749409.51.0.294419468907.issue21054@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- dependencies: +Derby: Convert the _sre module to use Argument Clinic, Index (augmented) assignment symbols _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 07:30:45 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 29 Apr 2014 05:30:45 +0000 Subject: [issue21054] Improve indexing of syntax symbols In-Reply-To: <1395703578.43.0.642568496743.issue21054@psf.upfronthosting.co.za> Message-ID: <1398749445.56.0.193738526473.issue21054@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- dependencies: +Index 'as' in import and with statements -Derby: Convert the _sre module to use Argument Clinic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 07:36:21 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Tue, 29 Apr 2014 05:36:21 +0000 Subject: [issue17861] put opcode information in one place In-Reply-To: <1367162089.6.0.986391601417.issue17861@psf.upfronthosting.co.za> Message-ID: <1398749781.14.0.131171482152.issue17861@psf.upfronthosting.co.za> Martin v. L?wis added the comment: It would be possible to have the daily DMG builder run "make touch". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 07:44:26 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 29 Apr 2014 05:44:26 +0000 Subject: [issue21305] PEP 466: update os.urandom In-Reply-To: <1398723757.61.0.467382503147.issue21305@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Le 29 avr. 2014 00:22, "Donald Stufft" a ?crit : > Well except random.SystemRandom doesn't keep the file open (At least in 2.7) and actually it just calls os.urandom under the covers, also it doesn't make it very nice to get a glob of random bytes. Yes, I'm proposing to enhance this class. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 07:55:35 2014 From: report at bugs.python.org (=?utf-8?q?Kim_Gr=C3=A4sman?=) Date: Tue, 29 Apr 2014 05:55:35 +0000 Subject: [issue18314] Have os.unlink remove junction points In-Reply-To: <1372335321.1.0.479247042071.issue18314@psf.upfronthosting.co.za> Message-ID: <1398750935.74.0.232556577851.issue18314@psf.upfronthosting.co.za> Kim Gr?sman added the comment: By the way, is PyMem_RawMalloc/PyMem_RawFree preferred for memory allocation across the board? If so, I can just prepare a new patch for you with that changed, zero-initialization in place and the prefix-overrun fixed. I might get to it tonight. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 07:56:47 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 29 Apr 2014 05:56:47 +0000 Subject: [issue21305] PEP 466: update os.urandom In-Reply-To: Message-ID: Charles-Fran?ois Natali added the comment: > Yes, I'm proposing to enhance this class. The problem is AFAICT there's currently no way to get a file descriptor to the underlying /dev/urandom (and I don't know how it works on Windows). Also, this would duplicate the work which has already been done. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 08:01:12 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 29 Apr 2014 06:01:12 +0000 Subject: [issue21037] add an AddressSanitizer build option In-Reply-To: <1395581927.59.0.22052744693.issue21037@psf.upfronthosting.co.za> Message-ID: <1398751272.44.0.501848815887.issue21037@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: I'd like to move this forward: it could IMO be a great way to proactively detect potential security defects, and nasty stack/heap/memory corruption in general. The remaining - missing - part is buildbot integration: AFAICT the only specific thing to do is to start the process with the ASAN_OPTIONS environment variable set to "handle_segv=0", to avoid interference with faulthandler. But I'm not really familiar with the buildbot support, so if anyone has a clue... ---------- nosy: +haypo, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 08:27:03 2014 From: report at bugs.python.org (Anton Afanasyev) Date: Tue, 29 Apr 2014 06:27:03 +0000 Subject: [issue21321] itertools.islice() doesn't release reference to the source iterator when the slice is exhausted In-Reply-To: <1398082430.51.0.59207810702.issue21321@psf.upfronthosting.co.za> Message-ID: <1398752823.28.0.548808771878.issue21321@psf.upfronthosting.co.za> Anton Afanasyev added the comment: Hi Antoine, my test works for me. It can be either >>> a = [1, 2, 3] or >>> a = iter([1, 2, 3]) , no matter: both objects will be +1 referenced after taking >>> b = islice(a, 1) . My test failed without patch and passed with one. But your test is more straightforward, thanks. Attaching patches with your test. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 08:27:22 2014 From: report at bugs.python.org (Anton Afanasyev) Date: Tue, 29 Apr 2014 06:27:22 +0000 Subject: [issue21321] itertools.islice() doesn't release reference to the source iterator when the slice is exhausted In-Reply-To: <1398082430.51.0.59207810702.issue21321@psf.upfronthosting.co.za> Message-ID: <1398752842.31.0.909784242476.issue21321@psf.upfronthosting.co.za> Changes by Anton Afanasyev : Added file: http://bugs.python.org/file35086/issue21321_2.7_e3217efa6edd_4.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 08:27:51 2014 From: report at bugs.python.org (Anton Afanasyev) Date: Tue, 29 Apr 2014 06:27:51 +0000 Subject: [issue21321] itertools.islice() doesn't release reference to the source iterator when the slice is exhausted In-Reply-To: <1398082430.51.0.59207810702.issue21321@psf.upfronthosting.co.za> Message-ID: <1398752871.48.0.269298565899.issue21321@psf.upfronthosting.co.za> Changes by Anton Afanasyev : Added file: http://bugs.python.org/file35087/issue21321_3.4_8c8315bac6a8_4.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 08:28:30 2014 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 29 Apr 2014 06:28:30 +0000 Subject: [issue8776] Bytes version of sys.argv In-Reply-To: <1274357456.02.0.0768864678422.issue8776@psf.upfronthosting.co.za> Message-ID: <1398752910.78.0.197923762633.issue8776@psf.upfronthosting.co.za> Nick Coghlan added the comment: Makes sense to me. Assuming we eventually manage to resolve the POSIX locale issue, the bytes variant will become even less useful. ---------- resolution: later -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 08:29:47 2014 From: report at bugs.python.org (Donald Stufft) Date: Tue, 29 Apr 2014 06:29:47 +0000 Subject: [issue21305] PEP 466: update os.urandom In-Reply-To: <1397868674.52.0.918643592406.issue21305@psf.upfronthosting.co.za> Message-ID: <1398752987.71.0.283628305642.issue21305@psf.upfronthosting.co.za> Donald Stufft added the comment: One of the reasons the PEP was done the way it was done was it allowed you to write 2/3 compatible code without version checks. Enhancing that class won't land until 3.5 which is 18+ months away. Further more the os.urandom persistent FD's already exists and is a complete superset of functionality that a random.SystemRandom random would have. This conversation would have been a lot more useful when the PEP was being discussed on python-dev. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 08:34:32 2014 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 29 Apr 2014 06:34:32 +0000 Subject: [issue21379] StopIteration is silenced when raised by generator within context manager In-Reply-To: <1398719429.87.0.781789142964.issue21379@psf.upfronthosting.co.za> Message-ID: <1398753272.77.0.812255633599.issue21379@psf.upfronthosting.co.za> Nick Coghlan added the comment: This is expected behaviour - "raise StopIteration" in a generator is equivalent to "return", except it can occur inside a called function. The bug here is in the given context manager definition - it should be taking appropriate action if the "next" call failing is supposed to be treated as an error rather than termination of the generator. ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 09:06:25 2014 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 29 Apr 2014 07:06:25 +0000 Subject: [issue21305] PEP 466: update os.urandom In-Reply-To: <1398752987.71.0.283628305642.issue21305@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: Note that the discussion of this PEP *did* suffer from the "language summit effect" where folks that couldn't make it to the summit are missing some of the context. I believe I included all of the key motivating points in the PEP itself, but it's still not the same as being there from a "why take the risk?" perspective. Of the approved feature backports, this one was the most borderline, and as noted above, I think it could comfortably wait until 2.7.8. The SSL changes are most significant, followed by the constant time comparison function, and only then the other updates. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 09:48:00 2014 From: report at bugs.python.org (Tim Golden) Date: Tue, 29 Apr 2014 07:48:00 +0000 Subject: [issue18314] Have os.unlink remove junction points In-Reply-To: <1398750935.74.0.232556577851.issue18314@psf.upfronthosting.co.za> Message-ID: <535F5933.6050207@timgolden.me.uk> Tim Golden added the comment: Yes, now that the custom allocator / tracing stuff is in place: otherwise there's no way for custom allocation or tracing to occur. Please go ahead and rework the patch when you have the time. Also, since the setup of the reparse header is such an underdocumented nightmare, please add as much commentary as possible around the choice of allocations & offsets. I was reviewing your code with an eye on the various MSDN pages and examples and I still wasn't always able to follow your choices. (BTW I'm not convinced that the PyMem change was the problem since the PyMem_Raw* functions simply hand off to malloc/free unless there's a custom allocator. Unless of course the missing memset-0 was significant here). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 09:55:59 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 29 Apr 2014 07:55:59 +0000 Subject: [issue21377] PyBytes_Concat could try to concat in-place In-Reply-To: <1398714444.35.0.443659487134.issue21377@psf.upfronthosting.co.za> Message-ID: <1398758159.39.0.0243960747141.issue21377@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Tentative patch attached. The test suite still passes, but I'm not > sure if it actually exerts the new code path. A quick grep shows me that it should be exercised at least by Modules/_io/bufferedio.c. Otherwise, the way to test the C API is to add a function to Modules/_testcapi.c, and test that function from the relevant test file. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 09:58:13 2014 From: report at bugs.python.org (Ned Deily) Date: Tue, 29 Apr 2014 07:58:13 +0000 Subject: [issue21381] Python 3.4+ interpreter built on/with OS X 10.7 deployment target segfaults on 10.8+ In-Reply-To: <1398734858.53.0.489606157179.issue21381@psf.upfronthosting.co.za> Message-ID: <1398758293.07.0.621433750551.issue21381@psf.upfronthosting.co.za> Ned Deily added the comment: Yes, it should be possible to build all Pythons for all recent OS X deployment targets but, normally, the safest way is to build a specific deployment target on the same OS X version; that should avoid any possibility of inadvertently linking with new features not available on the older deployment target system. It is possible to use SDKs and tools from older versions of Xcode on newer systems to simulate building on an older system but that isn't foolproof. Also, keep in mind that the deployment target is a minimum deployment target. Pythons built with a deployment target of 10.n also work on 10.n+1 and generally 10.n+m, at least as long as there is no major compatibility break, like dropping support for running PPC architecture executables in 10.7. However, the problem you've found here is an exception to that general rule. The culprit appears to be the execution stack size increase at link time introduced by Issue18075 in b07ad4b5e349 for 3.4.0. With the stack size increased to 16MB, when Python is built on 10.7, it seems to work fine on 10.7 but, if the same executable is moved to 10.8 or 10.9, it segfaults early in initialization. The same behavior is observed with either debug or non-debug builds. When the same executable is run under gdb or lldb, the interpreter doesn't segfault. Likewise, the same behavior is seen when building on 10.8 or 10.9 and setting MACOSX_DEPLOYMENT_TARGET=10.7. (Also, building with Xcode 4.6.3 (the current 10.7 toolchain) on 10.9 makes no difference.) With dept target of 10.7, If the stack size increase in configure is commented out, #LINKFORSHARED="-Wl,-stack_size,1000000 $LINKFORSHARED" then builds with dept target of 10.7 succeed and all tests pass. In fact, at first glance it seemed that all tests passed with a dept target of 10.9 using the current Xcode 5.1.1 build tools so it's not clear whether the original problem reported in Issue18075 still exists. I'm puzzled by this one: thanks, Chris! We could certainly make the stack size increase conditional but it's odd that it only seems to be a problem with 10.7. Ronald (or anyone else): any ideas? ---------- nosy: +ronaldoussoren title: python build crash on Mavericht -> Python 3.4+ interpreter built on/with OS X 10.7 deployment target segfaults on 10.8+ versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 09:58:14 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 29 Apr 2014 07:58:14 +0000 Subject: [issue21037] add an AddressSanitizer build option In-Reply-To: <1395581927.59.0.22052744693.issue21037@psf.upfronthosting.co.za> Message-ID: <1398758293.99.0.303253903098.issue21037@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > But I'm not really familiar with the buildbot support, so if anyone > has a clue... I can add environment variables and configure options specific to a buildbot. Just tell me which ones (and which buildbot (preferably yours ? :-)). That said, it would be better if you first check said options work locally. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 10:03:36 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 29 Apr 2014 08:03:36 +0000 Subject: [issue20951] SSLSocket.send() returns 0 for non-blocking socket In-Reply-To: <1395004591.32.0.211111410214.issue20951@psf.upfronthosting.co.za> Message-ID: <3gHwN75KJcz7LjQ@mail.python.org> Roundup Robot added the comment: New changeset 3cf067049211 by Antoine Pitrou in branch 'default': Issue #20951: SSLSocket.send() now raises either SSLWantReadError or SSLWantWriteError on a non-blocking socket if the operation would block. Previously, it would return 0. http://hg.python.org/cpython/rev/3cf067049211 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 10:06:07 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 29 Apr 2014 08:06:07 +0000 Subject: [issue20951] SSLSocket.send() returns 0 for non-blocking socket In-Reply-To: <1395004591.32.0.211111410214.issue20951@psf.upfronthosting.co.za> Message-ID: <3gHwR23zCZz7LjQ@mail.python.org> Roundup Robot added the comment: New changeset b0f6983d63df by Antoine Pitrou in branch 'default': Add porting note for issue #20951. http://hg.python.org/cpython/rev/b0f6983d63df ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 10:06:41 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 29 Apr 2014 08:06:41 +0000 Subject: [issue20951] SSLSocket.send() returns 0 for non-blocking socket In-Reply-To: <1395004591.32.0.211111410214.issue20951@psf.upfronthosting.co.za> Message-ID: <1398758801.26.0.608633131587.issue20951@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Patch finally committed. Thanks Nikolaus! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 10:17:16 2014 From: report at bugs.python.org (rsevcan) Date: Tue, 29 Apr 2014 08:17:16 +0000 Subject: [issue21382] Signal module doesnt raises ValueError Exception Message-ID: <1398759436.39.0.420418396293.issue21382@psf.upfronthosting.co.za> New submission from rsevcan: signal.signal() built-in function doesnt throws a ValueError exception in Windows when is called with a different signal than SIGABRT, SIGFPE, SIGILL, SIGINT, SIGSEGV, or SIGTERM, as it is written in the documentation. https://docs.python.org/2/library/signal.html#signal.signal https://docs.python.org/3/library/signal.html#signal.signal It throws an AttributeError Exception >>> import signal >>> import sys >>> sys.platform 'win32' >>> signal.signal(signal.SIGPIPE, lambda signum, frame: sys.exit(1)) Traceback (most recent call last): File "", line 1, in AttributeError: 'module' object has no attribute 'SIGPIPE' >>> Regards ---------- assignee: docs at python components: Documentation messages: 217486 nosy: docs at python, rsevcan priority: normal severity: normal status: open title: Signal module doesnt raises ValueError Exception type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 10:22:51 2014 From: report at bugs.python.org (Simon Zack) Date: Tue, 29 Apr 2014 08:22:51 +0000 Subject: [issue4709] Mingw-w64 and python on windows x64 In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za> Message-ID: <1398759771.31.0.666353655597.issue4709@psf.upfronthosting.co.za> Simon Zack added the comment: The problem is still present in python 3.4 with mingw gcc 4.8.2. I was having trouble with compiling radare2's python swig bindings. The solution described here: http://ascend4.org/Setting_up_a_MinGW-w64_build_environment#Setup_Python_for_compilation_of_extensions also fixes my problem when using generated dlls. ---------- nosy: +simonzack _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 10:25:54 2014 From: report at bugs.python.org (=?utf-8?q?Kim_Gr=C3=A4sman?=) Date: Tue, 29 Apr 2014 08:25:54 +0000 Subject: [issue18314] Have os.unlink remove junction points In-Reply-To: <1372335321.1.0.479247042071.issue18314@psf.upfronthosting.co.za> Message-ID: <1398759954.71.0.451391569765.issue18314@psf.upfronthosting.co.za> Kim Gr?sman added the comment: > Also, since the setup of the reparse header is such an underdocumented > nightmare, please add as much commentary as possible around the choice > of allocations & offsets. I'll try. It might turn into a novel. > (BTW I'm not convinced that the PyMem change was the problem since > the PyMem_Raw* functions simply hand off to malloc/free unless > there's a custom allocator. > Unless of course the missing memset-0 was significant here). I think it might be, there was a message in the log that DeviceIoControl failed: stty: standard input: Inappropriate ioctl for device That could be attributed to garbage in the buffer. I'll be back with a revised patch, and we can work from there. Thanks for your help! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 10:27:24 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 29 Apr 2014 08:27:24 +0000 Subject: [issue20951] SSLSocket.send() returns 0 for non-blocking socket In-Reply-To: <1395004591.32.0.211111410214.issue20951@psf.upfronthosting.co.za> Message-ID: <3gHwvb5fcVz7Ljv@mail.python.org> Roundup Robot added the comment: New changeset 7f50e1836ddb by Antoine Pitrou in branch 'default': Fix failure in test_poplib after issue #20951. http://hg.python.org/cpython/rev/7f50e1836ddb ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 10:27:25 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 29 Apr 2014 08:27:25 +0000 Subject: [issue21057] TextIOWrapper does not support reading bytearrays or memoryviews In-Reply-To: <1395720869.89.0.455515257207.issue21057@psf.upfronthosting.co.za> Message-ID: <3gHwvc3x3zz7Ljv@mail.python.org> Roundup Robot added the comment: New changeset 2a1d63f09560 by Antoine Pitrou in branch 'default': Issue #21057: TextIOWrapper now allows the underlying binary stream's read() or read1() method to return an arbitrary bytes-like object (such as a memoryview). http://hg.python.org/cpython/rev/2a1d63f09560 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 10:27:55 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 29 Apr 2014 08:27:55 +0000 Subject: [issue21057] TextIOWrapper does not support reading bytearrays or memoryviews In-Reply-To: <1395720869.89.0.455515257207.issue21057@psf.upfronthosting.co.za> Message-ID: <1398760075.89.0.237297871708.issue21057@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thank you, I've committed tha patch to 3.5. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 10:28:38 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 29 Apr 2014 08:28:38 +0000 Subject: [issue20951] SSLSocket.send() returns 0 for non-blocking socket In-Reply-To: <1395004591.32.0.211111410214.issue20951@psf.upfronthosting.co.za> Message-ID: <1398760118.13.0.441776415333.issue20951@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok, there was a failure in test_poplib when run with -unetwork, I fixed it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 10:36:34 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 29 Apr 2014 08:36:34 +0000 Subject: [issue21375] Fix and test overflow behavior in the C version of heapq In-Reply-To: <1398707994.45.0.696035798055.issue21375@psf.upfronthosting.co.za> Message-ID: <1398760594.05.0.853981344899.issue21375@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Attaching a fix. I can't think of a way to test this without an array of sys.maxsize. ---------- keywords: +patch Added file: http://bugs.python.org/file35088/fix_overflow.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 10:37:46 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 29 Apr 2014 08:37:46 +0000 Subject: [issue21305] PEP 466: update os.urandom In-Reply-To: Message-ID: STINNER Victor added the comment: > The problem is AFAICT there's currently no way to get a file > descriptor to the underlying /dev/urandom (and I don't know how it > works on Windows). We can reimplement os.urandom in SystemRandom on UNIX to keep the file (fd) open. The code is very simple, basically it's just a call to file.read(n). Adding a randbytes() method in Python 3.5 would be nice. The io module can handle boring things for you, like calling read in a loop until you get enough bytes and handle InterruptError. Except if you would prefer to use os.read or FileIO.read to avoid readahead. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 10:39:22 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 29 Apr 2014 08:39:22 +0000 Subject: [issue21321] itertools.islice() doesn't release reference to the source iterator when the slice is exhausted In-Reply-To: <1398082430.51.0.59207810702.issue21321@psf.upfronthosting.co.za> Message-ID: <1398760762.35.0.930166917982.issue21321@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thanks. Could you also add a test for the islice_reduce additions? Or is it already tested? I suspect there's a reference leak there: after calling PyObject_GetIter, you should always Py_DECREF(empty_list). Also, with the "O" code, Py_BuildValue will take a new reference to empty_it, so you should use the "N" code instead. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 10:41:12 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 29 Apr 2014 08:41:12 +0000 Subject: [issue21305] PEP 466: update os.urandom In-Reply-To: Message-ID: STINNER Victor added the comment: > (and I don't know how it > works on Windows). On Windows, the OS CryptoAPI is used and a handle is kept open between calls to os.urandom. On Windows, I don't think that it's a an issue to keep a handle open. Handle are not sequential numbers and users don't manipulate them directly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 10:42:27 2014 From: report at bugs.python.org (Ned Deily) Date: Tue, 29 Apr 2014 08:42:27 +0000 Subject: [issue21383] "make touch" fails when the build directory is not the source directory Message-ID: <1398760947.89.0.691766045615.issue21383@psf.upfronthosting.co.za> New submission from Ned Deily: make touch hg --config extensions.touch=Tools/hg/hgtouch.py touch -v *** failed to import extension touch from Tools/hg/hgtouch.py: [Errno 2] No such file or directory: 'Tools/hg/hgtouch.py' hg: unknown command 'touch' ---------- components: Build messages: 217497 nosy: ned.deily priority: normal severity: normal status: open title: "make touch" fails when the build directory is not the source directory versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 10:45:16 2014 From: report at bugs.python.org (Ned Deily) Date: Tue, 29 Apr 2014 08:45:16 +0000 Subject: [issue21383] "make touch" fails when the build directory is not the source directory In-Reply-To: <1398760947.89.0.691766045615.issue21383@psf.upfronthosting.co.za> Message-ID: <1398761116.7.0.110637830886.issue21383@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file35089/issue21383_make_touch.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 10:45:21 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 29 Apr 2014 08:45:21 +0000 Subject: [issue21377] PyBytes_Concat could try to concat in-place In-Reply-To: <1398758159.39.0.0243960747141.issue21377@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: If I remember correctly, ceval.c has an optmisation for str += str even if the refcount is 2. Do we need to implement it or suggest to use bytearray or b''.join() instead? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 10:46:06 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 29 Apr 2014 08:46:06 +0000 Subject: [issue21377] PyBytes_Concat could try to concat in-place In-Reply-To: Message-ID: <1398761164.2305.0.camel@fsol> Antoine Pitrou added the comment: > If I remember correctly, ceval.c has an optmisation for str += str even if > the refcount is 2. Do we need to implement it or suggest to use bytearray > or b''.join() instead? The latter, IMO. This issue is about the C API _PyBytes_Concat. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 10:46:51 2014 From: report at bugs.python.org (Ned Deily) Date: Tue, 29 Apr 2014 08:46:51 +0000 Subject: [issue17861] put opcode information in one place In-Reply-To: <1367162089.6.0.986391601417.issue17861@psf.upfronthosting.co.za> Message-ID: <1398761211.04.0.876521963169.issue17861@psf.upfronthosting.co.za> Ned Deily added the comment: Martin, it could if "make touch" worked when building outside of the source directory (Issue21383). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 10:59:41 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 29 Apr 2014 08:59:41 +0000 Subject: [issue21384] Windows: Make handle non inheritable by default Message-ID: <1398761981.56.0.701422046655.issue21384@psf.upfronthosting.co.za> New submission from STINNER Victor: The PEP 446 was implemented in Python 3.4. All file descriptors are now created non inheritable. The implementation was not finished on Windows, handles may be created inheritable. The Python code should be audoted for that. For example, hCryptProv in Python/random.c is inheritable or not? ---------- components: Windows messages: 217501 nosy: haypo, sbt, tim.golden priority: normal severity: normal status: open title: Windows: Make handle non inheritable by default versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 11:00:10 2014 From: report at bugs.python.org (Antti Haapala) Date: Tue, 29 Apr 2014 09:00:10 +0000 Subject: [issue21385] Compiling modified AST crashes on debug build unless linenumbering discarded Message-ID: <1398762010.89.0.992252148712.issue21385@psf.upfronthosting.co.za> New submission from Antti Haapala: We had had problems with our web service occasionally hanging and performing poorly, and as we didn't have much clue about the cause of these, we decided to continuously run our staging build under debug enabled python 3.4, and then attaching gdb as needed. To much dismay we found out that our code generating code that builds AST trees and then compiles them to modules is dumping cores on the debug version. The assertion is the much discussed "linenumbers must grow monotonically" at http://hg.python.org/cpython/file/04f714765c13/Python/compile.c#l3969 In our case, the AST is generated from a HTML template with embedded python parts; as we could approximately point out much of the corresponding code in the source template, we decided to reuse the linenumbers in AST, and things seemed to work quite nicely and usually we could get usable tracebacks too. Under debug build, however, as the ordering of some constructs in the source language are different from python, we need to discard *all* linenumbers and only after then use fix_missing_locations, and thus get completely unusable traces from these parts of code, all happening on line 1. Just using fix_missing_locations does not work. Likewise the rules for which parts of the tree should come in which order in the lnotab is quite hard to deduce. It seems to me that when the lnotab was created, no one even had in mind that there would be an actually useful AST module that would be used for code generation. Considering that there have been other calls for breaking the correspondence of bytecode addresses to monotonically growing linenumbers, I want to reopen the discussion about changing the lnotab structures now to allow arbitrary mapping of source code locations to bytecode, and especially about the need for this assertion in the debug builds at all. Attached is an example of code that appends a function to an existing module syntax tree, run under python*-dbg it dumps the core with "Python/compile.c:nnnn: assemble_lnotab: Assertion `d_lineno >= 0' failed." Ofc in this simple case it is easy to just modify the linenumbers so that function "bar" would come after "foo", however in some cases it is hard to know the actual rules; fix_missing_locations does not do this right at all. I am also pretty sure most of the existing code that combine parsed and generated ASTs and then compile the resulting trees also would fail that assert, but no one is ever running their code under debug builds. ---------- components: Interpreter Core files: astlinenotest.py messages: 217502 nosy: Ztane priority: normal severity: normal status: open title: Compiling modified AST crashes on debug build unless linenumbering discarded type: crash versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file35090/astlinenotest.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 11:41:45 2014 From: report at bugs.python.org (Giampaolo Rodola') Date: Tue, 29 Apr 2014 09:41:45 +0000 Subject: [issue1284316] Win32: Security problem with default installation directory Message-ID: <1398764505.93.0.906521378421.issue1284316@psf.upfronthosting.co.za> Changes by Giampaolo Rodola' : ---------- nosy: +giampaolo.rodola versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 11:55:51 2014 From: report at bugs.python.org (Anton Afanasyev) Date: Tue, 29 Apr 2014 09:55:51 +0000 Subject: [issue21321] itertools.islice() doesn't release reference to the source iterator when the slice is exhausted In-Reply-To: <1398082430.51.0.59207810702.issue21321@psf.upfronthosting.co.za> Message-ID: <1398765351.57.0.543271229588.issue21321@psf.upfronthosting.co.za> Anton Afanasyev added the comment: Hi Antoine, oops you are right about leaks: fixed them in new attached patch. As for testing changes in "reduce()": they are already covered by "self.pickletest(islice(range(100), *args))". Function "pickletest()" covers case for pickle dumping/loading of exhausted iterator. ---------- Added file: http://bugs.python.org/file35091/issue21321_3.4_8c8315bac6a8_5.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 12:06:43 2014 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Tue, 29 Apr 2014 10:06:43 +0000 Subject: [issue7105] weak dict iterators are fragile because of unpredictable GC runs In-Reply-To: <1255282166.4.0.13882602695.issue7105@psf.upfronthosting.co.za> Message-ID: <1398766003.53.0.982038324643.issue7105@psf.upfronthosting.co.za> Changes by Kristj?n Valur J?nsson : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 12:12:04 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 29 Apr 2014 10:12:04 +0000 Subject: [issue21321] itertools.islice() doesn't release reference to the source iterator when the slice is exhausted In-Reply-To: <1398082430.51.0.59207810702.issue21321@psf.upfronthosting.co.za> Message-ID: <1398766324.58.0.790691286948.issue21321@psf.upfronthosting.co.za> Antoine Pitrou added the comment: For the record, checks such as: self.assertEqual(wr() is None, False) are better written: self.assertIsNotNone(wr()) No need to upload a new patch, I'm gonna make the change while committing :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 12:14:59 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 29 Apr 2014 10:14:59 +0000 Subject: [issue21321] itertools.islice() doesn't release reference to the source iterator when the slice is exhausted In-Reply-To: <1398082430.51.0.59207810702.issue21321@psf.upfronthosting.co.za> Message-ID: <3gHzHk2Z9zz7LjQ@mail.python.org> Roundup Robot added the comment: New changeset b795105db23a by Antoine Pitrou in branch '3.4': Issue #21321: itertools.islice() now releases the reference to the source iterator when the slice is exhausted. http://hg.python.org/cpython/rev/b795105db23a New changeset a627b3e3c9c8 by Antoine Pitrou in branch 'default': Issue #21321: itertools.islice() now releases the reference to the source iterator when the slice is exhausted. http://hg.python.org/cpython/rev/a627b3e3c9c8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 12:15:48 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 29 Apr 2014 10:15:48 +0000 Subject: [issue21321] itertools.islice() doesn't release reference to the source iterator when the slice is exhausted In-Reply-To: <1398082430.51.0.59207810702.issue21321@psf.upfronthosting.co.za> Message-ID: <1398766548.12.0.374866395851.issue21321@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Patch committed, thank you! If you want to provide a patch for 2.7, please say so, otherwise I'll close the issue. ---------- resolution: -> fixed stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 12:21:37 2014 From: report at bugs.python.org (Giampaolo Rodola') Date: Tue, 29 Apr 2014 10:21:37 +0000 Subject: [issue1284316] Win32: Security problem with default installation directory Message-ID: <1398766897.45.0.482780376458.issue1284316@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: If on one hand I agree that Python being in C:\PythonXX is not optimal for all the reasons which have been mentioned so far, changing such an old established aspect of the interpreter would be too much disruptive as a change. To say one, being that on Windows 'python' is not recognized as a command, some folks rely on it simply living in C:\Python** and make that assumption into their scripts (I did exactly this in psutil: https://code.google.com/p/psutil/source/browse/make.bat?name=release-2.1.0#23). I agree with what Martin says here: http://bugs.python.org/issue1284316#msg26236. We should let Python live in C\:PythonXX and just fix permissions during installation so that when the installation completes C:\PythonXX will not be writable by limited users. If this introduces a performance issue because the pyd files cannot be created afterwards then simply create pyd files as part of the installation process (this should be done if "install for all users" option is checked). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 12:21:38 2014 From: report at bugs.python.org (Anton Afanasyev) Date: Tue, 29 Apr 2014 10:21:38 +0000 Subject: [issue21321] itertools.islice() doesn't release reference to the source iterator when the slice is exhausted In-Reply-To: <1398082430.51.0.59207810702.issue21321@psf.upfronthosting.co.za> Message-ID: <1398766898.11.0.0324721320227.issue21321@psf.upfronthosting.co.za> Anton Afanasyev added the comment: Antoine, not sure about 2.7. The issue first arose for me at Python 2.7, so I would prefer "issue21321_2.7_e3217efa6edd_4.diff" patch be applied. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 12:26:59 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 29 Apr 2014 10:26:59 +0000 Subject: [issue21321] itertools.islice() doesn't release reference to the source iterator when the slice is exhausted In-Reply-To: <1398082430.51.0.59207810702.issue21321@psf.upfronthosting.co.za> Message-ID: <3gHzYb1ssTz7LjQ@mail.python.org> Roundup Robot added the comment: New changeset 8ee76e1b5aa6 by Antoine Pitrou in branch '2.7': Issue #21321: itertools.islice() now releases the reference to the source iterator when the slice is exhausted. http://hg.python.org/cpython/rev/8ee76e1b5aa6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 12:27:27 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 29 Apr 2014 10:27:27 +0000 Subject: [issue21321] itertools.islice() doesn't release reference to the source iterator when the slice is exhausted In-Reply-To: <1398082430.51.0.59207810702.issue21321@psf.upfronthosting.co.za> Message-ID: <1398767247.29.0.0357175328526.issue21321@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok, then I've committed to 2.7 too. Thank you very much for contributing! ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 13:35:35 2014 From: report at bugs.python.org (Roger Luethi) Date: Tue, 29 Apr 2014 11:35:35 +0000 Subject: [issue21386] ipaddress.IPv4Address.is_global not implemented Message-ID: <1398771335.62.0.997727403803.issue21386@psf.upfronthosting.co.za> New submission from Roger Luethi: Lib/ipaddress.py does not implement is_global for IPv4Address, in contrast to the documentation which states for IPv4Address.is_global: "True if the address is allocated for public networks." A patch like the one attached to this report should fix that. ---------- components: Library (Lib) files: ipv4addr_global.diff keywords: patch messages: 217511 nosy: rluethi priority: normal severity: normal status: open title: ipaddress.IPv4Address.is_global not implemented versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file35092/ipv4addr_global.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 13:55:14 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 29 Apr 2014 11:55:14 +0000 Subject: [issue1820] Enhance Object/structseq.c to match namedtuple and tuple api In-Reply-To: <1200284428.58.0.762384814897.issue1820@psf.upfronthosting.co.za> Message-ID: <1398772514.2.0.0498286918328.issue1820@psf.upfronthosting.co.za> Stefan Krah added the comment: Okay, if no one else wants this, I'll go ahead with the _fields part. Andrew, could you sign a contributor agreement? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 13:55:37 2014 From: report at bugs.python.org (Evgeniy Stepanov) Date: Tue, 29 Apr 2014 11:55:37 +0000 Subject: [issue21387] Memory leaks when embedded interpreter is reinitialized Message-ID: <1398772537.74.0.909134635776.issue21387@psf.upfronthosting.co.za> New submission from Evgeniy Stepanov: Following https://docs.python.org/2/c-api/init.html#Py_Finalize, I'm reinitializing embedded python interpreter multiple time in one process. #include void f() { Py_Initialize(); PyRun_SimpleString("from time import time,ctime\n" "import datetime\n" "print 'Today is',ctime(time())\n"); Py_Finalize(); } int main(void) { for (int i = 0; i < 30; ++i) f(); return 0; } I see 2 sources of memory leaks: * _once_registry is never teared down. ==20144==ERROR: LeakSanitizer: detected memory leaks Direct leak of 8120 byte(s) in 29 object(s) allocated from: #0 0x4a3e38 in malloc /code/llvm/build0/../projects/compiler-rt/lib/asan/asan_malloc_linux.cc:75 #1 0x4e1524 in _PyObject_GC_Malloc build/Python-2.7.6/Modules/gcmodule.c:1499 #2 0x4e16ff in _PyObject_GC_New build/Python-2.7.6/Modules/gcmodule.c:1521 #3 0x57e581 in PyDict_New build/Python-2.7.6/Objects/dictobject.c:277 #4 0x62b9a7 in _PyWarnings_Init build/Python-2.7.6/Python/_warnings.c:898 #5 0x4c2985 in Py_InitializeEx build/Python-2.7.6/Python/pythonrun.c:254 #6 0x4c22a4 in f() build/Python-2.7.6/1.cc:4 #7 0x4c22a4 in main build/Python-2.7.6/1.cc:14 * datetime module creates a bunch of objects in its initialization function and never destroys them Direct leak of 8120 byte(s) in 29 object(s) allocated from: #0 0x4a3e38 in malloc /code/llvm/build0/../projects/compiler-rt/lib/asan/asan_malloc_linux.cc:75 #1 0x4e1524 in _PyObject_GC_Malloc build/Python-2.7.6/Modules/gcmodule.c:1499 #2 0x4e16ff in _PyObject_GC_New build/Python-2.7.6/Modules/gcmodule.c:1521 #3 0x57e581 in PyDict_New build/Python-2.7.6/Objects/dictobject.c:277 #4 0x6cb976 in PyErr_NewException build/Python-2.7.6/Python/errors.c:577 #5 0x757227 in initzipimport build/Python-2.7.6/./Modules/zipimport.c:1235 #6 0x6e5797 in init_builtin build/Python-2.7.6/Python/import.c:1999 #7 0x6e158d in load_module build/Python-2.7.6/Python/import.c:1928 #8 0x6e6919 in import_submodule build/Python-2.7.6/Python/import.c:2700 #9 0x6e5ac7 in load_next build/Python-2.7.6/Python/import.c:2515 #10 0x6e036c in import_module_level build/Python-2.7.6/Python/import.c:2224 #11 0x6e036c in PyImport_ImportModuleLevel build/Python-2.7.6/Python/import.c:2288 #12 0x671e6f in builtin___import__ build/Python-2.7.6/Python/bltinmodule.c:49 #13 0x502b40 in PyObject_Call build/Python-2.7.6/Objects/abstract.c:2529 #14 0x502e82 in call_function_tail build/Python-2.7.6/Objects/abstract.c:2561 #15 0x502e82 in PyObject_CallFunction build/Python-2.7.6/Objects/abstract.c:2585 #16 0x6df7b0 in PyImport_Import build/Python-2.7.6/Python/import.c:2886 #17 0x6db9a7 in PyImport_ImportModule build/Python-2.7.6/Python/import.c:2129 #18 0x6db9a7 in _PyImportHooks_Init build/Python-2.7.6/Python/import.c:239 #19 0x4c287f in Py_InitializeEx build/Python-2.7.6/Python/pythonrun.c:248 #20 0x4c22a4 in f() build/Python-2.7.6/1.cc:4 #21 0x4c22a4 in main build/Python-2.7.6/1.cc:14 ---------- components: Extension Modules, Interpreter Core messages: 217513 nosy: Evgeniy.Stepanov priority: normal severity: normal status: open title: Memory leaks when embedded interpreter is reinitialized versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 13:56:03 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 29 Apr 2014 11:56:03 +0000 Subject: [issue20230] structseq types should expose _fields In-Reply-To: <1389575574.46.0.402404595733.issue20230@psf.upfronthosting.co.za> Message-ID: <1398772563.45.0.188517478653.issue20230@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- resolution: -> duplicate stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 13:58:18 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 29 Apr 2014 11:58:18 +0000 Subject: [issue20230] structseq types should expose _fields In-Reply-To: <1389575574.46.0.402404595733.issue20230@psf.upfronthosting.co.za> Message-ID: <1398772698.1.0.765091370286.issue20230@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- superseder: -> Enhance Object/structseq.c to match namedtuple and tuple api _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 14:14:55 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 29 Apr 2014 12:14:55 +0000 Subject: [issue19001] test_gdb fails on Fedora buildbot In-Reply-To: <1378841773.14.0.068562621875.issue19001@psf.upfronthosting.co.za> Message-ID: <1398773695.79.0.244584927567.issue19001@psf.upfronthosting.co.za> Stefan Krah added the comment: Since Fedora 16 is EOL, let's close this. ---------- resolution: -> out of date stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 14:24:41 2014 From: report at bugs.python.org (Eric V. Smith) Date: Tue, 29 Apr 2014 12:24:41 +0000 Subject: [issue21386] ipaddress.IPv4Address.is_global not implemented In-Reply-To: <1398771335.62.0.997727403803.issue21386@psf.upfronthosting.co.za> Message-ID: <1398774281.65.0.312428591393.issue21386@psf.upfronthosting.co.za> Changes by Eric V. Smith : ---------- nosy: +eric.smith, ncoghlan, pmoody _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 14:42:31 2014 From: report at bugs.python.org (Tim Golden) Date: Tue, 29 Apr 2014 12:42:31 +0000 Subject: [issue21138] mimetypes.MimeType UnicodeDecodeError In-Reply-To: <1396489160.22.0.410580562036.issue21138@psf.upfronthosting.co.za> Message-ID: <1398775351.33.0.0392126115232.issue21138@psf.upfronthosting.co.za> Tim Golden added the comment: Fixed by issue9291 ---------- resolution: -> duplicate stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 14:45:37 2014 From: report at bugs.python.org (Jason R. Coombs) Date: Tue, 29 Apr 2014 12:45:37 +0000 Subject: [issue1284316] Win32: Security problem with default installation directory Message-ID: <1398775537.77.0.540661549705.issue1284316@psf.upfronthosting.co.za> Jason R. Coombs added the comment: I still disagree. If the preferable place for Python to be installed is not in the root (and I fervently feel so), then there could be a transitional approach to move it to the appropriate place, such as creating symbolic links from the legacy destinations (as an opt-out option). Still, as Martin said, a change to the default install location would require a PEP that would have to address these concerns. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 15:17:28 2014 From: report at bugs.python.org (dellair jie) Date: Tue, 29 Apr 2014 13:17:28 +0000 Subject: [issue21124] _struct module compilation error under Cygwin 1.7.17 on Python 3.4 In-Reply-To: <1396363951.96.0.324613047949.issue21124@psf.upfronthosting.co.za> Message-ID: <1398777448.43.0.437901410457.issue21124@psf.upfronthosting.co.za> dellair jie added the comment: Hello masamoto, The patch you provided works quite well. The build passed and Python calls are successfully. Please let me know what else you need me to test in order to have the patch accepted or else feel free to close it with Resolution Fixed. Thanks, Dellair ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 15:37:24 2014 From: report at bugs.python.org (dellair jie) Date: Tue, 29 Apr 2014 13:37:24 +0000 Subject: [issue21085] compile error Python3.3 on Cygwin In-Reply-To: <1396019829.85.0.386935527155.issue21085@psf.upfronthosting.co.za> Message-ID: <1398778644.19.0.332248201219.issue21085@psf.upfronthosting.co.za> dellair jie added the comment: Finally got it compiled on Cygwin! :) Victor, I am still having issue with the "make test" on Cygwin, hence can only do some manual testing: Output: >>> info = signal.sigwaitinfo({signal.SIGINT}) ^C >>> >>> info = signal.struct_siginfo((2, 128, 0, 0, 0, 3)) Traceback (most recent call last): File "", line 1, in TypeError: signal.struct_siginfo() takes an at least 7-sequence (6-sequence given) >>> info = signal.struct_siginfo((2, 128, 0, 0, 0, 3, 0)) Traceback (most recent call last): File "", line 1, in TypeError: signal.struct_siginfo() takes an at most 6-sequence (7-sequence given) >>> help(signal.struct_siginfo) | ---------------------------------------------------------------------- | Data descriptors defined here: | | si_code | signal code | | si_errno | errno associated with this signal | | si_pid | sending process ID | | si_signo | signal number | | si_status | exit value or signal | | si_uid | real user ID of sending process | | ---------------------------------------------------------------------- Feel free to let me know if more testing is required. Br, Dellair ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 15:39:31 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 29 Apr 2014 13:39:31 +0000 Subject: [issue21388] decimal.InvalidContext is unused Message-ID: <1398778771.07.0.438455770103.issue21388@psf.upfronthosting.co.za> New submission from Stefan Krah: We could remove decimal.InvalidContext, which is completely unused both in decimal.py and _decimal. ---------- messages: 217519 nosy: mark.dickinson, rhettinger, skrah priority: normal severity: normal status: open title: decimal.InvalidContext is unused type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 16:47:55 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 29 Apr 2014 14:47:55 +0000 Subject: [issue17386] Bring Doc/make.bat as close to Doc/Makefile as possible In-Reply-To: <1362781994.31.0.121984055749.issue17386@psf.upfronthosting.co.za> Message-ID: <3gJ5Lf4thVz7Ljw@mail.python.org> Roundup Robot added the comment: New changeset c75a2282166f by Zachary Ware in branch '3.4': Issue #17386: List the 'htmlview' target in the Doc/Makefile help output. http://hg.python.org/cpython/rev/c75a2282166f New changeset c378c67c4170 by Zachary Ware in branch '3.4': Issue #17386: Update Doc/README.txt to list all targets http://hg.python.org/cpython/rev/c378c67c4170 New changeset a172f26195f6 by Zachary Ware in branch '3.4': Issue #17386: Expand Doc/make.bat to be much more similar to Doc/Makefile http://hg.python.org/cpython/rev/a172f26195f6 New changeset 2b2577d79e80 by Zachary Ware in branch 'default': Closes #17386: Merge with 3.4 http://hg.python.org/cpython/rev/2b2577d79e80 ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 17:11:32 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 29 Apr 2014 15:11:32 +0000 Subject: [issue19630] marshal.dump cannot write to temporary file In-Reply-To: <1384675790.16.0.0477801542512.issue19630@psf.upfronthosting.co.za> Message-ID: <3gJ5sv4z65z7LjQ@mail.python.org> Roundup Robot added the comment: New changeset 0f6bdc2b0e38 by Tim Golden in branch '2.7': Issue #19630 Emphasise that the file parameter to marshal.dump must be a real file object http://hg.python.org/cpython/rev/0f6bdc2b0e38 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 17:12:34 2014 From: report at bugs.python.org (Tim Golden) Date: Tue, 29 Apr 2014 15:12:34 +0000 Subject: [issue19630] marshal.dump cannot write to temporary file In-Reply-To: <1384675790.16.0.0477801542512.issue19630@psf.upfronthosting.co.za> Message-ID: <1398784354.94.0.566080411949.issue19630@psf.upfronthosting.co.za> Tim Golden added the comment: I updated the docs to emphasise that the file parameter to marshal.dump must be a real file, not a wrapper. ---------- assignee: -> tim.golden status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 17:22:01 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 29 Apr 2014 15:22:01 +0000 Subject: [issue21040] socketserver: use selectors module In-Reply-To: <1395605825.75.0.216216542224.issue21040@psf.upfronthosting.co.za> Message-ID: <1398784920.99.0.660786254531.issue21040@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Shouldn't this issue be closed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 17:31:11 2014 From: report at bugs.python.org (Zachary Ware) Date: Tue, 29 Apr 2014 15:31:11 +0000 Subject: [issue21314] Document '/' in signatures In-Reply-To: <1397988439.5.0.703056699862.issue21314@psf.upfronthosting.co.za> Message-ID: <1398785471.93.0.723814397563.issue21314@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- keywords: +easy stage: -> needs patch status: -> open type: -> enhancement versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 17:34:42 2014 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Tue, 29 Apr 2014 15:34:42 +0000 Subject: [issue12916] Add inspect.splitdoc In-Reply-To: <1315326747.38.0.43030903994.issue12916@psf.upfronthosting.co.za> Message-ID: <1398785682.37.0.0908919633838.issue12916@psf.upfronthosting.co.za> St?phane Wirtel added the comment: Hi all, Here is a new version of the patch, please, keep me informed and I think I have to modify some parts, but give me your feedback. Thanks ---------- Added file: http://bugs.python.org/file35093/issue12916-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 17:35:16 2014 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 29 Apr 2014 15:35:16 +0000 Subject: [issue21388] decimal.InvalidContext is unused In-Reply-To: <1398778771.07.0.438455770103.issue21388@psf.upfronthosting.co.za> Message-ID: <1398785716.15.0.98901624027.issue21388@psf.upfronthosting.co.za> Mark Dickinson added the comment: It's part of the specification, though. For me, that's a good enough reason to keep it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 17:37:41 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 29 Apr 2014 15:37:41 +0000 Subject: [issue21040] socketserver: use selectors module In-Reply-To: <1395605825.75.0.216216542224.issue21040@psf.upfronthosting.co.za> Message-ID: <1398785861.05.0.455129991383.issue21040@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 18:17:16 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Tue, 29 Apr 2014 16:17:16 +0000 Subject: [issue21316] mark test_devpoll to be meaningful only for Solaris In-Reply-To: <1398019012.76.0.381361357153.issue21316@psf.upfronthosting.co.za> Message-ID: <1398788236.33.0.385638023823.issue21316@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- assignee: -> jcea nosy: +jcea title: mark test_devpoll to be meaningfull only for Solaris -> mark test_devpoll to be meaningful only for Solaris versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 18:19:14 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 29 Apr 2014 16:19:14 +0000 Subject: [issue21316] mark test_devpoll to be meaningful only for Solaris In-Reply-To: <1398019012.76.0.381361357153.issue21316@psf.upfronthosting.co.za> Message-ID: <3gJ7N20rn4z7Ljd@mail.python.org> Roundup Robot added the comment: New changeset cc2345e6e9ff by Jesus Cea in branch '3.4': Closes issue #21316: mark test_devpoll to be meaningfull only for Solaris http://hg.python.org/cpython/rev/cc2345e6e9ff New changeset 825c67196aac by Jesus Cea in branch 'default': MERGE: Closes issue #21316: mark test_devpoll to be meaningfull only for Solaris http://hg.python.org/cpython/rev/825c67196aac ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 18:20:09 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Tue, 29 Apr 2014 16:20:09 +0000 Subject: [issue21316] mark test_devpoll to be meaningful only for Solaris In-Reply-To: <1398019012.76.0.381361357153.issue21316@psf.upfronthosting.co.za> Message-ID: <1398788409.63.0.71056816717.issue21316@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- resolution: -> fixed stage: -> resolved status: open -> closed type: enhancement -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 18:21:13 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Tue, 29 Apr 2014 16:21:13 +0000 Subject: [issue21316] mark test_devpoll to be meaningful only for Solaris In-Reply-To: <1398019012.76.0.381361357153.issue21316@psf.upfronthosting.co.za> Message-ID: <1398788473.61.0.134011972866.issue21316@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Thanks for the head-up!!. Can you compile new version and try it out?. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 18:26:17 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 29 Apr 2014 16:26:17 +0000 Subject: [issue21374] DecimalTuple.__module__ is set to _frozen_importlib In-Reply-To: <1398700826.27.0.585241892269.issue21374@psf.upfronthosting.co.za> Message-ID: <3gJ7X91b5jz7LjT@mail.python.org> Roundup Robot added the comment: New changeset bf64a5f7c1af by Stefan Krah in branch 'default': Issue #21374: Fix pickling of DecimalTuple. http://hg.python.org/cpython/rev/bf64a5f7c1af New changeset 25919f35241e by Stefan Krah in branch '3.4': Issue #21374: Fix pickling of DecimalTuple. http://hg.python.org/cpython/rev/25919f35241e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 18:30:08 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 29 Apr 2014 16:30:08 +0000 Subject: [issue21374] DecimalTuple.__module__ is set to _frozen_importlib In-Reply-To: <1398700826.27.0.585241892269.issue21374@psf.upfronthosting.co.za> Message-ID: <1398789008.51.0.61399685327.issue21374@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 18:35:50 2014 From: report at bugs.python.org (Bill Bergmann) Date: Tue, 29 Apr 2014 16:35:50 +0000 Subject: [issue21378] ImportError: No module named 'concurrent.futures' In-Reply-To: <1398718950.31.0.466187960646.issue21378@psf.upfronthosting.co.za> Message-ID: <1398789350.4.0.297449564272.issue21378@psf.upfronthosting.co.za> Bill Bergmann added the comment: Thank you for your response. The program works as expected. I removed PYTHONPATH settings for 3.4 and 2.7. I'm not sure how those settings were written. I suspect something related to virtualenv, and I will be watching to see if they are written again. When I removed those paths, an error message pointed me to a local version of concurrent.py from tornado that was shadowing the concurrent.py in the python3.4 site-packages. ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 18:39:02 2014 From: report at bugs.python.org (Florent Xicluna) Date: Tue, 29 Apr 2014 16:39:02 +0000 Subject: [issue21382] Signal module doesnt raises ValueError Exception In-Reply-To: <1398759436.39.0.420418396293.issue21382@psf.upfronthosting.co.za> Message-ID: <1398789542.49.0.010437376623.issue21382@psf.upfronthosting.co.za> Changes by Florent Xicluna : ---------- components: +Library (Lib), Windows nosy: +flox type: enhancement -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 19:07:53 2014 From: report at bugs.python.org (Christian Tismer) Date: Tue, 29 Apr 2014 17:07:53 +0000 Subject: [issue21381] Python 3.4+ interpreter built on/with OS X 10.7 deployment target segfaults on 10.8+ In-Reply-To: <1398734858.53.0.489606157179.issue21381@psf.upfronthosting.co.za> Message-ID: <1398791273.11.0.358706020992.issue21381@psf.upfronthosting.co.za> Christian Tismer added the comment: Ned, thank you for locating the patch that causes the problem. At least, I could now make my script work, built a patch feature into it. cheers - Chris ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 19:16:49 2014 From: report at bugs.python.org (Florent Xicluna) Date: Tue, 29 Apr 2014 17:16:49 +0000 Subject: [issue21382] Signal module doesnt raises ValueError Exception In-Reply-To: <1398759436.39.0.420418396293.issue21382@psf.upfronthosting.co.za> Message-ID: <1398791809.52.0.850759217678.issue21382@psf.upfronthosting.co.za> Florent Xicluna added the comment: It's about documentation only. The sentence is not wrong, but it is slightly confusing, and there's no hint which signals are defined on Windows. "On Windows, signal() can only be called with SIGABRT, SIGFPE, SIGILL, SIGINT, SIGSEGV, or SIGTERM. A ValueError will be raised in any other case." Reading only this documentation, if the developer doesn't have a test platform on Windows, he could blindly write: try: signal.signal(signal.SIGPIPE, lambda signum, frame: sys.exit(1)) except ValueError: pass ... until a Windows user detects the issue (thank you rsevcan) Now I just found this page which is relevant here ... either we could link to the page in a "See also" section, or give an hint about which signals are defined or not. http://msdn.microsoft.com/en-us/library/xdkz3x12.aspx ---------- components: -Library (Lib) priority: normal -> low versions: +Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 19:27:43 2014 From: report at bugs.python.org (Tim Golden) Date: Tue, 29 Apr 2014 17:27:43 +0000 Subject: [issue9291] mimetypes initialization fails on Windows because of non-Latin characters in registry In-Reply-To: <1279454095.41.0.733053669611.issue9291@psf.upfronthosting.co.za> Message-ID: <1398792463.56.0.288398297778.issue9291@psf.upfronthosting.co.za> Changes by Tim Golden : ---------- assignee: -> tim.golden resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 19:50:38 2014 From: report at bugs.python.org (Brian Quinlan) Date: Tue, 29 Apr 2014 17:50:38 +0000 Subject: [issue21362] concurrent.futures does not validate that max_workers is proper In-Reply-To: <1398598769.27.0.217084820664.issue21362@psf.upfronthosting.co.za> Message-ID: <1398793838.54.0.430682495659.issue21362@psf.upfronthosting.co.za> Brian Quinlan added the comment: The patch looks good to me too. I'll commit it soon. ---------- assignee: -> bquinlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 19:58:44 2014 From: report at bugs.python.org (Adam Polkosnik) Date: Tue, 29 Apr 2014 17:58:44 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1398794324.52.0.815895898542.issue6839@psf.upfronthosting.co.za> Adam Polkosnik added the comment: Gentlemen, Is there's any way this fix can be included in any version? Currently, the fact that the exception is thrown makes extracting some zip files impossible with this library, and rolling your own is a bit painful. (either using a wrapper around 7zip to handle those or just provide cloned/patched versions for every major python version). This ridiculous behavior is really not consistent with other ZIP implementations (7zip just ignores the mismatch). Thank you for your time and effort. ---------- versions: +Python 3.1, Python 3.2, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 20:21:23 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 29 Apr 2014 18:21:23 +0000 Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler. In-Reply-To: <1364833880.2.0.617388686213.issue17611@psf.upfronthosting.co.za> Message-ID: <1398795683.48.0.289413234768.issue17611@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is an updated patch keeping up with recent changes in the source tree. ---------- Added file: http://bugs.python.org/file35094/unwinding.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 20:27:34 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 29 Apr 2014 18:27:34 +0000 Subject: [issue21387] Memory leaks when embedded interpreter is reinitialized In-Reply-To: <1398772537.74.0.909134635776.issue21387@psf.upfronthosting.co.za> Message-ID: <1398796054.96.0.260346604491.issue21387@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thanks. It would be nice if you could try the same with Python 3.4, or the development version. ---------- nosy: +pitrou, skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 20:34:25 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 29 Apr 2014 18:34:25 +0000 Subject: [issue21353] document Popen.args attribute In-Reply-To: <1398481373.88.0.978177813548.issue21353@psf.upfronthosting.co.za> Message-ID: <3gJBN01f4Mz7LjT@mail.python.org> Roundup Robot added the comment: New changeset 0a4b211b927e by Gregory P. Smith in branch '3.3': Document the subprocess Popen.args attribute (issue21353) http://hg.python.org/cpython/rev/0a4b211b927e New changeset 182b869283a5 by Gregory P. Smith in branch '3.4': Document the subprocess Popen.args attribute (issue21353) http://hg.python.org/cpython/rev/182b869283a5 New changeset 0b2e199ad088 by Gregory P. Smith in branch 'default': Document the subprocess Popen.args attribute (issue21353) http://hg.python.org/cpython/rev/0b2e199ad088 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 20:35:05 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 29 Apr 2014 18:35:05 +0000 Subject: [issue21353] document Popen.args attribute In-Reply-To: <1398481373.88.0.978177813548.issue21353@psf.upfronthosting.co.za> Message-ID: <1398796505.44.0.497565848693.issue21353@psf.upfronthosting.co.za> Gregory P. Smith added the comment: yes. this was overlooked. thanks! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 20:58:47 2014 From: report at bugs.python.org (=?utf-8?q?Kim_Gr=C3=A4sman?=) Date: Tue, 29 Apr 2014 18:58:47 +0000 Subject: [issue18314] Have os.unlink remove junction points In-Reply-To: <1372335321.1.0.479247042071.issue18314@psf.upfronthosting.co.za> Message-ID: <1398797927.85.0.290204071852.issue18314@psf.upfronthosting.co.za> Kim Gr?sman added the comment: Here's a new attempt, please let me know if this works out better. Changes: - Switched to CRT string functions (wcsncmp, wcscpy) instead of Windows lstrxxxW. There was no lstrncmpW. - Switched to PyMem_Raw(Malloc|Free) and added explicit memset after allocation - Better error handling (check arguments for NULL, check memory allocation) - Fix possible overrun when checking if src_path starts with "\??\" - Extensive commentary to describe the buffer sizing Hope this works out better. I already have ideas for improvements, but I think we can try to get this in place first. ---------- Added file: http://bugs.python.org/file35095/unlink_junctions_r2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 21:11:23 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 29 Apr 2014 19:11:23 +0000 Subject: [issue21388] decimal.InvalidContext is unused In-Reply-To: <1398778771.07.0.438455770103.issue21388@psf.upfronthosting.co.za> Message-ID: <1398798683.45.0.755350552222.issue21388@psf.upfronthosting.co.za> Stefan Krah added the comment: Okay, also it is easier to keep it. I was just busy with the exception docs and found the InvalidContext situation slightly odd. Of course, there is a very small chance that external software is using it. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 21:14:41 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 29 Apr 2014 19:14:41 +0000 Subject: [issue21387] Memory leaks when embedded interpreter is reinitialized In-Reply-To: <1398772537.74.0.909134635776.issue21387@psf.upfronthosting.co.za> Message-ID: <1398798881.8.0.52990054226.issue21387@psf.upfronthosting.co.za> Stefan Krah added the comment: Are we fixing these on a case by case basis or is it hopeless (msg146615)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 21:20:41 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 29 Apr 2014 19:20:41 +0000 Subject: [issue21387] Memory leaks when embedded interpreter is reinitialized In-Reply-To: <1398772537.74.0.909134635776.issue21387@psf.upfronthosting.co.za> Message-ID: <1398799241.55.0.863842370976.issue21387@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I think fixing on a case by case is fine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 21:38:14 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Tue, 29 Apr 2014 19:38:14 +0000 Subject: [issue2159] dbmmodule inquiry function is performance prohibitive In-Reply-To: <1203640875.82.0.736964888757.issue2159@psf.upfronthosting.co.za> Message-ID: <1398800294.98.0.443183502095.issue2159@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Eric, would you mind to clarify the points I raised in the last message?. Lets move this forward. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 22:08:22 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 29 Apr 2014 20:08:22 +0000 Subject: [issue21037] add an AddressSanitizer build option In-Reply-To: <1398758293.99.0.303253903098.issue21037@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > That said, it would be better if you first check said options work locally. I wasn't clear, but I did test it, and it works: the only problem I encountered is address space exhaustion: I have a 32-bit box, and ASAN uses a lot of virtual address space (for shadow pages), so with a lot of memory or many thread you can hit the 3G limit. So we should only run this on 64-bit machine (see below for more details). > I can add environment variables and configure options specific to a buildbot. Just tell me which ones (and which buildbot (preferably yours ? :-)). Yeah, I barely have a day-to-day machine, so I'm afraid I can't help here :-) I guess we could go for any non-stable buildbot meeting the following criteria: - Linux 64-bit - clang >= 3.1 or gcc >= 4.8 But it would be great if someone could test the patch locally on a 64-bit machine before I commit it. Basically: $ patch -p1 < ~/asan.diff && autoconf && autoheader && ./configure --with-address-sanitizer && make $ ASAN_OPTIONS=handle_segv=0 ./python -m test -vG -uall ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 22:22:57 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 29 Apr 2014 20:22:57 +0000 Subject: [issue21037] add an AddressSanitizer build option In-Reply-To: <1395581927.59.0.22052744693.issue21037@psf.upfronthosting.co.za> Message-ID: <1398802977.78.0.219196358272.issue21037@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > I guess we could go for any non-stable buildbot meeting the following > criteria: > - Linux 64-bit > - clang >= 3.1 or gcc >= 4.8 Hmm... perhaps Stefan would like to set something up? ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 22:27:14 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 29 Apr 2014 20:27:14 +0000 Subject: [issue21037] add an AddressSanitizer build option In-Reply-To: <1395581927.59.0.22052744693.issue21037@psf.upfronthosting.co.za> Message-ID: <1398803234.15.0.897159631014.issue21037@psf.upfronthosting.co.za> Antoine Pitrou added the comment: How do we spot any ASAN issues, though? Does ASAN change the process' return code on errors? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 22:41:34 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 29 Apr 2014 20:41:34 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1398804094.59.0.529007791924.issue6839@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Adam P, please don't screw around with the version headers. If you want to claim that this is a security issue of the type we care about (threats to the public internet) for patching old releases, and severe enough that we should do anything about it, send a detailed explanation with links to evidence to security response team. Simple writing 'a possible scenario' is insufficient. ---------- versions: -Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 22:54:46 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 29 Apr 2014 20:54:46 +0000 Subject: [issue21037] add an AddressSanitizer build option In-Reply-To: <1398803234.15.0.897159631014.issue21037@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > How do we spot any ASAN issues, though? Does ASAN change the process' return code on errors? It aborts: $ cat /tmp/test.c int main(int argc, char *argv[]) { int bar[16] = {0}; /* oops */ return bar[16]; } $ gcc -Wall -fsanitize=address -o /tmp/test /tmp/test.c $ /tmp/test ================================================================= ==15028== ERROR: AddressSanitizer: stack-buffer-overflow on address 0xbffab500 at pc 0x80485ec bp 0xbffab488 sp 0xbffab47c READ of size 4 at 0xbffab500 thread T0 #0 0x80485eb (/tmp/test+0x80485eb) #1 0xb5fd8a62 (/lib/i386-linux-gnu/i686/cmov/libc-2.18.so+0x19a62) #2 0x8048490 (/tmp/test+0x8048490) Address 0xbffab500 is located at offset 96 in frame
of T0's stack: This frame has 1 object(s): [32, 96) 'bar' HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext (longjmp and C++ exceptions *are* supported) Shadow bytes around the buggy address: 0x37ff5650: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x37ff5660: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x37ff5670: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x37ff5680: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x37ff5690: 00 00 00 00 f1 f1 f1 f1 00 00 00 00 00 00 00 00 =>0x37ff56a0:[f3]f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 0x37ff56b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x37ff56c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x37ff56d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x37ff56e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x37ff56f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 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 righ 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 ASan internal: fe ==15028== ABORTING You obviously don't see here, but it also colors the output in a terminal :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 22:59:34 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 29 Apr 2014 20:59:34 +0000 Subject: [issue18104] Idle: make human-mediated GUI tests usable In-Reply-To: <1369961521.26.0.131640091288.issue18104@psf.upfronthosting.co.za> Message-ID: <1398805174.05.0.0743791894822.issue18104@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The new patch adds a docstring with spec template, a second example, and a crude runall(). I am inclined to push this as a base for further patches -- at least one to improve runall and others to test more widget classes. These might be separate issues. ---------- Added file: http://bugs.python.org/file35096/18104-htest2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 22:59:54 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 29 Apr 2014 20:59:54 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1398805194.98.0.957786844127.issue21233@psf.upfronthosting.co.za> STINNER Victor added the comment: Patch version 6: - I renamed "int zero" parameter to "int use_calloc" and move the new parameter at the first position to avoid confusion with nelem. For example, _PyObject_Alloc(ctx, 1, nbytes, 0) becomes _PyObject_Alloc(0, ctx, 1, nbytes). It also more logical to put it in the first position. In bytesobject.c, I leaved it at the parameter at the end since its meaning is different (fill bytes with zero or not) IMO. - I removed my hack (premature optimization) "assert(nelem == 1); ... malloc(elsize);" and replaced it with a less surprising "... malloc(nelem * elsize);" Stefan & Charles-Fran?ois: I hope that the patch looks better to you. ---------- Added file: http://bugs.python.org/file35097/calloc-6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 23:05:27 2014 From: report at bugs.python.org (Hannan Aharonov) Date: Tue, 29 Apr 2014 21:05:27 +0000 Subject: [issue21379] StopIteration is silenced when raised by generator within context manager In-Reply-To: <1398719429.87.0.781789142964.issue21379@psf.upfronthosting.co.za> Message-ID: <1398805527.06.0.195970293528.issue21379@psf.upfronthosting.co.za> Hannan Aharonov added the comment: OK. Thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 23:08:29 2014 From: report at bugs.python.org (Adam Polkosnik) Date: Tue, 29 Apr 2014 21:08:29 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1398805709.75.0.750986704428.issue6839@psf.upfronthosting.co.za> Adam Polkosnik added the comment: For the version headers, I've added the versions featuring the broken behavior. That's all. I'm not saying that this is I'm extracting malware from the Central Quarantine files, and the vendor's implementation is broken and is causing this issue for me on every single file inside the archive. Let's say, I've got a wrapper script that feeds the contents of a zip file to be scanned with this, because of this behavior, the wrapper will error out... Customers will say your product sucks, etc. Does this really take an act of god to fix this? ---------- versions: +Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 23:09:12 2014 From: report at bugs.python.org (=?utf-8?q?William_Tis=C3=A4ter?=) Date: Tue, 29 Apr 2014 21:09:12 +0000 Subject: [issue12382] [msilib] Obscure exception message when trying to open a non-existent MSI database In-Reply-To: <1308658337.05.0.630810191443.issue12382@psf.upfronthosting.co.za> Message-ID: <1398805752.41.0.655733483438.issue12382@psf.upfronthosting.co.za> William Tis?ter added the comment: Found this a simple fix for an annoying and time consuming error. Patched as discussed earlier and decided to leave the filename out. ---------- components: +Windows -Library (Lib) keywords: +patch nosy: +tiwilliam versions: +Python 3.5 Added file: http://bugs.python.org/file35098/12382_msi-open-error-message.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 23:14:30 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 29 Apr 2014 21:14:30 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1398805194.98.0.957786844127.issue21233@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: LGTM! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 23:15:57 2014 From: report at bugs.python.org (Adam Polkosnik) Date: Tue, 29 Apr 2014 21:15:57 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1398806157.76.0.00240578019325.issue6839@psf.upfronthosting.co.za> Adam Polkosnik added the comment: Also, this behavior is present on all platforms and all versions of Python (zipfile Library), so maybe the headers should be adjusted there too. I'm not saying that this is necessarily a big freaking hole, but by using this, one can prevent files from being extracted using this simple trick. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 23:18:41 2014 From: report at bugs.python.org (Tim Peters) Date: Tue, 29 Apr 2014 21:18:41 +0000 Subject: [issue21375] Fix and test overflow behavior in the C version of heapq In-Reply-To: <1398707994.45.0.696035798055.issue21375@psf.upfronthosting.co.za> Message-ID: <1398806321.04.0.203787025708.issue21375@psf.upfronthosting.co.za> Tim Peters added the comment: I don't see a way to test it either, but it's easy enough to prove it's correct ;-) That is, looks good to me! ---------- nosy: +tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 23:21:07 2014 From: report at bugs.python.org (Adam Polkosnik) Date: Tue, 29 Apr 2014 21:21:07 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1398806467.65.0.454553120339.issue6839@psf.upfronthosting.co.za> Adam Polkosnik added the comment: If I got a file scanner in my mail gateway implemented with this, one can easily avoid getting the contents of zip-files scanned. Is that enough of a security impact? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 23:30:41 2014 From: report at bugs.python.org (Eric Olson) Date: Tue, 29 Apr 2014 21:30:41 +0000 Subject: [issue2159] dbmmodule inquiry function is performance prohibitive In-Reply-To: <1203640875.82.0.736964888757.issue2159@psf.upfronthosting.co.za> Message-ID: <1398807041.81.0.817071399537.issue2159@psf.upfronthosting.co.za> Eric Olson added the comment: Thank you for the feedback. Sorry I didn't see your previous response until today. I will take a look and respond tonight. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 29 23:42:14 2014 From: report at bugs.python.org (Adam Polkosnik) Date: Tue, 29 Apr 2014 21:42:14 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1398807734.92.0.778181012128.issue6839@psf.upfronthosting.co.za> Adam Polkosnik added the comment: I've also tested with WinZip, and Windows Explorer, on windows. Both extract the contents of test.zip without a warning (just like 7zip on Windows did). This behavior counts as Denial Of Service if the zipfile Library is used to extract files, besides lots of formats use ZIP as an envelope; DOCX, APK, JAR, EPUB come to mind. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 00:17:40 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Tue, 29 Apr 2014 22:17:40 +0000 Subject: [issue21281] DEBUGGING: Simultaneous stopping of all threads on breakpoint and switching between threads In-Reply-To: <1397724727.36.0.728876639251.issue21281@psf.upfronthosting.co.za> Message-ID: <1398809860.91.0.781949955629.issue21281@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- versions: -Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 00:35:47 2014 From: report at bugs.python.org (=?utf-8?q?William_Tis=C3=A4ter?=) Date: Tue, 29 Apr 2014 22:35:47 +0000 Subject: [issue19214] shutil.make_archive should recognize extensions in filenames In-Reply-To: <1381395037.28.0.850005234621.issue19214@psf.upfronthosting.co.za> Message-ID: <1398810947.54.0.769454910178.issue19214@psf.upfronthosting.co.za> William Tis?ter added the comment: I'm not sure if this is a suitable feature in `make_archive()`, it would only introduce a more expensive and ugly lookup. Using this method with a pre-defined filename including extension must be rare. If you really want this behaviour, I would prefer having this helper instead: def make_archive(filename, **kwargs): for fmt, ext, info in shutil.get_unpack_formats(): if not filename.lower().endswith(tuple(ext)): continue return shutil.make_archive(filename[:-len(ext)], fmt, **kwargs) raise ValueError("Unknown archive format: %s" % filename) Not sure what version you are using, `get_unpack_formats()` got introduced in 3.2. ---------- nosy: +tiwilliam _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 00:46:42 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 29 Apr 2014 22:46:42 +0000 Subject: [issue18104] Idle: make human-mediated GUI tests usable In-Reply-To: <1369961521.26.0.131640091288.issue18104@psf.upfronthosting.co.za> Message-ID: <1398811602.76.0.643657964822.issue18104@psf.upfronthosting.co.za> Terry J. Reedy added the comment: New patch. I refined the definition of the parameter for run() in the process of adding a test for EditorWindow.HelpDialog. This cannot be tested directly. This example is also a reminder that some files define more than one display widget. I should try template and framework with non-dialog, but the example above pretty well convinces me that the framework should be flexible enough. ---------- Added file: http://bugs.python.org/file35099/18104-htest3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 01:12:25 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 29 Apr 2014 23:12:25 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1398813145.77.0.747518288952.issue6839@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Adam P. I politely asked you to leave the headers alone. Since you ignored that, LEAVE THE HEADERS ALONE! If you continue, you will eventually get banned. An issue gets dealt with when a volunteer core developer makes it his top priority. In the past 24 hours, patches were pushed for 16 different issues, but not this one. Sorry, but that is how it is. ---------- versions: -Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 01:43:48 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Tue, 29 Apr 2014 23:43:48 +0000 Subject: [issue21234] __contains__ and friends should check "is" for all elements first In-Reply-To: <1397567063.59.0.649029276797.issue21234@psf.upfronthosting.co.za> Message-ID: <1398815028.69.0.138955912891.issue21234@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 01:58:39 2014 From: report at bugs.python.org (Masayuki Yamamoto) Date: Tue, 29 Apr 2014 23:58:39 +0000 Subject: [issue21124] _struct module compilation error under Cygwin 1.7.17 on Python 3.4 In-Reply-To: <1396363951.96.0.324613047949.issue21124@psf.upfronthosting.co.za> Message-ID: <1398815919.91.0.222109935163.issue21124@psf.upfronthosting.co.za> Masayuki Yamamoto added the comment: I have solved about compiling _struct module too. I have no authority of this issues, So please close of issues. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 01:59:23 2014 From: report at bugs.python.org (Masayuki Yamamoto) Date: Tue, 29 Apr 2014 23:59:23 +0000 Subject: [issue21124] _struct module compilation error under Cygwin 1.7.17 on Python 3.4 In-Reply-To: <1396363951.96.0.324613047949.issue21124@psf.upfronthosting.co.za> Message-ID: <1398815963.68.0.931435074575.issue21124@psf.upfronthosting.co.za> Changes by Masayuki Yamamoto : ---------- nosy: -masamoto _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 02:55:59 2014 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 30 Apr 2014 00:55:59 +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: <1398819359.97.0.47096094926.issue19217@psf.upfronthosting.co.za> Ezio Melotti added the comment: I don't think I will have time for this for a while, so if anyone wants to provide tests they are welcomed to do it. The related #11763 already has some tests, so those might be adapted for this issue. ---------- keywords: +easy stage: patch review -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 03:17:19 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 30 Apr 2014 01:17:19 +0000 Subject: [issue21320] dict() allows keyword expansion with integer keys, e.g. dict(**{5:'v'}) In-Reply-To: <1398081299.38.0.288058317096.issue21320@psf.upfronthosting.co.za> Message-ID: <1398820639.87.0.252085801248.issue21320@psf.upfronthosting.co.za> R. David Murray added the comment: I'm not going to reopen it, but my point was that if we really are going to add additional -3 warnings to help people port 2.7, as discussed at the language summit, then this would be a candidate. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 03:44:30 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Wed, 30 Apr 2014 01:44:30 +0000 Subject: [issue21377] PyBytes_Concat could try to concat in-place In-Reply-To: <1398714444.35.0.443659487134.issue21377@psf.upfronthosting.co.za> Message-ID: <1398822270.25.0.790691228043.issue21377@psf.upfronthosting.co.za> Changes by Nikolaus Rath : Added file: http://bugs.python.org/file35100/issue_21377_r3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 03:51:36 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 30 Apr 2014 01:51:36 +0000 Subject: [issue18154] make install failed on solaris In-Reply-To: <1370592517.54.0.994664040442.issue18154@psf.upfronthosting.co.za> Message-ID: <1398822696.59.0.191784044581.issue18154@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Palm, I am trying "ln -sf" on Solaris 10 and it works ok. What error are you getting? ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 04:26:41 2014 From: report at bugs.python.org (Steven Barker) Date: Wed, 30 Apr 2014 02:26:41 +0000 Subject: [issue21389] The repr of BoundMethod objects sometimes incorrectly identifies the bound function Message-ID: <1398824801.68.0.416059453762.issue21389@psf.upfronthosting.co.za> New submission from Steven Barker: The "repr" of bound method objects can be misleading in certain situations. The repr is always is of the format: > But "x" is often incorrect. Here are some examples where the current code gets it wrong: # inherited method class Base(object): def foo(self): pass class Derived(Base): pass print(Derived().foo) # not too bad, prints ">" # it probably should say "Base.foo" instead of "Derived.foo", but at least they're two names for the same function # however, an override and super() it gets very bad class Derived2(Base): def foo(self): pass print(super(Derived2, Derived2()).foo) # totally wrong, prints ">" # but it actually *is* Base.foo bound to a Derived2 instance! # bound class methods: class Test(object): @classmethod def foo(cls): pass print(Test.foo) # wrong, prints > I suggest that rather than trying to assemble the "x.y" pair by from "__self__.__class__" and "__func__.__name__", the BoundMethod should just use the "__func__.__qualname__". In each of the cases above, the function's location would be correctly located this way. I came across this bug while investigating a confusing (to me) issue with metaclasses and inheritance. The misleading "repr" output made it much harder to figure out that my expectations were wrong. Here's a simplified example of how it led me astray: class A(object): @classmethod def foo(cls): return "classmethod from A" class BMeta(type): def foo(cls): return "instancemethod from BMeta" class B(A, metaclass=BMeta): pass print(B.foo()) # surprisingly (to me) prints "classmethod from A" print(B.foo) # incorrectly prints ">" It is presumably not a bug that inherited class methods take precedence over instance methods from a metaclass (though it was surprising to me at the time). The repr of the bound method though, suggested exactly the opposite. Given that it gets many more common situations wrong as well, I think that the repr should be fixed. The relevant code appears to be in the method_repr function in Objects/Classobject.c . ---------- components: Interpreter Core messages: 217566 nosy: Steven.Barker priority: normal severity: normal status: open title: The repr of BoundMethod objects sometimes incorrectly identifies the bound function type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 04:58:01 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Wed, 30 Apr 2014 02:58:01 +0000 Subject: [issue20951] SSLSocket.send() returns 0 for non-blocking socket In-Reply-To: <1395004591.32.0.211111410214.issue20951@psf.upfronthosting.co.za> Message-ID: <1398826681.1.0.0311781316112.issue20951@psf.upfronthosting.co.za> Nikolaus Rath added the comment: Antoine, are you sure this was a problem related to this patch? The test seems to work just fine for me: $ hg update -C -r b0f6983d63df $ make clean $ ./configure --with-pydebug && make -j1 $ ./python -m test -u network,urlfetch -j 8 test_poplib [1/1] test_poplib 1 test OK. Am I doing something wrong? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 06:02:11 2014 From: report at bugs.python.org (Eric Olson) Date: Wed, 30 Apr 2014 04:02:11 +0000 Subject: [issue2159] dbmmodule inquiry function is performance prohibitive In-Reply-To: <1203640875.82.0.736964888757.issue2159@psf.upfronthosting.co.za> Message-ID: <1398830531.88.0.778290121593.issue2159@psf.upfronthosting.co.za> Eric Olson added the comment: Hi Jes?s, I believe the patch should have this behavior: a) If the database is closed, raise an exception. b) If database is empty, return False. c) If database has any entry, return True. Fast and simply checking if the database has at least a single record. The 0/1 appears to be converted to Py_TRUE/Py_FALSE in PyObject_IsTrue() in boolobject.c. For background, here's the code path I'm seeing: bool_new(...) (in Objects/boolobject.c) ... ok = PyObject_IsTrue(obj) (in Objects/object.c) ... return PyBool_FromLong(ok) Looking at PyObject_IsTrue is informative. It shows that since tp_as_number->nb_bool is defined (as dbm_bool), it is used instead of the old default of tp_as_mapping->mp_length. I'm still learning CPython, and I'm not sure if everything goes through bool_new(), but I think this makes sense. If you see more places I can/should look for details here, let me know. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 06:12:23 2014 From: report at bugs.python.org (Ethan Furman) Date: Wed, 30 Apr 2014 04:12:23 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1398831143.88.0.92857442437.issue6839@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 06:16:52 2014 From: report at bugs.python.org (Adam Polkosnik) Date: Wed, 30 Apr 2014 04:16:52 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1398831412.76.0.226074261159.issue6839@psf.upfronthosting.co.za> Adam Polkosnik added the comment: Terry, I apologize about the second change of headers, somehow I must have used the submission form to post the comment from a tab that had the old content, and the headers didn't refresh there. I assure you that it was not my intention to change them again. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 06:23:10 2014 From: report at bugs.python.org (Adam Polkosnik) Date: Wed, 30 Apr 2014 04:23:10 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1398831790.26.0.577149006807.issue6839@psf.upfronthosting.co.za> Adam Polkosnik added the comment: In any event, I think that zipfile_stupid3.patch would be the best trivial fix to this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 06:34:06 2014 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 30 Apr 2014 04:34:06 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1398832446.34.0.883173424516.issue6839@psf.upfronthosting.co.za> Nick Coghlan added the comment: The check can be simplified further to "if self.debug and fname != zinfo.orig_filename:", but the conversion to a debugging print seems reasonable to me. ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 07:16:10 2014 From: report at bugs.python.org (Adam Polkosnik) Date: Wed, 30 Apr 2014 05:16:10 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1398834970.23.0.855258606173.issue6839@psf.upfronthosting.co.za> Adam Polkosnik added the comment: Patch against 2.7.6 attached. ---------- Added file: http://bugs.python.org/file35101/zipfile_276_filename_mismatch.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 07:19:50 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 30 Apr 2014 05:19:50 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1398835190.83.0.0795500505421.issue6839@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Nick, do you agree that this should be treated as a bug (apply to all 3 versions)? Should debug messages be 'print'ed, sent to stderr, or go through the warnings module? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 07:23:54 2014 From: report at bugs.python.org (Adam Polkosnik) Date: Wed, 30 Apr 2014 05:23:54 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1398835434.06.0.467345377597.issue6839@psf.upfronthosting.co.za> Adam Polkosnik added the comment: Patch against zipfile 3.4.0 attached. ---------- Added file: http://bugs.python.org/file35102/zipfile_340_filename_mismatch.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 07:25:59 2014 From: report at bugs.python.org (Adam Polkosnik) Date: Wed, 30 Apr 2014 05:25:59 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1398835559.49.0.65495272472.issue6839@psf.upfronthosting.co.za> Changes by Adam Polkosnik : Removed file: http://bugs.python.org/file35102/zipfile_340_filename_mismatch.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 07:26:12 2014 From: report at bugs.python.org (Adam Polkosnik) Date: Wed, 30 Apr 2014 05:26:12 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1398835572.31.0.00510185128773.issue6839@psf.upfronthosting.co.za> Changes by Adam Polkosnik : Removed file: http://bugs.python.org/file35101/zipfile_276_filename_mismatch.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 07:27:23 2014 From: report at bugs.python.org (Adam Polkosnik) Date: Wed, 30 Apr 2014 05:27:23 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1398835643.31.0.520235772323.issue6839@psf.upfronthosting.co.za> Adam Polkosnik added the comment: update ---------- Added file: http://bugs.python.org/file35103/zipfile_340_filename_mismatch.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 07:30:35 2014 From: report at bugs.python.org (Adam Polkosnik) Date: Wed, 30 Apr 2014 05:30:35 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1398835835.69.0.0365629905127.issue6839@psf.upfronthosting.co.za> Adam Polkosnik added the comment: Once again patch against 2.7.6 ---------- Added file: http://bugs.python.org/file35104/zipfile_276_filename_mismatch.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 09:15:17 2014 From: report at bugs.python.org (dellair jie) Date: Wed, 30 Apr 2014 07:15:17 +0000 Subject: [issue21124] _struct module compilation error under Cygwin 1.7.17 on Python 3.4 In-Reply-To: <1396363951.96.0.324613047949.issue21124@psf.upfronthosting.co.za> Message-ID: <1398842117.29.0.214668771404.issue21124@psf.upfronthosting.co.za> dellair jie added the comment: Fixed with the patch. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 09:23:25 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 30 Apr 2014 07:23:25 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1398842605.59.0.546249937639.issue6839@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Don't use print (to stdout) or sys.stderr directly. There are already many other uses of warnings.warn within the zipfile module. Be consistent with those. Existing zipfile warnings seem to favor lazily importing warnings when its needed rather than a top level 'import warnings'. While I find that annoying, there are sometimes reasons to do it and the minimally invasive change that is consistent with the rest of the existing code is to do the same thing here. something similar to: + if self.debug and fname != zinfo.orig_filename: + import warnings + warnings.warn( + 'Warning: Filename in directory "%s" and header "%s" differ.' % ( + zinfo.orig_filename, fname)) ---------- nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 09:30:15 2014 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 30 Apr 2014 07:30:15 +0000 Subject: [issue21381] Python 3.4+ interpreter built on/with OS X 10.7 deployment target segfaults on 10.8+ In-Reply-To: <1398734858.53.0.489606157179.issue21381@psf.upfronthosting.co.za> Message-ID: <1398843015.02.0.351352921346.issue21381@psf.upfronthosting.co.za> Ronald Oussoren added the comment: The problem in Issue18075 depends on the amount of C stack used on average during recursion because unlike Windows the Unix ports don't test if the end of the stack is reached but just check for a maximum recursion count. It could well be that the problem in that issue don't happen at the moment due to small changes in either CPython or the compiler. It is also easier to trigger the problem with a debug build. I have no idea why the linker flag causes problems, I'd have to debug this myself. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 09:33:43 2014 From: report at bugs.python.org (Li Zhenhua) Date: Wed, 30 Apr 2014 07:33:43 +0000 Subject: [issue21390] strdup may cause Segment Fault on Android Message-ID: <1398843223.64.0.854948810113.issue21390@psf.upfronthosting.co.za> New submission from Li Zhenhua: On Android platform, when run "python" command without any scripts, it may crash, get an error message "Segment Fault". This is because strdup with a NULL pointer. Details: In file Modules/readline.c, function static void setup_readline(void) This line: char *saved_locale = strdup(setlocale(LC_CTYPE, NULL)); When running on an Android platform, setlocale(LC_CTYPE, NULL) returns NULL, and this causes strdup with a NULL pointer, then Segment Fault occurs. ---------- components: Cross-Build files: strdup.patch keywords: patch messages: 217580 nosy: lizhenhua.dev priority: normal severity: normal status: open title: strdup may cause Segment Fault on Android versions: Python 3.5 Added file: http://bugs.python.org/file35105/strdup.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 10:09:16 2014 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 30 Apr 2014 08:09:16 +0000 Subject: [issue20438] inspect: Deprecate getfullargspec? In-Reply-To: <1397690245.32.0.364350666473.issue20438@psf.upfronthosting.co.za> Message-ID: St?phane Wirtel added the comment: @Larry Hasting: If you check my patch, it's the case where I modify the documentation and add a DeprecationWarning in the code. @Yury Selivanov, @Nick Coghlan, @Brett Cannon: From your point of views, I need to propose a patch just for the documentation, I agree with that. @Brett Cannon: In the current patch, I implemented a test with the python version. If the version is greater or equal than 3.7, in this case, I raise an exception. I propose to follow the solution of @Yury Selinanov, just deprecate the function in the documentation and keep the check in the unit test for the version. Are you agree? Thanks ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 10:49:28 2014 From: report at bugs.python.org (Yinon Ehrlich) Date: Wed, 30 Apr 2014 08:49:28 +0000 Subject: [issue21391] PATCH: using the abspath shortcut in Lib/shutil Message-ID: <1398847768.59.0.993653219407.issue21391@psf.upfronthosting.co.za> Changes by Yinon Ehrlich : ---------- components: Library (Lib) nosy: Yinon priority: normal severity: normal status: open title: PATCH: using the abspath shortcut in Lib/shutil versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 10:53:22 2014 From: report at bugs.python.org (Jayanth Koushik) Date: Wed, 30 Apr 2014 08:53:22 +0000 Subject: [issue21380] timezone support in strftime methods broken In-Reply-To: <1398720102.85.0.645448692913.issue21380@psf.upfronthosting.co.za> Message-ID: <1398848002.73.0.570728830792.issue21380@psf.upfronthosting.co.za> Jayanth Koushik added the comment: This is not an issue with strftime. By default, datetime and time objects are 'navie' and they do not contain timezone info. Nor does the datetime module provide any tzinfo classes of its own. You would need to write a class derived from tzinfo and specify it as the tzinfo attribute for these objects to be timezone aware. ---------- nosy: +jayanthkoushik _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 11:00:57 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 30 Apr 2014 09:00:57 +0000 Subject: [issue20951] SSLSocket.send() returns 0 for non-blocking socket In-Reply-To: <1398826681.1.0.0311781316112.issue20951@psf.upfronthosting.co.za> Message-ID: <1398848454.2295.0.camel@fsol> Antoine Pitrou added the comment: > Am I doing something wrong? I can reproduce the failure here. There might be different behaviour accross OpenSSL versions (mine is 1.0.1e). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 11:15:15 2014 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 30 Apr 2014 09:15:15 +0000 Subject: [issue21224] BaseHTTPRequestHandler, update the protocol version to http 1.1 by default? In-Reply-To: <1397782830.45.0.168242937584.issue21224@psf.upfronthosting.co.za> Message-ID: St?phane Wirtel added the comment: In this case, I suggest than by default, we use the version 1.1 of HTTP and not 1.0. We are in 2014, I suppose that all the old http clients use the version 1.1 of the protocol, otherwise, the user can specify the version 1.0. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 11:15:44 2014 From: report at bugs.python.org (dellair jie) Date: Wed, 30 Apr 2014 09:15:44 +0000 Subject: [issue21392] Python on Cygwin: subprocess.call BlockingIOError: [Errno 11] Resource temporarily unavailable Message-ID: <1398849344.37.0.135899033278.issue21392@psf.upfronthosting.co.za> New submission from dellair jie: Folks, I am running Python 3.4 on Cygwin 1.7.17 on Windows 2008. The constant error I get is: Traceback (most recent call last): File "M:/sb3_ljie/bce/cmTools/lib/CC.py", line 321, in standAlone results = Process.execute (cmd = cmd, opts = opts) File "M:/sb3_ljie/bce/cmTools/lib/Process.py", line 327, in execute timeout = timeout) File "/usr/local/lib/python3.4/subprocess.py", line 535, in call with Popen(*popenargs, **kwargs) as p: File "/usr/local/lib/python3.4/subprocess.py", line 848, in __init__ restore_signals, start_new_session) File "/usr/local/lib/python3.4/subprocess.py", line 1379, in _execute_child restore_signals, start_new_session, preexec_fn) BlockingIOError: [Errno 11] Resource temporarily unavailable Python script is invoked via socket (server runs Cygwin inetd). While the script (snippet) Process.py is as below with relatively large data return: import subprocess, os, tempfile, re def execute (cmd = None, opts = None, log = None, verify = False, cmdlog = False, audit = False, logappend = False, ignorestatus = False, umask = None, host = None, interrupt = None, timeout = None, forceaudit = False): global __signal global __signalList returnData = {"status": 0, "rawstatus": 0, "interrupt": 0, "stdout": None, "stderr": None} os.environ["ENV"] = "" stdOutHandle, stdOut = tempfile.mkstemp (text = True) stdErrHandle, stdErr = tempfile.mkstemp (text = True) if re.match ("\s", cmd): cmd = "'" + cmd + "'" cmd = [cmd] opts = opts.split() cmd.extend (opts) if not verify: if umask: originalUmask = os.umask (umask) if interrupt: for idex, item in enumerate (__signalList): if item: signal.signal (idex, interrupt) __signal = 0 returnData["rawstatus"] = subprocess.call (cmd, stdout = stdOutHandle, stderr = stdErrHandle, timeout = timeout) returns = returnData["rawstatus"] os.close (stdOutHandle) os.close (stdErrHandle) Br, Dellair ---------- messages: 217585 nosy: dellair.jie priority: normal severity: normal status: open title: Python on Cygwin: subprocess.call BlockingIOError: [Errno 11] Resource temporarily unavailable versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 11:16:12 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Wed, 30 Apr 2014 09:16:12 +0000 Subject: [issue16104] Compileall script: add option to use multiple cores In-Reply-To: <1349124414.14.0.0730954283721.issue16104@psf.upfronthosting.co.za> Message-ID: <1398849372.28.0.881373817275.issue16104@psf.upfronthosting.co.za> Claudiu.Popa added the comment: Updated patch according to the python-dev thread: - processes renamed to workers - `workers` defaults to 1 - When `workers` is equal to 0, then `os.cpu_count` will be used - When `workers` > 1, multiple processes will be used - When `workers` == 1, run normally (no multiple processes) - Negative values raises a ValueError - Will raise NotImplementedError if multiprocessing can't be used (when `workers` equals to 0 or > 1) ---------- Added file: http://bugs.python.org/file35106/issue16104_12.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 11:16:41 2014 From: report at bugs.python.org (dellair jie) Date: Wed, 30 Apr 2014 09:16:41 +0000 Subject: [issue21392] Python on Cygwin: subprocess.call BlockingIOError: [Errno 11] Resource temporarily unavailable In-Reply-To: <1398849344.37.0.135899033278.issue21392@psf.upfronthosting.co.za> Message-ID: <1398849401.34.0.183210959087.issue21392@psf.upfronthosting.co.za> Changes by dellair jie : ---------- components: +IO type: -> resource usage _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 11:50:23 2014 From: report at bugs.python.org (Eric V. Smith) Date: Wed, 30 Apr 2014 09:50:23 +0000 Subject: [issue21392] Python on Cygwin: subprocess.call BlockingIOError: [Errno 11] Resource temporarily unavailable In-Reply-To: <1398849344.37.0.135899033278.issue21392@psf.upfronthosting.co.za> Message-ID: <1398851423.58.0.446370743901.issue21392@psf.upfronthosting.co.za> Eric V. Smith added the comment: Can you provide a working example? How are you calling execute()? What are __signal and __signalList set to? Note that the default of "None" for cmd can't ever work, due to calling re.match ("\s", cmd). ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 11:51:46 2014 From: report at bugs.python.org (Eric V. Smith) Date: Wed, 30 Apr 2014 09:51:46 +0000 Subject: [issue21391] PATCH: using the abspath shortcut in Lib/shutil Message-ID: <1398851506.17.0.252002971676.issue21391@psf.upfronthosting.co.za> New submission from Eric V. Smith: If you meant to supply a patch, it is missing. And in any event, you need to describe the issue. ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 11:52:45 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 30 Apr 2014 09:52:45 +0000 Subject: [issue21390] readline: setlocale() returns NULL on Android In-Reply-To: <1398843223.64.0.854948810113.issue21390@psf.upfronthosting.co.za> Message-ID: <1398851565.86.0.533262030298.issue21390@psf.upfronthosting.co.za> STINNER Victor added the comment: Here is a patch. ---------- nosy: +haypo title: strdup may cause Segment Fault on Android -> readline: setlocale() returns NULL on Android versions: +Python 2.7, Python 3.4 Added file: http://bugs.python.org/file35107/readline_android.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 11:53:29 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 30 Apr 2014 09:53:29 +0000 Subject: [issue21387] Memory leaks when embedded interpreter is reinitialized In-Reply-To: <1398772537.74.0.909134635776.issue21387@psf.upfronthosting.co.za> Message-ID: <1398851609.17.0.310444911146.issue21387@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 11:56:09 2014 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 30 Apr 2014 09:56:09 +0000 Subject: [issue21390] readline: setlocale() returns NULL on Android In-Reply-To: <1398843223.64.0.854948810113.issue21390@psf.upfronthosting.co.za> Message-ID: <1398851769.6.0.218409505549.issue21390@psf.upfronthosting.co.za> St?phane Wirtel added the comment: +1 for the patch ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 11:56:20 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 30 Apr 2014 09:56:20 +0000 Subject: [issue21393] Python/random.c: close hCryptProv at exit Message-ID: <1398851780.59.0.329794424514.issue21393@psf.upfronthosting.co.za> New submission from STINNER Victor: Attached patch closes hCryptProv handle at Python exit. ---------- files: random_closehandle.patch keywords: patch messages: 217591 nosy: haypo priority: normal severity: normal status: open title: Python/random.c: close hCryptProv at exit versions: Python 3.5 Added file: http://bugs.python.org/file35108/random_closehandle.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 11:57:08 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 30 Apr 2014 09:57:08 +0000 Subject: [issue21393] Python/random.c: close hCryptProv at exit In-Reply-To: <1398851780.59.0.329794424514.issue21393@psf.upfronthosting.co.za> Message-ID: <1398851828.4.0.367351362212.issue21393@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- components: +Windows nosy: +tim.golden _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 11:57:52 2014 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 30 Apr 2014 09:57:52 +0000 Subject: [issue21393] Python/random.c: close hCryptProv at exit In-Reply-To: <1398851780.59.0.329794424514.issue21393@psf.upfronthosting.co.za> Message-ID: <1398851872.56.0.0941453907486.issue21393@psf.upfronthosting.co.za> St?phane Wirtel added the comment: +1 for the patch ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 12:00:23 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 30 Apr 2014 10:00:23 +0000 Subject: [issue21384] Windows: Make handle non inheritable by default In-Reply-To: <1398761981.56.0.701422046655.issue21384@psf.upfronthosting.co.za> Message-ID: <1398852023.33.0.447842390127.issue21384@psf.upfronthosting.co.za> STINNER Victor added the comment: On Windows, handles are created non-inheritable by default, but I would prefer to double check. The tool "Handle" can be used to list all open handles of a process: http://technet.microsoft.com/en-us/sysinternals/bb896655.aspx To test that all handles are non-inheritable: run all Python unit tests, create a subprocesss with close_fds=False, list open handles of the child process and check that the list of not longer than a fresh Python process. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 12:02:30 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 30 Apr 2014 10:02:30 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1398852150.16.0.856636677381.issue21233@psf.upfronthosting.co.za> STINNER Victor added the comment: @Stefan: Can you please review calloc-6.patch? Charles-Fran?ois wrote that the patch looks good, but for such critical operation (memory allocation), I would prefer a second review ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 12:07:47 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 30 Apr 2014 10:07:47 +0000 Subject: [issue21394] Lib/random.py: use more efficient code to convert bytes to integer Message-ID: <1398852467.62.0.62846026727.issue21394@psf.upfronthosting.co.za> New submission from STINNER Victor: In Lib/random.py, I see lines like that: long(_hexlify(_urandom(32)), 16) I guess that something more efficient can be fonud to convert a bytes string to an integer. bytes.from_bytes() maybe? ---------- keywords: easy messages: 217595 nosy: haypo priority: normal severity: normal status: open title: Lib/random.py: use more efficient code to convert bytes to integer type: performance versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 12:09:15 2014 From: report at bugs.python.org (akira) Date: Wed, 30 Apr 2014 10:09:15 +0000 Subject: [issue21332] subprocess bufsize=1 docs are misleading In-Reply-To: <1398209745.28.0.851161689347.issue21332@psf.upfronthosting.co.za> Message-ID: <1398852555.77.0.122778986188.issue21332@psf.upfronthosting.co.za> akira added the comment: It looks like a bug in the subprocess module e.g., if child process does: sys.stdout.write(sys.stdin.readline()) sys.stdout.flush() and the parent: p.stdin.write(line) #NOTE: no flush line = p.stdout.readline() then a deadlock may happen with bufsize=1 (because it is equivalent to bufsize=-1 in the current code) Surprisingly, it works if universal_newlines=True but only for C implementation of io i.e., if C extension is disabled: import io, _pyio io.TextIOWrapper = _pyio.TextIOWrapper then it blocks forever even if universal_newlines=True with bufsize=1 that is clearly wrong (<-- bug) e.g., `test_universal_newlines` deadlocks with _pyio.TextIOWrapper C implementation works because it sets `needflush` flag even if only `write_through` is provided [1]: if (self->write_through) needflush = 1; else if (self->line_buffering && (haslf || PyUnicode_FindChar(text, '\r', 0, PyUnicode_GET_LENGTH(text), 1) != -1)) needflush = 1; [1]: http://hg.python.org/cpython/file/0b2e199ad088/Modules/_io/textio.c#l1333 Python io implementation doesn't flush with only `write_through` flag. It doesn't deadlock if bufsize=0 whether universal_newlines=True or not. Note: Python 2.7 doesn't deadlock with bufsize=0 and bufsize=1 in this case as expected. What is not clear is whether it should work with universal_newline=False and bufsize=1: both current docs and Python 2.7 behaviour say that there should not be a deadlock. I've updated the docs to mention that bufsize=1 works only with universal_newlines=True and added corresponding tests. I've also updated the subprocess' code to pass line_buffering explicitly. Patch is uploaded. ---------- keywords: +patch type: -> behavior Added file: http://bugs.python.org/file35109/subprocess-line-buffering-issue21332.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 12:16:52 2014 From: report at bugs.python.org (Tim Golden) Date: Wed, 30 Apr 2014 10:16:52 +0000 Subject: [issue21393] Python/random.c: close hCryptProv at exit In-Reply-To: <1398851780.59.0.329794424514.issue21393@psf.upfronthosting.co.za> Message-ID: <1398853012.54.0.749533590994.issue21393@psf.upfronthosting.co.za> Tim Golden added the comment: The crypto stuff's not really my area. I agree that the patch looks sane. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 12:18:47 2014 From: report at bugs.python.org (Brian Gesiak) Date: Wed, 30 Apr 2014 10:18:47 +0000 Subject: [issue21395] runtests.rst: link "build Python" to setup.rst#compiling Message-ID: <1398853127.11.0.29558653351.issue21395@psf.upfronthosting.co.za> New submission from Brian Gesiak: runtests.rst insists that readers must build Python before running the tests. For those readers that have not yet built Python, add a link to more information on how to do so. ---------- components: Devguide files: runtests.rst.patch hgrepos: 243 keywords: patch messages: 217598 nosy: ezio.melotti, modocache priority: normal severity: normal status: open title: runtests.rst: link "build Python" to setup.rst#compiling type: enhancement Added file: http://bugs.python.org/file35110/runtests.rst.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 12:34:36 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Wed, 30 Apr 2014 10:34:36 +0000 Subject: [issue21394] Lib/random.py: use more efficient code to convert bytes to integer In-Reply-To: <1398852467.62.0.62846026727.issue21394@psf.upfronthosting.co.za> Message-ID: <1398854076.58.0.868361501155.issue21394@psf.upfronthosting.co.za> Claudiu.Popa added the comment: Do you mean int.from_bytes? It's already changed in Python 3.5: int.from_bytes(_urandom(32), 'big'). ---------- nosy: +Claudiu.Popa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 12:36:57 2014 From: report at bugs.python.org (akira) Date: Wed, 30 Apr 2014 10:36:57 +0000 Subject: [issue21396] Python io implementation doesn't flush with write_through=True unlike C implementation Message-ID: <1398854217.51.0.158914324658.issue21396@psf.upfronthosting.co.za> New submission from akira: related: msg217596 (bufsize=1 is broken if subprocess module uses Python io) TextIOWrapper.write behavior: _pyio.py [1]: if self._line_buffering and (haslf or "\r" in s): self.flush() textio.c [2]: if (self->write_through) needflush = 1; else if (self->line_buffering && (haslf || PyUnicode_FindChar(text, '\r', 0, PyUnicode_GET_LENGTH(text), 1) != -1)) needflush = 1; C implementation calls flush() if write_through=True, Python implementation doesn't. [1]: http://hg.python.org/cpython/file/0b2e199ad088/Lib/_pyio.py#l1636 [2]: http://hg.python.org/cpython/file/0b2e199ad088/Modules/_io/textio.c#l1333 ---------- components: IO messages: 217600 nosy: akira priority: normal severity: normal status: open title: Python io implementation doesn't flush with write_through=True unlike C implementation type: behavior versions: Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 12:39:57 2014 From: report at bugs.python.org (akira) Date: Wed, 30 Apr 2014 10:39:57 +0000 Subject: [issue21332] subprocess bufsize=1 docs are misleading In-Reply-To: <1398209745.28.0.851161689347.issue21332@psf.upfronthosting.co.za> Message-ID: <1398854397.24.0.437461443453.issue21332@psf.upfronthosting.co.za> akira added the comment: Related issue #21396 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 12:47:51 2014 From: report at bugs.python.org (Brian Gesiak) Date: Wed, 30 Apr 2014 10:47:51 +0000 Subject: [issue21397] tempfile.py: Fix grammar in docstring, comment typos Message-ID: <1398854871.81.0.354739462705.issue21397@psf.upfronthosting.co.za> New submission from Brian Gesiak: Commit 1: tempfile.py: Fix grammar in docstring Meaning of "just below" in docstring is unclear; it could mean either "the interfaces listed immediately below this docstring", or "only the interfaces listed as safe below". Fix wording to take on the latter meaning. Commit 2: tempfile.py: Fix typo in comment: s/hget/get/ --- This is my first patch to CPython, but hopefully not my last! Any and all feedback, such as on patch submission etiquette, is very much appreciated! ---------- components: Library (Lib) files: tempfile.py.patch hgrepos: 244 keywords: patch messages: 217602 nosy: modocache priority: normal severity: normal status: open title: tempfile.py: Fix grammar in docstring, comment typos versions: Python 3.5 Added file: http://bugs.python.org/file35111/tempfile.py.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 13:24:00 2014 From: report at bugs.python.org (dellair jie) Date: Wed, 30 Apr 2014 11:24:00 +0000 Subject: [issue21392] Python on Cygwin: subprocess.call BlockingIOError: [Errno 11] Resource temporarily unavailable In-Reply-To: <1398849344.37.0.135899033278.issue21392@psf.upfronthosting.co.za> Message-ID: <1398857040.54.0.349258580254.issue21392@psf.upfronthosting.co.za> dellair jie added the comment: The value of __signal and __signalList: __signal=0 __signalList=[None] * 256 __signalList[signal.SIGHUP] = signalHandler __signalList[signal.SIGQUIT] = signalHandler __signalList[signal.SIGUSR1] = signalHandler __signalList[signal.SIGUSR2] = signalHandler signal.signal (signal.SIGHUP, signalHandler) signal.signal (signal.SIGQUIT, signalHandler) signal.signal (signal.SIGUSR2, signalHandler) signal.signal (signal.SIGUSR1, signalHandler) I think those are irrelevant though. cmd is a command and that is working. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 13:33:21 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 30 Apr 2014 11:33:21 +0000 Subject: [issue21398] pydoc heapq leaves terminal in an unusable state Message-ID: <1398857601.48.0.383316165786.issue21398@psf.upfronthosting.co.za> New submission from Stefan Krah: $ ./python -m pydoc heapq Traceback (most recent call last): File "/home/stefan/hg/cpython/Lib/runpy.py", line 170, in _run_module_as_main "__main__", mod_spec) File "/home/stefan/hg/cpython/Lib/runpy.py", line 85, in _run_code exec(code, run_globals) File "/home/stefan/hg/cpython/Lib/pydoc.py", line 2615, in cli() File "/home/stefan/hg/cpython/Lib/pydoc.py", line 2580, in cli help.help(arg) File "/home/stefan/hg/cpython/Lib/pydoc.py", line 1862, in help elif request: doc(request, 'Help on %s:', output=self._output) File "/home/stefan/hg/cpython/Lib/pydoc.py", line 1600, in doc pager(render_doc(thing, title, forceload)) File "/home/stefan/hg/cpython/Lib/pydoc.py", line 1408, in pager pager(text) File "/home/stefan/hg/cpython/Lib/pydoc.py", line 1422, in return lambda text: pipepager(text, os.environ['PAGER']) File "/home/stefan/hg/cpython/Lib/pydoc.py", line 1449, in pipepager pipe.write(text) UnicodeEncodeError: 'ascii' codec can't encode character '\xe7' in position 3574: ordinal not in range(128) $ stty sane $ locale LANG=en_US.UTF-8 LANGUAGE= LC_CTYPE="C" LC_NUMERIC="C" LC_TIME="C" LC_COLLATE="C" LC_MONETARY="C" LC_MESSAGES="C" LC_PAPER="C" LC_NAME="C" LC_ADDRESS="C" LC_TELEPHONE="C" LC_MEASUREMENT="C" LC_IDENTIFICATION="C" LC_ALL=C ---------- messages: 217604 nosy: skrah priority: normal severity: normal status: open title: pydoc heapq leaves terminal in an unusable state versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 13:48:17 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 30 Apr 2014 11:48:17 +0000 Subject: [issue21398] pydoc heapq leaves terminal in an unusable state In-Reply-To: <1398857601.48.0.383316165786.issue21398@psf.upfronthosting.co.za> Message-ID: <1398858497.95.0.151187174546.issue21398@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 14:17:43 2014 From: report at bugs.python.org (Eric V. Smith) Date: Wed, 30 Apr 2014 12:17:43 +0000 Subject: [issue21392] Python on Cygwin: subprocess.call BlockingIOError: [Errno 11] Resource temporarily unavailable In-Reply-To: <1398849344.37.0.135899033278.issue21392@psf.upfronthosting.co.za> Message-ID: <1398860263.8.0.137342737641.issue21392@psf.upfronthosting.co.za> Eric V. Smith added the comment: I'd like to help with this, but unless you can provide a script I can run that shows the problem, I can't. I don't have the time to figure out what parameters I need to pass in to cause the problem. Sorry. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 14:19:21 2014 From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=) Date: Wed, 30 Apr 2014 12:19:21 +0000 Subject: [issue18564] Integer overflow in socketmodule In-Reply-To: <1374861545.82.0.430674187566.issue18564@psf.upfronthosting.co.za> Message-ID: <1398860361.85.0.450646728309.issue18564@psf.upfronthosting.co.za> Changes by Michele Orr? : Added file: http://bugs.python.org/file35112/issue18564.2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 14:22:03 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 30 Apr 2014 12:22:03 +0000 Subject: [issue21399] inspect and class methods Message-ID: <1398860523.15.0.277604564567.issue21399@psf.upfronthosting.co.za> New submission from Stefan Krah: In Python2.7, the cls parameter shows up in pydoc: frombuf(cls, buf) from __builtin__.type Construct a TarInfo object from a 512 byte string buffer. In 3.5, it doesn't: frombuf(buf, encoding, errors) from builtins.type Construct a TarInfo object from a 512 byte bytes object. inspect.signature shows 'self', but not 'cls': >>> from tarfile import * >>> from inspect import * >>> signature(TarInfo.create_gnu_header) >>> signature(TarInfo.frombuf) So my guess is that this is an oversight. How about the C docstrings? Can we get "$cls" for classmethods? ---------- messages: 217606 nosy: Yury.Selivanov, larry, skrah priority: normal severity: normal status: open title: inspect and class methods type: behavior versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 14:22:25 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 30 Apr 2014 12:22:25 +0000 Subject: [issue21398] pydoc heapq leaves terminal in an unusable state In-Reply-To: <1398857601.48.0.383316165786.issue21398@psf.upfronthosting.co.za> Message-ID: <1398860545.91.0.106839422406.issue21398@psf.upfronthosting.co.za> R. David Murray added the comment: Works fine for me. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 14:28:36 2014 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 30 Apr 2014 12:28:36 +0000 Subject: [issue21398] pydoc heapq leaves terminal in an unusable state In-Reply-To: <1398857601.48.0.383316165786.issue21398@psf.upfronthosting.co.za> Message-ID: <1398860916.54.0.681900702536.issue21398@psf.upfronthosting.co.za> St?phane Wirtel added the comment: the pydoc module works fine but when I use CTRL-C to quit it, I get this error in the terminal. I think it's an other bug but the traceback is really similar. Stephane Traceback (most recent call last): File "/Users/stephane/src/projects/externals/cpython/Lib/runpy.py", line 170, in _run_module_as_main "__main__", mod_spec) File "/Users/stephane/src/projects/externals/cpython/Lib/runpy.py", line 85, in _run_code exec(code, run_globals) File "/Users/stephane/src/projects/externals/cpython/Lib/pydoc.py", line 2615, in cli() File "/Users/stephane/src/projects/externals/cpython/Lib/pydoc.py", line 2580, in cli help.help(arg) File "/Users/stephane/src/projects/externals/cpython/Lib/pydoc.py", line 1862, in help elif request: doc(request, 'Help on %s:', output=self._output) File "/Users/stephane/src/projects/externals/cpython/Lib/pydoc.py", line 1600, in doc pager(render_doc(thing, title, forceload)) File "/Users/stephane/src/projects/externals/cpython/Lib/pydoc.py", line 1408, in pager pager(text) File "/Users/stephane/src/projects/externals/cpython/Lib/pydoc.py", line 1428, in return lambda text: pipepager(text, 'less') File "/Users/stephane/src/projects/externals/cpython/Lib/pydoc.py", line 1450, in pipepager pipe.close() File "/Users/stephane/src/projects/externals/cpython/Lib/os.py", line 957, in close returncode = self._proc.wait() File "/Users/stephane/src/projects/externals/cpython/Lib/subprocess.py", line 1581, in wait (pid, sts) = self._try_wait(0) File "/Users/stephane/src/projects/externals/cpython/Lib/subprocess.py", line 1529, in _try_wait (pid, sts) = _eintr_retry_call(os.waitpid, self.pid, wait_flags) File "/Users/stephane/src/projects/externals/cpython/Lib/subprocess.py", line 502, in _eintr_retry_call return func(*args) KeyboardInterrupt ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 14:30:14 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 30 Apr 2014 12:30:14 +0000 Subject: [issue21398] pydoc heapq leaves terminal in an unusable state In-Reply-To: <1398857601.48.0.383316165786.issue21398@psf.upfronthosting.co.za> Message-ID: <1398861014.18.0.624364817977.issue21398@psf.upfronthosting.co.za> Stefan Krah added the comment: Did you use the same locale settings? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 14:31:38 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 30 Apr 2014 12:31:38 +0000 Subject: [issue20974] email module docs say not compatible with current python version In-Reply-To: <1395176910.11.0.458502603486.issue20974@psf.upfronthosting.co.za> Message-ID: <1398861098.76.0.907920775546.issue20974@psf.upfronthosting.co.za> R. David Murray added the comment: Like I said, the compatibility claims are almost certainly incorrect. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 14:32:54 2014 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 30 Apr 2014 12:32:54 +0000 Subject: [issue21398] pydoc heapq leaves terminal in an unusable state In-Reply-To: <1398857601.48.0.383316165786.issue21398@psf.upfronthosting.co.za> Message-ID: <1398861174.91.0.290782018997.issue21398@psf.upfronthosting.co.za> St?phane Wirtel added the comment: > locale LANG="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_CTYPE="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_ALL="en_US.UTF-8" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 14:37:47 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 30 Apr 2014 12:37:47 +0000 Subject: [issue21398] LC_CTYPE=C: pydoc leaves terminal in an unusable state In-Reply-To: <1398857601.48.0.383316165786.issue21398@psf.upfronthosting.co.za> Message-ID: <1398861467.37.0.297348461549.issue21398@psf.upfronthosting.co.za> Stefan Krah added the comment: Sorry, then I should have been more explicit: The failure only occurs with LC_CTYPE=C. ---------- title: pydoc heapq leaves terminal in an unusable state -> LC_CTYPE=C: pydoc leaves terminal in an unusable state _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 14:39:59 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 30 Apr 2014 12:39:59 +0000 Subject: [issue21398] LC_CTYPE=C: pydoc leaves terminal in an unusable state In-Reply-To: <1398857601.48.0.383316165786.issue21398@psf.upfronthosting.co.za> Message-ID: <1398861599.92.0.191260368586.issue21398@psf.upfronthosting.co.za> R. David Murray added the comment: Ah, yes, my lc_ctype was en_US.utf-8. I can reproduce it if I change that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 14:43:22 2014 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 30 Apr 2014 12:43:22 +0000 Subject: [issue21398] LC_CTYPE=C: pydoc leaves terminal in an unusable state In-Reply-To: <1398857601.48.0.383316165786.issue21398@psf.upfronthosting.co.za> Message-ID: <1398861801.99.0.921595627081.issue21398@psf.upfronthosting.co.za> St?phane Wirtel added the comment: I use OSX 10.9 on my laptop, Python 3.5 and I get this error in one case. If I use CTRL-C to quit the application and if LC_CTYPE=C. with the 'q' key, I don't get this problem. Just LC_CTYPE=C and CTRL-C and I have to reset my terminal. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 14:53:53 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 30 Apr 2014 12:53:53 +0000 Subject: [issue21398] LC_CTYPE=C: pydoc leaves terminal in an unusable state In-Reply-To: <1398857601.48.0.383316165786.issue21398@psf.upfronthosting.co.za> Message-ID: <1398862433.67.0.350856770779.issue21398@psf.upfronthosting.co.za> Stefan Krah added the comment: I can also confirm the need to reset the terminal when using a working locale and Ctrl-C. So we have two issues then: 1) The UnicodeDecodeError should not happen. 2) pydoc behaves erratically after various exceptions. In Python2.7 neither of the issues is present. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 14:54:14 2014 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 30 Apr 2014 12:54:14 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1398842605.59.0.546249937639.issue6839@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: As Greg suggested, the important thing is to follow the precedent set by other debug messages in the module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 14:58:52 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 30 Apr 2014 12:58:52 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1398862732.34.0.562293149717.issue21233@psf.upfronthosting.co.za> Stefan Krah added the comment: Victor, sure, maybe not right away. If you prefer to commit very soon, I promise to do a post commit review. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 14:59:59 2014 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 30 Apr 2014 12:59:59 +0000 Subject: [issue21398] LC_CTYPE=C: pydoc leaves terminal in an unusable state In-Reply-To: <1398857601.48.0.383316165786.issue21398@psf.upfronthosting.co.za> Message-ID: <1398862799.91.0.743351069196.issue21398@psf.upfronthosting.co.za> St?phane Wirtel added the comment: In python 2.7, If I use my working locales (utf-8) and I use CTRL-C, pydoc does not quit but leave a message when the screen is cleaned. same result with LC_CTYPE=C bash-4.3$ python -m pydoc heapq Traceback (most recent call last): File "/usr/local/Cellar/python/2.7.6_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/runpy.py", line 162, in _run_module_as_main "__main__", fname, loader, pkg_name) File "/usr/local/Cellar/python/2.7.6_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/runpy.py", line 72, in _run_code exec code in run_globals File "/usr/local/Cellar/python/2.7.6_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pydoc.py", line 2359, in if __name__ == '__main__': cli() File "/usr/local/Cellar/python/2.7.6_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pydoc.py", line 2328, in cli help.help(arg) File "/usr/local/Cellar/python/2.7.6_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pydoc.py", line 1793, in help elif request: doc(request, 'Help on %s:') File "/usr/local/Cellar/python/2.7.6_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pydoc.py", line 1532, in doc pager(render_doc(thing, title, forceload)) File "/usr/local/Cellar/python/2.7.6_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pydoc.py", line 1337, in pager pager(text) File "/usr/local/Cellar/python/2.7.6_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pydoc.py", line 1357, in return lambda text: pipepager(text, 'less') File "/usr/local/Cellar/python/2.7.6_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pydoc.py", line 1379, in pipepager pipe.close() KeyboardInterrupt bash-4.3$ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 15:23:43 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 30 Apr 2014 13:23:43 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1398862732.34.0.562293149717.issue21233@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > If you prefer to commit very soon, > I promise to do a post commit review. There is no need to hurry. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 15:58:36 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 30 Apr 2014 13:58:36 +0000 Subject: [issue21395] runtests.rst: link "build Python" to setup.rst#compiling In-Reply-To: <1398853127.11.0.29558653351.issue21395@psf.upfronthosting.co.za> Message-ID: <3gJhCJ0fFFz7Ljy@mail.python.org> Roundup Robot added the comment: New changeset 678310833d85 by Benjamin Peterson in branch 'default': add link to compiling documentation (closes #21395) http://hg.python.org/devguide/rev/678310833d85 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 17:06:39 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 30 Apr 2014 15:06:39 +0000 Subject: [issue21282] setup.py: More informative error msg for modules which built but failed import check In-Reply-To: <1397732962.82.0.641060383961.issue21282@psf.upfronthosting.co.za> Message-ID: <3gJjjp2tB8z7LnR@mail.python.org> Roundup Robot added the comment: New changeset 981242c8fc86 by Benjamin Peterson in branch 'default': setup.py: report modules which built but import failed (closes #21282) http://hg.python.org/cpython/rev/981242c8fc86 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 17:07:54 2014 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 30 Apr 2014 15:07:54 +0000 Subject: [issue21400] Code coverage documentation is out-of-date. Message-ID: <1398870474.7.0.668295680228.issue21400@psf.upfronthosting.co.za> New submission from St?phane Wirtel: In the section "Increase Test Coverage" of the DevGuide : https://docs.python.org/devguide/_sources/coverage.txt You can read this paragraph where there is a url for a website, but the website is out-of-date and don't reflect the right version of Python. """ Choosing what module you want to increase test coverage for can be done in a couple of ways. A third-party website at http://coverage.livinglogic.de/ provides an overall view of how good coverage is for various modules (you will want to focus on those in the ``Lib`` directory as those are the pure Python modules from Python's stdlib, and thus easier to work with than the C extension modules). But since this is a third-party site we cannot promise that it will always be accessible or have useful information (i.e., be working properly). """ """ Python code coverage Generated at 2013-08-14 08:28:40 Last commit at 2013-08-14 03:34:49 by Raymond Hettinger Changeset identification hash ac2f59a6637f0cc69c4a5541195ce752cf34952a Local revision number 85168 """ Two options, remove the link or update the site. ---------- messages: 217622 nosy: matrixise priority: normal severity: normal status: open title: Code coverage documentation is out-of-date. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 17:42:32 2014 From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=) Date: Wed, 30 Apr 2014 15:42:32 +0000 Subject: [issue21400] Code coverage documentation is out-of-date. In-Reply-To: <1398870474.7.0.668295680228.issue21400@psf.upfronthosting.co.za> Message-ID: <1398872552.72.0.0146136318677.issue21400@psf.upfronthosting.co.za> Walter D?rwald added the comment: The cronjob that produces this information has been deactivated, because it currently produces broken output. The code for that job is available from here: https://pypi.python.org/pypi/pycoco It would be great to have up to date coverage info for Python again, but I don't have time to work on that. Perhaps someone can combine this code and Ned Batchelder coverage script to implement a new coverage site (that includes coverage info for C modules). However for now I think this link should be removed. ---------- nosy: +doerwalter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 17:50:33 2014 From: report at bugs.python.org (Adam Polkosnik) Date: Wed, 30 Apr 2014 15:50:33 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1398873033.21.0.289841046375.issue6839@psf.upfronthosting.co.za> Changes by Adam Polkosnik : Removed file: http://bugs.python.org/file35103/zipfile_340_filename_mismatch.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 17:50:42 2014 From: report at bugs.python.org (Adam Polkosnik) Date: Wed, 30 Apr 2014 15:50:42 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1398873042.11.0.984615711502.issue6839@psf.upfronthosting.co.za> Changes by Adam Polkosnik : Removed file: http://bugs.python.org/file33666/zipfile_stupid3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 17:50:50 2014 From: report at bugs.python.org (Adam Polkosnik) Date: Wed, 30 Apr 2014 15:50:50 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1398873050.44.0.480404611054.issue6839@psf.upfronthosting.co.za> Changes by Adam Polkosnik : Removed file: http://bugs.python.org/file35104/zipfile_276_filename_mismatch.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 17:51:57 2014 From: report at bugs.python.org (Adam Polkosnik) Date: Wed, 30 Apr 2014 15:51:57 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1398873117.1.0.356304980224.issue6839@psf.upfronthosting.co.za> Adam Polkosnik added the comment: Attached is a patch with warnings against 2.7.6 ---------- Added file: http://bugs.python.org/file35113/zipfile_276_filename_mismatch_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 17:52:37 2014 From: report at bugs.python.org (Adam Polkosnik) Date: Wed, 30 Apr 2014 15:52:37 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1398873157.14.0.98011614999.issue6839@psf.upfronthosting.co.za> Adam Polkosnik added the comment: Attached is a patch with warnings against 3.4.0 ---------- Added file: http://bugs.python.org/file35114/zipfile_340_filename_mismatch_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 17:53:40 2014 From: report at bugs.python.org (Adam Polkosnik) Date: Wed, 30 Apr 2014 15:53:40 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1398873220.8.0.483470213702.issue6839@psf.upfronthosting.co.za> Changes by Adam Polkosnik : Removed file: http://bugs.python.org/file35113/zipfile_276_filename_mismatch_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 18:01:42 2014 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 30 Apr 2014 16:01:42 +0000 Subject: [issue21400] Code coverage documentation is out-of-date. In-Reply-To: <1398872552.72.0.0146136318677.issue21400@psf.upfronthosting.co.za> Message-ID: St?phane Wirtel added the comment: Ok thanks for your feedback about your script. Where can I find the scripts of Ned? Thank you ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 18:10:33 2014 From: report at bugs.python.org (Adam Polkosnik) Date: Wed, 30 Apr 2014 16:10:33 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1398874233.14.0.983677278037.issue6839@psf.upfronthosting.co.za> Adam Polkosnik added the comment: Attached is a patch with warnings against 2.7.6 (this one should be good to go) ---------- Added file: http://bugs.python.org/file35115/zipfile_276_filename_mismatch_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 18:40:58 2014 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 30 Apr 2014 16:40:58 +0000 Subject: [issue21399] inspect and class methods In-Reply-To: <1398860523.15.0.277604564567.issue21399@psf.upfronthosting.co.za> Message-ID: <1398876058.51.0.45898970343.issue21399@psf.upfronthosting.co.za> Yury Selivanov added the comment: > In Python2.7, the cls parameter shows up in pydoc: > > frombuf(cls, buf) from __builtin__.type > Construct a TarInfo object from a 512 byte string buffer. > > > In 3.5, it doesn't: > > frombuf(buf, encoding, errors) from builtins.type > Construct a TarInfo object from a 512 byte bytes object. Yes, that's a correct behaviour in 3.4 and 3.5. See #20710 for details. > >>> signature(TarInfo.create_gnu_header) > > >>> signature(TarInfo.frombuf) > There is no bug here. `TarInfo.create_gnu_header` is an unbound method, that indeed requires first argument 'self'. `TarInfo.frombuf` is a classmethod, so it doesn't need a 'cls' arg. Signature, by default and by design, only shows arguments that need to be passed to correctly execute the given callable. > How about the C docstrings? Can we get "$cls" for classmethods? Yes, I think it should work. ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 18:48:26 2014 From: report at bugs.python.org (Ned Deily) Date: Wed, 30 Apr 2014 16:48:26 +0000 Subject: [issue21380] timezone support in strftime methods broken In-Reply-To: <1398720102.85.0.645448692913.issue21380@psf.upfronthosting.co.za> Message-ID: <1398876506.35.0.129208448864.issue21380@psf.upfronthosting.co.za> Ned Deily added the comment: As Jayanth points out, datetime objects are deliberately time zone "naive" by default; please read https://docs.python.org/2/library/datetime.html and https://docs.python.org/2/library/datetime.html#tzinfo-objects for more information. Also see https://pypi.python.org/pypi/pytz/. ---------- nosy: +ned.deily resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 18:57:51 2014 From: report at bugs.python.org (Ned Deily) Date: Wed, 30 Apr 2014 16:57:51 +0000 Subject: [issue21396] Python io implementation doesn't flush with write_through=True unlike C implementation In-Reply-To: <1398854217.51.0.158914324658.issue21396@psf.upfronthosting.co.za> Message-ID: <1398877071.33.0.971390503487.issue21396@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 19:05:11 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 30 Apr 2014 17:05:11 +0000 Subject: [issue20094] intermitent failures with test_dbm In-Reply-To: <1388335598.36.0.994619281921.issue20094@psf.upfronthosting.co.za> Message-ID: <1398877511.36.0.00373554058319.issue20094@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: I can't reproduce on Linux 12.04. I tried the test a thousand times. Ethan, what is your build environment? ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 19:16:20 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 30 Apr 2014 17:16:20 +0000 Subject: [issue10650] decimal.py: quantize(): excess digits with watchexp=0 In-Reply-To: <1291816575.32.0.784106881295.issue10650@psf.upfronthosting.co.za> Message-ID: <3gJmbR6tbnz7LjM@mail.python.org> Roundup Robot added the comment: New changeset c2f827af02a2 by Stefan Krah in branch 'default': Issue #10650: Remove the non-standard 'watchexp' parameter from the http://hg.python.org/cpython/rev/c2f827af02a2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 19:20:35 2014 From: report at bugs.python.org (Ned Deily) Date: Wed, 30 Apr 2014 17:20:35 +0000 Subject: [issue21332] subprocess bufsize=1 docs are misleading In-Reply-To: <1398209745.28.0.851161689347.issue21332@psf.upfronthosting.co.za> Message-ID: <1398878435.43.0.554149213467.issue21332@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 19:47:11 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 30 Apr 2014 17:47:11 +0000 Subject: [issue18104] Idle: make human-mediated GUI tests usable In-Reply-To: <1369961521.26.0.131640091288.issue18104@psf.upfronthosting.co.za> Message-ID: <1398880031.48.0.0853697589566.issue18104@psf.upfronthosting.co.za> Changes by Terry J. Reedy : Removed file: http://bugs.python.org/file35096/18104-htest2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 19:48:04 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 30 Apr 2014 17:48:04 +0000 Subject: [issue18104] Idle: make human-mediated GUI tests usable In-Reply-To: <1369961521.26.0.131640091288.issue18104@psf.upfronthosting.co.za> Message-ID: <1398880084.97.0.946544099982.issue18104@psf.upfronthosting.co.za> Changes by Terry J. Reedy : Removed file: http://bugs.python.org/file35099/18104-htest3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 19:50:55 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 30 Apr 2014 17:50:55 +0000 Subject: [issue18104] Idle: make human-mediated GUI tests usable In-Reply-To: <1369961521.26.0.131640091288.issue18104@psf.upfronthosting.co.za> Message-ID: <1398880255.18.0.383480215984.issue18104@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Defective patches removed and replaced with one that includes current htest.py and should have proper (unix) line endings. ---------- Added file: http://bugs.python.org/file35116/18104-htest4.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 20:00:16 2014 From: report at bugs.python.org (Joshua J Cogliati) Date: Wed, 30 Apr 2014 18:00:16 +0000 Subject: [issue21401] python2 -3 does not warn about str to bytes conversions and comparisons Message-ID: <1398880816.89.0.350834147614.issue21401@psf.upfronthosting.co.za> New submission from Joshua J Cogliati: The -3 option should warn about str to bytes conversions and str to bytes comparisons: For example in Python 3 the following happens: python3 Python 3.3.2 Type "help", "copyright", "credits" or "license" for more information. >>> b"a" + "a" Traceback (most recent call last): File "", line 1, in TypeError: can't concat bytes to str >>> b"a" == "a" False >>> But even python2 -3 does not warn about either of these uses: python2 -3 Python 2.7.5 Type "help", "copyright", "credits" or "license" for more information. >>> b"a" + "a" 'aa' >>> b"a" == "a" True >>> u"a" + "a" u'aa' >>> u"a" == "a" True >>> These two issues are some of the more significant problems I have in trying get python2 code working with python3, and if -3 does not warn about it this is harder to do. ---------- components: Unicode messages: 217633 nosy: Joshua.J.Cogliati, ezio.melotti, haypo priority: normal severity: normal status: open title: python2 -3 does not warn about str to bytes conversions and comparisons versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 20:01:52 2014 From: report at bugs.python.org (Berker Peksag) Date: Wed, 30 Apr 2014 18:01:52 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1398880912.02.0.435489556932.issue6839@psf.upfronthosting.co.za> Berker Peksag added the comment: --- a/zipfile.py Wed Apr 30 11:27:16 2014 +++ b/zipfile.py Wed Apr 30 11:27:01 2014 @@ -1174,8 +1174,9 @@ else: fname_str = fname.decode("cp437") - if fname_str != zinfo.orig_filename: - raise BadZipFile( + if self.debug and fname_str != zinfo.orig_filename: + import warnings + warnings.warn( 'File name in directory %r and header %r differ.' % (zinfo.orig_filename, fname)) Also, you need to add ``stacklevel=2`` to warnings.warn(). ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 20:28:56 2014 From: report at bugs.python.org (Adam Polkosnik) Date: Wed, 30 Apr 2014 18:28:56 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1398882536.78.0.959544094076.issue6839@psf.upfronthosting.co.za> Adam Polkosnik added the comment: 3.4.0 pathc with stacklevel=2 ---------- Added file: http://bugs.python.org/file35117/zipfile_340_filename_mismatch_v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 20:31:41 2014 From: report at bugs.python.org (Jim Jewett) Date: Wed, 30 Apr 2014 18:31:41 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1398882701.96.0.800294361954.issue6839@psf.upfronthosting.co.za> Jim Jewett added the comment: I'm leaving it as "needs patch" because it isn't clear exactly what a committer should do. I think the current intent is to make the changes listed in zipfile_???_filename_mismatch_v2.patch (which are not listed as reviewable -- but the changes are indeed sufficiently straightforward that the the files -- if need be -- could be edited by hand as if they were made originally by the committer.) This change is small enough (warning instead of raise) that a test case is probably not strictly required, but it would be helpful. test.zip would presumably be useful data for a test case. There is dispute over whether this would be an enhancement (more generous with what to accept), a bug fix, or a security *regression* because it still allows old vulnerable files to stick around unreplaced (or to hide from a malware scanner), but no longer raises an Exception to get attention. (warnings are often ignored) zlib_forward_slash.patch would also be good (and might even be a security fix, by allowing the new versions to be installed), but is not ready to be committed, as (A) it repeats the logic inline instead of using the newly defined helper method (B) it doesn't have a test case (test1.zip should help when creating one) (C) it has neither a doc change nor an explicit (and dubious) statement that this is just a bug fix and wouldn't need to be listed in the versionchanged. There is also a question of how general the filename correction should be, particularly with respect to windows drives and capitalization. The one in this patch seems to be the minimal change, and is explicitly supported by the zip spec. ---------- nosy: +Jim.Jewett _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 20:32:10 2014 From: report at bugs.python.org (Berker Peksag) Date: Wed, 30 Apr 2014 18:32:10 +0000 Subject: [issue21137] Better repr for threading.Lock() In-Reply-To: <1396487942.81.0.581020836184.issue21137@psf.upfronthosting.co.za> Message-ID: <1398882730.56.0.774959181019.issue21137@psf.upfronthosting.co.za> Berker Peksag added the comment: Here's an updated patch. Thanks for the reviews. > And of course we should keep "at 0x..." part, because it is the way to distinguish different lock objects. Done. $ ./python -c "import threading; l = threading.Lock(); print(l)" > The repr of threading._RLock contains owner and count, but not lock/unlock status. Done. $ ./python -c "import threading; rl = threading.RLock(); rl.acquire(); print(rl)" > The repr of locks from _dummy_thread also should contain lock/unlock status. Done. $ ./python -c "import dummy_threading as threading; l = threading.Lock(); print(l)" $ ./python -c "import dummy_threading as threading; l = threading.RLock(); print(l)" > As for tests, I think assertRegex() will produce more useful error report. Done. ---------- Added file: http://bugs.python.org/file35118/issue21137_v2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 20:33:23 2014 From: report at bugs.python.org (Jim Jewett) Date: Wed, 30 Apr 2014 18:33:23 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1398882803.04.0.0504569746881.issue6839@psf.upfronthosting.co.za> Jim Jewett added the comment: Presumably the stacklevel applies to all versions; verifying that it warns about the right code location is important enough to require a test case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 20:37:59 2014 From: report at bugs.python.org (Ethan Furman) Date: Wed, 30 Apr 2014 18:37:59 +0000 Subject: [issue20094] intermitent failures with test_dbm In-Reply-To: <1388335598.36.0.994619281921.issue20094@psf.upfronthosting.co.za> Message-ID: <1398883079.21.0.147042341125.issue20094@psf.upfronthosting.co.za> Ethan Furman added the comment: Actually, I haven't had this issue in quite a while now, so closing. Thanks for taking a look at it, Jes?s. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 20:38:54 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 30 Apr 2014 18:38:54 +0000 Subject: [issue18104] Idle: make human-mediated GUI tests usable In-Reply-To: <1369961521.26.0.131640091288.issue18104@psf.upfronthosting.co.za> Message-ID: <1398883134.49.0.554694665856.issue18104@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Here are my notes on modules that should probably be included in htest. Most have some end-of-module test now, many with errors. ---------- Added file: http://bugs.python.org/file35119/18104-htest.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 20:48:28 2014 From: report at bugs.python.org (Adam Polkosnik) Date: Wed, 30 Apr 2014 18:48:28 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1398883708.18.0.241975089997.issue6839@psf.upfronthosting.co.za> Changes by Adam Polkosnik : Removed file: http://bugs.python.org/file35114/zipfile_340_filename_mismatch_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 21:05:26 2014 From: report at bugs.python.org (Adam Polkosnik) Date: Wed, 30 Apr 2014 19:05:26 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1398884726.9.0.137674967612.issue6839@psf.upfronthosting.co.za> Adam Polkosnik added the comment: I just looked through 2.7.6 version of zipfile, and the the error handling there is either through using raise() or print(). So, inline with the guidance provided for 2.7.6, perhapswe should stick with print() instead of warning.warn(). I'll post that a bit later. test.zip up there is the test case for this change. Is there any other test case needed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 21:08:59 2014 From: report at bugs.python.org (Ethan Furman) Date: Wed, 30 Apr 2014 19:08:59 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1398884939.63.0.542079142627.issue6839@psf.upfronthosting.co.za> Ethan Furman added the comment: Adam, please stop deleting the files. It makes for a lot of noise to those on the nosy list, and is unnecessary. Just make sure you increment the version number on the files you upload and it will be fine. Thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 21:09:21 2014 From: report at bugs.python.org (Mark Grandi) Date: Wed, 30 Apr 2014 19:09:21 +0000 Subject: [issue14156] argparse.FileType for '-' doesn't work for a mode of 'rb' In-Reply-To: <1330513271.31.0.437438851478.issue14156@psf.upfronthosting.co.za> Message-ID: <1398884961.47.0.951884688027.issue14156@psf.upfronthosting.co.za> Changes by Mark Grandi : ---------- nosy: +markgrandi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 21:11:50 2014 From: report at bugs.python.org (Adam Polkosnik) Date: Wed, 30 Apr 2014 19:11:50 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1398885110.1.0.45638107752.issue6839@psf.upfronthosting.co.za> Adam Polkosnik added the comment: Jim, I've got some test cases where the zlib_forward_slash.patch doesn't cut it. That was the reason for trying a broader approach with filename_mismatch patches. ---------- Added file: http://bugs.python.org/file35120/zipfile_276_filename_mismatch_v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 21:22:43 2014 From: report at bugs.python.org (Stephen Paul Chappell) Date: Wed, 30 Apr 2014 19:22:43 +0000 Subject: [issue21402] tkinter.ttk._val_or_dict assumes tkinter._default_root exists Message-ID: <1398885763.19.0.937315925175.issue21402@psf.upfronthosting.co.za> New submission from Stephen Paul Chappell: If a call is made to tkinter.NoDefaultRoot, then calls to tkinter.ttk._val_or_dict may fail. NoDefaultRoot ends with "del _default_root" (line 174) and removes the variable from the module's namespace. _val_or_dict can try to access this variable but assumes that it exists (line 319). If _default_root does not exist, the function will raise an AttributeError: 'module' object has no attribute '_default_root'. ---------- components: Library (Lib), Tkinter messages: 217644 nosy: Zero priority: normal severity: normal status: open title: tkinter.ttk._val_or_dict assumes tkinter._default_root exists type: crash versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 21:26:45 2014 From: report at bugs.python.org (Zachary Ware) Date: Wed, 30 Apr 2014 19:26:45 +0000 Subject: [issue21402] tkinter.ttk._val_or_dict assumes tkinter._default_root exists In-Reply-To: <1398885763.19.0.937315925175.issue21402@psf.upfronthosting.co.za> Message-ID: <1398886005.14.0.631916398744.issue21402@psf.upfronthosting.co.za> Zachary Ware added the comment: Can you provide an example of when this happens? Note that tkinter.ttk._val_or_dict is a private function and should not be called by user code. ---------- nosy: +gpolo, serhiy.storchaka, zach.ware stage: -> test needed type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 21:55:59 2014 From: report at bugs.python.org (Zachary Ware) Date: Wed, 30 Apr 2014 19:55:59 +0000 Subject: [issue18604] Consolidate gui available checks in test.support In-Reply-To: <1375229615.82.0.560303267268.issue18604@psf.upfronthosting.co.za> Message-ID: <1398887759.36.0.494097730038.issue18604@psf.upfronthosting.co.za> Zachary Ware added the comment: If there are no objections forthcoming, I'll try to get this applied to 3.4/3.5 later this week, then look into backporting to 2.7. ---------- assignee: -> zach.ware components: +Tests, Tkinter versions: +Python 3.5 Added file: http://bugs.python.org/file35121/issue18604.v2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 22:13:09 2014 From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=) Date: Wed, 30 Apr 2014 20:13:09 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1398888789.26.0.373110292951.issue6839@psf.upfronthosting.co.za> Francisco Mart?n Brugu? added the comment: A small question related to: "zipfile_276_filename_mismatch_v3.patch" --- a/zipfile.py Wed Apr 30 11:44:38 2014 +++ b/zipfile.py Wed Apr 30 15:10:38 2014 @@ -970,10 +970,10 @@ if fheader[_FH_EXTRA_FIELD_LENGTH]: zef_file.read(fheader[_FH_EXTRA_FIELD_LENGTH]) - if fname != zinfo.orig_filename: - raise BadZipfile, \ + if self.debug and fname != zinfo.orig_filename: + print( \ 'File name in directory "%s" and header "%s" differ.' % ( - zinfo.orig_filename, fname) + zinfo.orig_filename, fname)) Shouldn't a change from raising an exception to a print be somewhere documented? Thanks ---------- nosy: +francismb _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 22:42:23 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 30 Apr 2014 20:42:23 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1398890543.03.0.136323817928.issue6839@psf.upfronthosting.co.za> Gregory P. Smith added the comment: The bug was that BadZipFile was being raised when it shouldn't be so I wouldn't worry about documenting the behavior change other than in the Misc/NEWS entry that the ultimate commiter writes up. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 22:47:41 2014 From: report at bugs.python.org (Alex Gaynor) Date: Wed, 30 Apr 2014 20:47:41 +0000 Subject: [issue21306] PEP 466: backport hmac.compare_digest In-Reply-To: <1397868787.47.0.118679212536.issue21306@psf.upfronthosting.co.za> Message-ID: <1398890861.37.0.159233195437.issue21306@psf.upfronthosting.co.za> Alex Gaynor added the comment: Attached patch now includes documentation and should be complete. ---------- keywords: +needs review Added file: http://bugs.python.org/file35122/compare_digest.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 22:49:59 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 30 Apr 2014 20:49:59 +0000 Subject: [issue19962] Create a 'python.bat' script to invoke interpreter from source root In-Reply-To: <1386862429.77.0.358851450829.issue19962@psf.upfronthosting.co.za> Message-ID: <3gJsKy6S6Pz7Ljr@mail.python.org> Roundup Robot added the comment: New changeset de35f6a3b292 by Zachary Ware in branch 'default': Issue #19962: The Windows build process now creates "python.bat" http://hg.python.org/cpython/rev/de35f6a3b292 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 22:56:50 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 30 Apr 2014 20:56:50 +0000 Subject: [issue21332] subprocess bufsize=1 docs are misleading In-Reply-To: <1398209745.28.0.851161689347.issue21332@psf.upfronthosting.co.za> Message-ID: <1398891410.77.0.831019008646.issue21332@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Thanks for the report, diagnosis and patch! Your change looks good to me. I'll commit it soon. ---------- assignee: -> gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 22:58:00 2014 From: report at bugs.python.org (Santoso Wijaya) Date: Wed, 30 Apr 2014 20:58:00 +0000 Subject: [issue21403] cElementTree node creation with attributes is bugged Message-ID: <1398891480.86.0.531348738543.issue21403@psf.upfronthosting.co.za> New submission from Santoso Wijaya: Observe: Python 2.7.6 (default, Mar 22 2014, 22:59:56) [GCC 4.8.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import xml.etree.ElementTree as ET >>> root = ET.Element('root', attrib={'Name':'Root'}) >>> child = ET.SubElement(root, 'child', attrib={'Name':'Child'}) >>> ET.tostring(root) '' >>> import xml.etree.cElementTree as cET >>> root = cET.Element('root', attrib={'Name':'Root'}) >>> child = cET.SubElement(root, 'child', attrib={'Name':'Child'}) >>> cET.tostring(root) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 1126, in tostring ElementTree(element).write(file, encoding, method=method) File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 820, in write serialize(write, self._root, encoding, qnames, namespaces) File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 932, in _serialize_xml v = _escape_attrib(v, encoding) File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 1092, in _escape_attrib _raise_serialization_error(text) File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 1052, in _raise_serialization_error "cannot serialize %r (type %s)" % (text, type(text).__name__) TypeError: cannot serialize {'Name': 'Root'} (type dict) ---------- components: Library (Lib) messages: 217652 nosy: santa4nt priority: normal severity: normal status: open title: cElementTree node creation with attributes is bugged type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 22:59:34 2014 From: report at bugs.python.org (Santoso Wijaya) Date: Wed, 30 Apr 2014 20:59:34 +0000 Subject: [issue21403] cElementTree node creation with attributes is bugged In-Reply-To: <1398891480.86.0.531348738543.issue21403@psf.upfronthosting.co.za> Message-ID: <1398891574.32.0.481758531808.issue21403@psf.upfronthosting.co.za> Santoso Wijaya added the comment: Or, more succintly: Python 2.7.6 (default, Mar 22 2014, 22:59:56) [GCC 4.8.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import xml.etree.ElementTree as ET >>> root = ET.Element('Root', attrib={'Name':'Root'}) >>> root.attrib {'Name': 'Root'} >>> import xml.etree.cElementTree as cET >>> root = cET.Element('Root', attrib={'Name':'Root'}) >>> root.attrib {'attrib': {'Name': 'Root'}} ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 23:03:48 2014 From: report at bugs.python.org (Santoso Wijaya) Date: Wed, 30 Apr 2014 21:03:48 +0000 Subject: [issue21403] cElementTree creation of nodes with attributes is bugged In-Reply-To: <1398891480.86.0.531348738543.issue21403@psf.upfronthosting.co.za> Message-ID: <1398891828.92.0.515793950611.issue21403@psf.upfronthosting.co.za> Changes by Santoso Wijaya : ---------- title: cElementTree node creation with attributes is bugged -> cElementTree creation of nodes with attributes is bugged _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 23:04:35 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 30 Apr 2014 21:04:35 +0000 Subject: [issue21396] Python io implementation doesn't flush with write_through=True unlike C implementation In-Reply-To: <1398854217.51.0.158914324658.issue21396@psf.upfronthosting.co.za> Message-ID: <1398891875.73.0.107830259524.issue21396@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thanks for the report, Akira. Feel free to submit a patch! (with a test) ---------- stage: -> needs patch versions: -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 23:06:56 2014 From: report at bugs.python.org (Sworddragon) Date: Wed, 30 Apr 2014 21:06:56 +0000 Subject: [issue21404] Compression level for tarfile/zipfile Message-ID: <1398892016.48.0.640823521737.issue21404@psf.upfronthosting.co.za> New submission from Sworddragon: The tarfile/zipfile libraries doesn't seem to provide a direct way to specify the compression level. I have now ported my code from subprocess to tarfile/zipfile to achieve platform independency but would be happy if I could also control the compression level. Or is there a special reason not to add this? ---------- components: Library (Lib) messages: 217655 nosy: Sworddragon priority: normal severity: normal status: open title: Compression level for tarfile/zipfile versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 23:07:07 2014 From: report at bugs.python.org (Sworddragon) Date: Wed, 30 Apr 2014 21:07:07 +0000 Subject: [issue21404] Compression level for tarfile/zipfile In-Reply-To: <1398892016.48.0.640823521737.issue21404@psf.upfronthosting.co.za> Message-ID: <1398892027.12.0.761442435071.issue21404@psf.upfronthosting.co.za> Changes by Sworddragon : ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 23:14:00 2014 From: report at bugs.python.org (Stephen Paul Chappell) Date: Wed, 30 Apr 2014 21:14:00 +0000 Subject: [issue21402] tkinter.ttk._val_or_dict assumes tkinter._default_root exists In-Reply-To: <1398885763.19.0.937315925175.issue21402@psf.upfronthosting.co.za> Message-ID: <1398892440.63.0.384115871482.issue21402@psf.upfronthosting.co.za> Stephen Paul Chappell added the comment: I discovered the problem when trying to run the program listed at http://code.activestate.com/recipes/577633/ (Directory Pruner 2). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 23:15:26 2014 From: report at bugs.python.org (Zachary Ware) Date: Wed, 30 Apr 2014 21:15:26 +0000 Subject: [issue19962] Create a 'python.bat' script to invoke interpreter from source root In-Reply-To: <1386862429.77.0.358851450829.issue19962@psf.upfronthosting.co.za> Message-ID: <1398892526.34.0.342899206128.issue19962@psf.upfronthosting.co.za> Zachary Ware added the comment: Thanks for the up-vote, Tim :) ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 23:44:13 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 30 Apr 2014 21:44:13 +0000 Subject: [issue21403] cElementTree creation of nodes with attributes is bugged In-Reply-To: <1398891480.86.0.531348738543.issue21403@psf.upfronthosting.co.za> Message-ID: <1398894253.95.0.380544684076.issue21403@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +eli.bendersky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 23:44:43 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 30 Apr 2014 21:44:43 +0000 Subject: [issue21393] Python/random.c: close hCryptProv at exit In-Reply-To: <1398851780.59.0.329794424514.issue21393@psf.upfronthosting.co.za> Message-ID: <1398894283.79.0.185692692585.issue21393@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Sounds fine to me. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 30 23:51:58 2014 From: report at bugs.python.org (Adam Polkosnik) Date: Wed, 30 Apr 2014 21:51:58 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1398894718.07.0.284867458609.issue6839@psf.upfronthosting.co.za> Adam Polkosnik added the comment: Is there anything else that you need me to provide? ---------- _______________________________________ Python tracker _______________________________________